Falha crítica no Elementor Pro permite carregar ficheiros PHP sem autenticação

O Elementor Pro corrigiu uma vulnerabilidade crítica de carregamento arbitrário de ficheiros que afeta todas as versões até à 4.2.1, inclusive. A falha pode permitir a um atacante sem sessão iniciada enviar um ficheiro PHP executável para o servidor, executar código remotamente e, em última instância, assumir o controlo completo do site.

Quem está exposto à vulnerabilidade

A falha, identificada como CVE-2026-32475, recebeu uma classificação CVSS de 9,8 em 10. Afeta o Elementor Website Builder Pro, um plugin premium do WordPress com uma estimativa de 6 000 000 de instalações ativas.

A exploração exige uma condição concreta: o site tem de publicar uma página com o widget Form do Elementor Pro e esse formulário tem de incluir pelo menos um campo File Upload que não esteja marcado como obrigatório. Um visitante não autenticado consegue então submeter o formulário especialmente preparado.

A vulnerabilidade foi comunicada através do programa de recompensa de bugs da Wordfence em 24 de julho de 2026. A correção completa chegou com o lançamento do Elementor Pro 4.2.2, em 19 de agosto de 2026.

Como o contorno da validação funciona

O widget Form aceita campos para carregar ficheiros e processa os pedidos através da função ajax_send_form() da classe Ajax_Handler. Visitantes sem autenticação conseguem alcançar esta função; os dados submetidos, incluindo os ficheiros, seguem para um objeto Form_Record e são depois validados e processados pela classe ElementorProModulesFormsFieldsUpload.

O problema está na função validation(). Quando o campo não é obrigatório e o primeiro elemento do array de ficheiros indica UPLOAD_ERR_NO_FILE – isto é, não foi enviado nenhum ficheiro nessa posição – a função usa return. Essa instrução termina a validação de todos os elementos seguintes do mesmo campo, em vez de ignorar apenas a posição vazia.

foreach ( $files[ $id ] as $index => $file ) {
    // Num campo opcional, um primeiro elemento vazio termina a validação.
    if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
        return;
    }

    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 $index => $file ) {
    // Num campo opcional, um primeiro elemento vazio termina a validação.
    if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
        return;
    }

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

O comportamento esperado seria usar continue. Assim, o código ignoraria o elemento vazio e avançaria para validar o ficheiro seguinte. Com return, as verificações de extensão em is_file_type_valid() e de tamanho em is_file_size_valid() deixam de ser executadas para todos os ficheiros posteriores.

Da validação ignorada à execução de código

Para explorar a falha, um atacante submete o campo de carregamento como um array com duas partes. A primeira fica vazia e produz o erro UPLOAD_ERR_NO_FILE, que interrompe a validação. A segunda contém uma payload PHP e um nome de ficheiro com a extensão escolhida pelo atacante, sem que a extensão ou o tamanho sejam verificados.

Apesar de a validação terminar cedo, process_field() usa corretamente continue ao encontrar o primeiro elemento vazio. Por isso, ignora essa entrada mas continua a processar a segunda, que já não passou pelas verificações necessárias.

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

    $uploads_dir = $this->get_ensure_upload_dir();
    // A extensão vem diretamente do nome enviado pelo cliente.
    $file_extension = pathinfo( $file['name'], PATHINFO_EXTENSION );
    $filename = uniqid() . '.' . $file_extension;
    $filename = wp_unique_filename( $uploads_dir, $filename );
    $new_file = trailingslashit( $uploads_dir ) . $filename;

    Plugin::instance()->php_api->move_uploaded_file(
        $file['tmp_name'],
        $new_file
    );
}

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

    $uploads_dir = $this->get_ensure_upload_dir();
    // A extensão vem diretamente do nome enviado pelo cliente.
    $file_extension = pathinfo( $file['name'], PATHINFO_EXTENSION );
    $filename = uniqid() . '.' . $file_extension;
    $filename = wp_unique_filename( $uploads_dir, $filename );
    $new_file = trailingslashit( $uploads_dir ) . $filename;

    Plugin::instance()->php_api->move_uploaded_file(
        $file['tmp_name'],
        $new_file
    );
}

O processamento preserva a extensão extraída do nome fornecido pelo cliente e grava o ficheiro no disco. Um ficheiro com extensão .php pode acabar em /wp-content/uploads/elementor/forms/; se o servidor o executar, basta pedir o URL desse ficheiro para correr a payload PHP.

Este tipo de carregamento arbitrário pode conduzir ao comprometimento integral do site, incluindo através de webshells e de outras técnicas de execução remota de código. A correção elimina o cenário que permitia contornar a validação do tipo e do tamanho dos ficheiros.

Cronologia da correção

1. 24 de julho de 2026: foi recebida uma comunicação sobre a vulnerabilidade de carregamento arbitrário de ficheiros sem autenticação.
2. 27 de julho de 2026: a falha e a prova de conceito foram validadas, tendo o problema sido comunicado à equipa do Elementor.
3. 2 de agosto de 2026: a equipa do Elementor informou que outra pessoa também tinha reportado a vulnerabilidade e que estava a preparar uma correção.
4. 19 de agosto de 2026: foi lançada a versão 4.2.2 do Elementor Pro com a correção completa.

O que deves fazer agora

Confirma a versão do Elementor Pro em todos os sites que administras e atualiza imediatamente qualquer instalação na versão 4.2.1 ou anterior para a 4.2.2 ou uma versão mais recente. Dá prioridade aos sites que publiquem formulários do Elementor Pro com campos File Upload opcionais, pois são os que reúnem a condição necessária para explorar a falha.

Depois de atualizar, revê os ficheiros presentes em /wp-content/uploads/elementor/forms/, sobretudo ficheiros PHP inesperados. Se encontrares indícios de carregamentos suspeitos, trata o site como potencialmente comprometido e investiga a execução de código não autorizado no servidor.