Actualizează Elementor Pro la 4.2.2: vulnerabilitate critică de upload de fișiere
Elementor Pro are o vulnerabilitate critică de încărcare arbitrară de fișiere, identificată ca CVE-2026-32475. Problema afectează toate versiunile până la 4.2.1 inclusiv și permite unui atacator neautentificat să încarce fișiere cu extensii alese de el, inclusiv fișiere PHP executabile. Actualizează pluginul la versiunea 4.2.2 sau la cea mai nouă versiune disponibilă cât mai repede.
Impact critic
Vulnerabilitatea are scorul CVSS 9.8 din 10. Un atacator poate ajunge la execuție de cod la distanță și poate compromite complet site-ul.
Cine este afectat
Vulnerabilitatea apare în Elementor Website Builder Pro, un plugin WordPress premium cu aproximativ 6 milioane de instalări active. Sunt vulnerabile versiunile Elementor Pro ≤ 4.2.1; versiunea care remediază complet problema este 4.2.2.
Atacul nu cere cont WordPress și nici permisiuni administrative. Totuși, atacatorul are nevoie ca site-ul să publice o pagină care conține un widget Form din Elementor Pro, cu cel puțin un câmp File Upload care nu este marcat ca obligatoriu.
Ce permite vulnerabilitatea
Un upload arbitrar de fișiere apare când aplicația acceptă un fișier fără să îi verifice corect extensia sau tipul. În acest caz, atacatorul poate trimite un fișier PHP și îl poate executa ulterior printr-un URL public, ceea ce deschide drumul către un webshell și alte metode de preluare a serverului.
Problema a fost raportată responsabil pe 24 iulie 2026 prin programul de bug bounty al Wordfence. Elementor a primit raportul pe 27 iulie, a confirmat că o altă parte raportase aceeași problemă pe 2 august și a publicat corecția completă pe 19 august 2026.
De unde pornește ocolirea validării
Formularele Elementor Pro ajung la funcția ajax_send_form() din clasa Ajax_Handler, accesibilă și vizitatorilor neautentificați. Pluginul împachetează datele trimise, inclusiv fișierele, într-un obiect Form_Record, apoi le trimite prin rutinele de validare și procesare ale clasei ElementorProModulesFormsFieldsUpload.
Pentru un câmp de upload, fluxul ajunge în validation() și process_field(). În validation(), pluginul verifică mai întâi numărul maxim de fișiere configurat pentru câmp. Apoi parcurge fișierele și ar trebui să verifice erorile de upload, tipul permis prin is_file_type_valid() și dimensiunea permisă prin is_file_size_valid().
Defectul este în bucla care tratează un slot de upload gol. Dacă acel câmp nu este obligatoriu, iar primul element din array are eroarea PHP UPLOAD_ERR_NO_FILE, codul folosește return. Astfel, oprește validarea întregului câmp și nu mai verifică niciun fișier care urmează în același array.
foreach ( $files[ $id ] as $index => $file ) {
// Câmpul nu este obligatoriu, iar primul slot este gol.
if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
return; // Oprește validarea tuturor fișierelor rămase.
}
if ( ! $this->is_file_type_valid( $field, $file ) ) {
$ajax_handler->add_error( $id, 'This file type is not allowed.' );
}
if ( ! $this->is_file_size_valid( $field, $file ) ) {
$ajax_handler->add_error( $id, 'This file exceeds the maximum allowed size.' );
}
}Comportamentul corect ar fi folosit continue, care ignoră doar intrarea goală și continuă cu următorul fișier. Din cauza lui return, validarea extensiei și a dimensiunii nu mai rulează pentru elementele rămase.
Cum poate fi exploatată
Atacatorul trimite câmpul de upload ca array cu două elemente. Primul element este gol, deci generează UPLOAD_ERR_NO_FILE și declanșează ieșirea prematură din validation(). Al doilea element conține payloadul PHP, cu extensia aleasă de atacator, iar pluginul nu îl mai validează.
Funcția process_field() tratează diferit slotul gol: folosește corect continue, îl sare și procesează al doilea fișier, care nu a trecut prin controalele de tip și dimensiune. Pluginul preia extensia direct din numele de fișier trimis de client, creează un nume unic și mută fișierul pe disc.
foreach ( $files[ $id ] as $index => $file ) {
if ( UPLOAD_ERR_NO_FILE === $file['error'] ) {
continue; // Sare peste slotul gol.
}
$uploads_dir = $this->get_ensure_upload_dir();
$file_extension = pathinfo( $file['name'], PATHINFO_EXTENSION );
$filename = wp_unique_filename( $uploads_dir, uniqid() . '.' . $file_extension );
$new_file = trailingslashit( $uploads_dir ) . $filename;
Plugin::instance()->php_api->move_uploaded_file(
$file['tmp_name'],
$new_file
);
}Fișierul păstrează extensia extrasă din numele controlat de atacator și ajunge în directorul /wp-content/uploads/elementor/forms/. Dacă atacatorul încarcă un fișier cu extensia .php, poate cere ulterior acel URL pentru a executa payloadul PHP pe server.
Ce trebuie să faci acum
- Verifică versiunea Elementor Pro din WordPress, în pagina Pluginuri.
- Dacă rulezi versiunea 4.2.1 sau una mai veche, actualizează imediat la versiunea 4.2.2 sau la cea mai nouă versiune disponibilă.
- Verifică paginile publicate care folosesc widgetul Form și câmpuri File Upload, mai ales câmpurile care nu sunt obligatorii.
- După actualizare, caută fișiere neașteptate în
/wp-content/uploads/elementor/forms/, în special fișiere cu extensia.php, deoarece un site vulnerabil ar fi putut fi deja vizat. - Dacă găsești fișiere suspecte sau indicii de execuție neautorizată, tratează situația ca pe un posibil compromis al site-ului și investighează serverul, conturile WordPress și fișierele modificate.
Corecția este disponibilă din 19 august 2026. Nu te baza pe faptul că formularul pare puțin folosit sau că uploadul este opțional: tocmai un câmp File Upload neobligatoriu, expus într-o pagină publică, îndeplinește condiția necesară pentru atac.
Andrei Ionescu
Specialist în securitate cibernetică și hacking etic. Testarea de penetrare și auditul de securitate sunt specialitatea mea. Securitatea nu este opțională, ci o cerință fundamentală.
Toate articolele