Krytyczna luka w Elementor Pro pozwalała wgrać dowolny plik bez logowania

W Elementor Pro wykryto krytyczną podatność CVE-2026-32475, która dotyczy wszystkich wersji do 4.2.1 włącznie. Niezalogowany atakujący mógł wgrać na serwer dowolny plik, także wykonywalny plik PHP, a następnie uruchomić go zdalnie i przejąć witrynę.

Kogo dotyczy problem

Podatność występuje w Elementor Website Builder Pro, czyli Elementor Pro, który ma szacunkowo 6 mln aktywnych instalacji. Warunek wykorzystania luki jest konkretny: witryna musi publikować stronę z widżetem Form z co najmniej jednym polem File Upload, którego nie oznaczono jako wymaganego.

Ocena CVSS wynosi 9,8 na 10, czyli poziom krytyczny. Problem odkryto i odpowiedzialnie zgłoszono 24 lipca 2026 roku w programie bug bounty; za zgłoszenie wypłacono nagrodę 15 600 USD.

Na czym polega błąd walidacji

Formularze obsługuje dostępna dla niezalogowanych odwiedzających metoda ajax_send_form() z klasy Ajax_Handler. Dane przesłane przez formularz, wraz z plikami, trafiają do obiektu Form_Record, a pola uploadu przechodzą przez metody validation() i process_field() klasy ElementorProModulesFormsFieldsUpload.

Błąd znajduje się w pętli walidującej metodę Upload::validation(). Gdy pierwsza pozycja tablicy plików ma błąd UPLOAD_ERR_NO_FILE, a pole nie jest wymagane, kod wywołuje return. Przerywa to całą walidację pozostałych plików w tym samym polu, zamiast pominąć pustą pozycję i przejść dalej.

foreach ( $files[ $id ] as $file ) {
    // Puste pole w opcjonalnym uploadzie.
    if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
        return; // Błąd: kończy walidację całego pola.
    }

    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.' );
    }
}

foreach ( $files[ $id ] as $file ) {
    // Puste pole w opcjonalnym uploadzie.
    if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
        return; // Błąd: kończy walidację całego pola.
    }

    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.' );
    }
}

Zamierzonym zachowaniem było użycie continue, które pomija tylko pusty element tablicy. Przez return nie uruchamiają się kontrole rozszerzenia i typu pliku przez is_file_type_valid() ani kontrola jego rozmiaru dla kolejnych pozycji.

Dlaczego umożliwia to wykonanie kodu PHP

Atak wykorzystuje pole uploadu przesłane jako tablicę z dwiema częściami. Pierwsza jest pusta, więc otrzymuje UPLOAD_ERR_NO_FILE i przedwcześnie kończy walidację. Druga zawiera plik z wybranym przez atakującego rozszerzeniem, którego mechanizm walidacji już nie sprawdza.

Metoda process_field() zachowuje się inaczej: dla pustej pierwszej pozycji używa poprawnie continue, więc przetwarza drugi, niewalidowany plik. Pobiera rozszerzenie bezpośrednio z nazwy przesłanej przez klienta, tworzy unikalną nazwę, zapisuje plik w katalogu uploadów, ustawia uprawnienia 0644 i dodaje jego ścieżkę oraz URL do rekordu formularza.

foreach ( $files[ $id ] as $index => $file ) {
    if ( UPLOAD_ERR_NO_FILE === $file['error'] ) {
        continue;
    }

    $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 );
    @chmod( $new_file, 0644 );
}

foreach ( $files[ $id ] as $index => $file ) {
    if ( UPLOAD_ERR_NO_FILE === $file['error'] ) {
        continue;
    }

    $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 );
    @chmod( $new_file, 0644 );
}

W efekcie plik z rozszerzeniem .php mógł trafić bezpośrednio do /wp-content/uploads/elementor/forms/. Atakujący mógł następnie odwołać się do zapisanego pliku, aby uruchomić kod PHP na serwerze. Tego typu luki w uploadzie dowolnych plików mogą prowadzić do pełnego przejęcia witryny, między innymi z użyciem webshelli.

Chronologia ujawnienia

1. 24 lipca 2026 roku zgłoszono podatność polegającą na uploadzie dowolnego pliku bez uwierzytelnienia.
2. 27 lipca 2026 roku potwierdzono zgłoszenie i proof of concept, a następnie przekazano informację twórcom Elementor Pro.
3. 2 sierpnia 2026 roku twórcy poinformowali, że tę samą podatność zgłosiła również inna osoba i pracują nad poprawką.
4. 19 sierpnia 2026 roku wydano Elementor Pro 4.2.2 z kompletną poprawką.

Pierwotnie przypisany identyfikator CVE odrzucono, ponieważ podatność zgłosiła także strona trzecia. Obowiązującym identyfikatorem jest CVE-2026-32475.

Co zrobić teraz

Sprawdź wersję Elementor Pro na każdej utrzymywanej witrynie i zaktualizuj wtyczkę co najmniej do 4.2.2. Szczególnie pilnie potraktuj strony, na których opublikowano formularze Elementor Pro z opcjonalnym polem File Upload, ponieważ to one spełniają warunek wykorzystania podatności.

Po aktualizacji przejrzyj katalog /wp-content/uploads/elementor/forms/ pod kątem nieoczekiwanych plików, zwłaszcza z rozszerzeniem .php. Jeśli znajdziesz podejrzane artefakty, potraktuj witrynę jako potencjalnie przejętą i rozpocznij procedurę obsługi incydentu.