Hoppa till innehåll
Kritisk filuppladdningsbrist åtgärdad i Elementor Pro 4.2.2
Maja Lindberg
Maja Lindberg 20 August 2026 · 5 min läsning

Kritisk filuppladdningsbrist åtgärdad i Elementor Pro 4.2.2

Elementor Pro har åtgärdat en kritisk säkerhetsbrist som kan låta en icke inloggad angripare ladda upp godtyckliga filer, även körbara PHP-filer, till en WordPress-webbplats. Bristen berör alla versioner till och med 4.2.1 och kan leda till fjärrkörning av kod och ett fullständigt övertagande av webbplatsen.

Uppdatera till 4.2.2

Installerade du Elementor Pro 4.2.1 eller en äldre version ska du uppdatera till version 4.2.2 så snart som möjligt. Angreppet kräver en publicerad sida med Elementor Pro Form och minst ett valfritt fält för filuppladdning.

Vilka webbplatser påverkas?

Säkerhetsbristen har identifieraren CVE-2026-32475 och CVSS-betyget 9,8 av 10, alltså kritiskt. Den finns i Elementor Website Builder Pro och berör versioner till och med 4.2.1. Elementor släppte den fullt korrigerade versionen 4.2.2 den 19 augusti 2026.

En angripare behöver inte ha ett konto på WordPress-webbplatsen. Däremot måste webbplatsen ha publicerat en sida med Form-widgeten från Elementor Pro, där minst ett File Upload-fält inte är markerat som obligatoriskt. Wordfence uppmärksammade bristen den 24 juli 2026.

Så kringgår angreppet filvalideringen

Elementor Pro hanterar formulärinskick via funktionen ajax_send_form() i klassen Ajax_Handler, en endpoint som besökare utan inloggning kan nå. Tillägget kapslar sedan formulärdata och uppladdade filer i ett Form_Record-objekt och skickar dem genom sin validering och bearbetning.

För File Upload-fält går flödet vidare till validation() och process_field() i klassen ElementorProModulesFormsFieldsUpload. Felet finns i valideringsloopen: när ett valfritt fält innehåller en tom första plats i filarrayen returnerar koden från hela funktionen i stället för att hoppa över just den tomma posten.

foreach ( $files[ $id ] as $index => $file ) {
    // Ingen fil har laddats upp i denna plats.
    if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
        return;
    }

    // Kontroll av filtyp och filstorlek körs aldrig för senare poster.
    if ( ! $this->is_file_type_valid( $field, $file ) ) {
        $ajax_handler->add_error(
            $id,
            esc_html__( 'This file type is not allowed.', 'elementor-pro' )
        );
    }

    if ( ! $this->is_file_size_valid( $field, $file ) ) {
        $ajax_handler->add_error(
            $id,
            esc_html__( 'This file exceeds the maximum allowed size.', 'elementor-pro' )
        );
    }
}

Det avsedda beteendet hade varit continue. Då hade loopen hoppat över den tomma posten och fortsatt kontrollera nästa fil. return avbryter i stället all återstående validering, så varken is_file_type_valid() eller filstorlekskontrollen körs för senare filer i samma uppladdningsfält.

Så når en PHP-fil servern

Angriparen skickar uppladdningsfältet som en array med två delar. Den första delen är tom och får felet UPLOAD_ERR_NO_FILE, vilket utlöser den tidiga returen. Den andra delen innehåller en PHP-payload med en filändelse som angriparen väljer, men valideringen granskar aldrig den filen.

Bearbetningsfunktionen process_field() använder däremot korrekt continue för den tomma första posten. Därför fortsätter den till den andra, ovaliderade filen. Funktionen hämtar filändelsen direkt från det filnamn som klienten har skickat och skriver filen till disk.

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 = uniqid() . '.' . $file_extension;
    $filename = wp_unique_filename( $uploads_dir, $filename );
    $new_file = trailingslashit( $uploads_dir ) . $filename;

    if ( is_dir( $uploads_dir ) && is_writable( $uploads_dir ) ) {
        $move_new_file = Plugin::instance()->php_api->move_uploaded_file(
            $file['tmp_name'],
            $new_file
        );

        if ( false !== $move_new_file ) {
            chmod( $new_file, 0644 );
            $record->add_file( $id, $index, [
                'path' => $new_file,
                'url' => $this->get_file_url( $filename ),
            ] );
        }
    }
}

En fil med ändelsen .php hamnar därmed direkt i /wp-content/uploads/elementor/forms/. Angriparen kan sedan begära filens URL och köra PHP-payloaden på servern. Godtyckliga filuppladdningar kan bland annat ge angriparen möjlighet att använda en webshell och ta över hela webbplatsen.

Tidslinje

  1. 24 juli 2026: Säkerhetsbristen i Elementor Pro rapporterades via ett sårbarhetsprogram.
  2. 27 juli 2026: Rapporten validerades, ett proof of concept bekräftades och Elementor fick information om bristen.
  3. 2 augusti 2026: Elementor meddelade att en annan säkerhetsforskare också hade rapporterat samma brist och att en korrigering var under arbete.
  4. 19 augusti 2026: Elementor Pro 4.2.2 släpptes med en fullständig korrigering.

Uppdatera Elementor Pro nu

Kontrollera vilken version av Elementor Pro som körs på varje WordPress-webbplats du ansvarar för. Uppdatera alla installationer med version 4.2.1 eller äldre till 4.2.2, särskilt om de har publicerade formulär med valfria fält för filuppladdning. Granska också sådana formulär och webbplatsens uppladdningskatalog efter oväntade filer om en sårbar version har varit exponerad.

Maja Lindberg

Maja Lindberg

Serverless- och edge computing-utvecklare. Vercel och Cloudflare Workers är mina favoriter. Magin händer i molnets kant.

Alla inlägg

Gå med i HelloWP-communityn!

Chatta med oss om WordPress, webbutveckling och dela erfarenheter med andra utvecklare.

- medlemmar
- online
Gå med

Vi använder cookies för att förbättra din upplevelse. Genom att fortsätta godkänner du vår Cookiepolicy.