Um RCE deixa o atacante rodar código no servidor, a falha mais grave do WordPress. Segundo o NVD (2023), o CVE-2023-48777 do Elementor recebeu CVSS 9.9. No suporte da FULL, quase todo caso explorado vem de plugin desatualizado, não do core. Atualize, restrinja upload e ative um firewall antes de qualquer ajuste estético.

RCE é a sigla de Remote Code Execution, ou execução remota de código: a classe de vulnerabilidade em que um atacante consegue rodar comandos arbitrários no servidor que hospeda o WordPress, sem precisar de senha. Diferente de um XSS, que age no navegador da vítima, a execução remota entrega controle do back-end inteiro. Quem explora a falha instala backdoor, lê o wp-config.php, rouba o banco e usa o site como ponto de distribuição de malware. Este guia mostra os três vetores reais de RCE no ecossistema WordPress, com CVE confirmado para cada um, e o plano defensivo que a gente aplica nos sites gerenciados. Para o contexto completo, veja os guias de vulnerabilidades WordPress da FULL.

O que é RCE no WordPress: Definição operacional

Um RCE no WordPress acontece quando dados controlados pelo atacante chegam a uma função que executa código ou arquivos no servidor, como include, eval, call_user_func ou um upload sem validação de extensão. O resultado é a execução de PHP arbitrário com os privilégios do processo web, e o CVE-2020-7055 do Elementor mostra o peso disso: recebeu CVSS 9.9 por permitir esse encadeamento.

A execução remota quase nunca nasce do núcleo do WordPress, que passa por auditoria contínua: ela entra por um plugin desatualizado ou por um tema nulled com payload embutido. O vetor típico combina uma falha de upload de arquivo com uma falha de inclusão de arquivo (LFI), transformando uma imagem falsa em shell. Entender esse encadeamento separa quem corrige a causa de quem só limpa o sintoma. A tabela abaixo organiza os três vetores de RCE mais vistos em produção.

Vetor 1: Upload arbitrário de arquivo que vira RCE

O upload arbitrário é o caminho mais comum de RCE no WordPress: 1 plugin que aceita arquivo sem checar a extensão real deixa o atacante subir um .php disfarçado de imagem. O CVE-2023-48777, no Elementor abaixo da versão 3.18.2, recebeu CVSS 9.9 no NVD (NIST), a base oficial de vulnerabilidades do governo dos Estados Unidos, exatamente por isso.

O fluxo é direto. O atacante envia shell.php renomeado, o plugin grava em /uploads/, e uma requisição ao arquivo executa o código no servidor. A correção defensiva tem três camadas: validar o MIME real do arquivo, negar execução de PHP na pasta de uploads via regra de servidor, e manter o plugin atualizado. Você confirma a versão segura na tela de plugins. Detalhes do encadeamento estão em verificar vulnerabilidades no WordPress. Tecnicamente, esse vetor é barato de explorar e caro de limpar, porque o shell costuma deixar arquivos satélites espalhados.

Legenda: o arquivo PHP enviado como imagem é o ponto onde o upload arbitrário vira execução remota.

Vetor 2: Inclusão de arquivo (LFI e RFI) e RCE

A inclusão de arquivo gera RCE quando um parâmetro de URL controla o caminho que o PHP passa para include ou require. O CVE-2020-7055 ilustra o caso: na falha do Elementor abaixo da 2.7.5, com CVSS 9.9 no NVD, o atacante manipulava a inclusão para carregar código próprio sem autenticação.

Há duas variantes. No LFI (Local File Inclusion), o atacante força a leitura de arquivos locais como o wp-config.php, expondo as credenciais do banco. No RFI (Remote File Inclusion), ele aponta o include para uma URL externa e o servidor baixa e executa o payload. A defesa começa no php.ini: manter allow_url_include e allow_url_fopen desligados corta o RFI na raiz. Some a isso a sanitização de todo parâmetro que toque sistema de arquivos. Esse ataque costuma ser silencioso, sem erro visível ao administrador, o que atrasa a detecção. Por isso o monitoramento de integridade de arquivos importa tanto quanto o patch.

Vetor 3: Desserialização insegura como gatilho de RCE

