d3kc4rt1/cve-2026-1657Upload arbitrario di file non autenticato nel plugin EventPrime
Disclaimer: Questo repository è stato creato solo a scopo educativo e per divulgazione etica. La vulnerabilità è stata segnalata responsabilmente al fornitore ed è stata corretta. Non utilizzare queste informazioni per sfruttare sistemi senza la dovuta autorizzazione.
È stata scoperta una vulnerabilità di Caricamento File Arbitrario Non Autenticato nel plugin EventPrime per WordPress (versioni <= 4.2.8.1). Questa falla consente a qualsiasi visitatore non autenticato di caricare file direttamente nella directory uploads di WordPress e di creare record di allegati nella Libreria Media.
La vulnerabilità esiste perché un endpoint AJAX specifico è esplicitamente registrato con nopriv (accessibile pubblicamente) e manca sia di controlli di autorizzazione che di una corretta validazione dei contenuti dei file. Gli attaccanti possono abusare di questo endpoint per causare l'esaurimento dello storage, spam nella libreria media o potenzialmente caricare payload dannosi camuffati da immagini.
<= 4.2.8.1La causa radice è una combinazione di una registrazione non sicura degli hook AJAX e una validazione insufficiente dei file.
1. Registrazione Non Sicura dell'Endpoint AJAX:
In includes/class-eventprime-event-calendar-management.php, il plugin registra l'azione upload_file_media. Intorno alla riga 557, imposta {upload_file_media: true} nella sua mappa delle azioni, dove true indica il supporto _nopriv. Di conseguenza, l'hook gwp_ajax_nopriv_ep_upload_file_media viene registrato, rendendo l'endpoint disponibile a chiunque.
2. Mancanza di Controlli di Autorizzazione e Nonce:
La funzione handler upload_file_media() (in includes/class-ep-ajax.php, righe 1659-1697) non utilizza current_user_can() per verificare i privilegi di caricamento, né verifica un nonce di sicurezza.
3. Logica di Validazione Difettosa:
L'handler valida solo l'estensione del file (ad es. jpg/jpeg/png/gif) basandosi sul nome file fornito dal client (righe 1661-1664). Non esegue una robusta validazione lato server del contenuto (come getimagesize() o wp_check_filetype_and_ext()). Ciò implica che script dannosi o altri tipi di file rinominati in harmless.jpg verranno scritti su disco prima che WordPress tenti la generazione dei metadati.
4. Persistenza:
Il file viene salvato utilizzando move_uploaded_file() direttamente in wp_upload_dir()['path'] e viene creato un allegato WordPress tramite wp_insert_attachment().
images), questa potrebbe portare a Remote Code Execution (RCE).1. Preparare il Payload: Creare un file immagine di esempio sulla propria macchina locale chiamato poc.jpg.
2. Eseguire la Richiesta: Inviare una richiesta POST multipart/form-data all'endpoint AJAX pubblico senza alcun cookie di sessione:
curl -i \
-F "[email protected];filename=poc.jpg" \
"http://TARGET_SITE/wp-admin/admin-ajax.php?action=ep_upload_file_media"
3. Osservare la Risposta: Il server risponderà con un 200 OK e restituirà un oggetto JSON contenente il nuovo ID allegato creato:
{"success":true,"data":{"attachment_id":117}}
4. Verifica:
wp-content/uploads/<year>/<month>/poc.jpg.Per risolvere questa vulnerabilità, gli sviluppatori devono:
nopriv se il caricamento è previsto per progettazione solo per utenti autenticati.current_user_can('upload_files') per garantire che solo utenti autorizzati e privilegiati possano caricare.check_ajax_referer() per prevenire attacchi CSRF.wp_handle_upload()) che eseguono controlli più severi su tipo MIME e contenuto.