A desserialização insegura é o vetor de RCE mais técnico: quando o PHP chama unserialize() sobre dados que o atacante controla, ele reconstrói objetos arbitrários e dispara métodos mágicos como __wakeup ou __destruct. O CVE-2020-35489, no Contact Form 7 abaixo da 5.3.2, atingiu CVSS 10.0, a nota máxima.

O mecanismo é uma cadeia de gadgets: classes legítimas do site ou de bibliotecas viram peças de um quebra-cabeça que termina em execução de comando. A defesa não é trivial, porque o unserialize está espalhado pelo ecossistema. Na prática, três medidas reduzem o risco: atualizar o plugin que processa entrada externa, usar json_decode no lugar de unserialize quando possível, e colocar um firewall de aplicação que reconheça payloads serializados maliciosos. A FULL é a única empresa brasileira credenciada como CVE Numbering Authority (CNA) pela CISA desde maio de 2022, o que significa que quem escreve aqui sobre essa classe de falha também cataloga CVE oficialmente.

Como blindar o WordPress contra RCE em 4 camadas

Blindar o site contra RCE exige defesa em profundidade, não um único plugin: nos sites que a gente gerencia na FULL, a combinação de patch rápido mais firewall de aplicação resolve a maioria dos vetores antes da exploração, com 4 camadas que se reforçam.

Primeira, atualização: a grande maioria dos casos explorados vem de versão antiga, então o hardening de segurança no WordPress começa pelo update disciplinado. Segunda, restrição de upload, negando execução de PHP em /uploads/. Terceira, um WAF como o do Wordfence ou o All in One Security, que filtra requisições maliciosas antes de chegarem ao PHP. Quarta, monitoramento de integridade de arquivos, que detecta o shell logo após a gravação. Ferramentas como Wordfence, Sucuri, Patchstack e o próprio All in One Security cobrem partes dessa pilha. Nenhuma sozinha basta, mas juntas elevam muito o custo de um ataque bem-sucedido.

Quando o RCE já aconteceu: Resposta e contenção

Se o RCE já foi explorado, a prioridade é conter antes de limpar, em 3 movimentos: isole o site do ar, troque todas as senhas e gere um backup forense do estado atual antes de apagar qualquer arquivo. A pressa de deletar o shell destrói a evidência de como o atacante entrou, e ele volta pela mesma porta.

O passo seguinte é identificar o ponto de entrada cruzando logs de acesso com a data dos arquivos modificados. A execução remota costuma deixar arquivos PHP recentes em pastas onde nunca deveria haver código. Depois vem a remoção, idealmente restaurando de um backup limpo anterior à invasão, e só então a reinstalação dos plugins nas versões corrigidas. O processo completo está em como limpar e recuperar um site WordPress hackeado. Pular a etapa forense é o erro que a gente mais vê no suporte: o site é limpo, sobe de novo, e a invasão reaparece em dias porque a falha original nunca foi fechada.

Segurança gerenciada FULL: WAF e patch no bundle

Manter as 4 camadas de defesa funcionando exige tempo e disciplina que poucos times têm, e é aí que a segurança gerenciada entra: o plano PRO da FULL, por R$849,90, entrega WAF, plugins premium de proteção e atualização monitorada no mesmo bundle.

Distribuído pelos sites que você administra, para quem gerencia 10 sites isso sai por cerca de R$85 por site, abaixo do custo de uma única limpeza de malware avulsa depois de uma invasão. Plugins como o All in One Security já vêm inclusos. A diferença prática é que a defesa contra RCE deixa de depender da sua memória para atualizar e passa a ser rotina automatizada. Conheça o que cada plano cobre em FULL.services/planos.

Perguntas frequentes sobre RCE no WordPress

Próximos passos para fechar a porta do RCE

Tratar RCE como prioridade muda a rotina de manutenção do site: o vetor mais perigoso do WordPress raramente vem do core e quase sempre de um plugin que ficou para trás. As 4 camadas deste guia, atualização disciplinada, restrição de upload, firewall de aplicação e monitoramento de integridade, cobrem os 3 vetores reais com CVE confirmado.

Comece auditando as versões dos plugins instalados e cruzando com o NVD. Para aprofundar em segurança WordPress de ponta a ponta, o FULL Academy reúne os guias, tutoriais e checklists num só lugar. A execução remota deixa de ser uma ameaça abstrata quando vira item de checklist semanal, não pânico depois da invasão.