| Vetor de ataque | Mecanismo técnico | CVE real (CVSS) | Defesa primária |
|---|---|---|---|
| Upload arbitrário | Arquivo .php enviado como imagem e executado depois | CVE-2023-48777 (9.9) | Validar MIME e bloquear PHP em uploads |
| Inclusão de arquivo (LFI/RFI) | Parâmetro controla o caminho de include do PHP | CVE-2020-7055 (9.9) | allow_url_include desligado, sanitização |
| Desserialização insegura | Objeto PHP malicioso reconstruído por unserialize | CVE-2020-35489 (10.0) | Atualizar plugin, WAF com regra de payload |
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.É raro, mas possível. O núcleo do WordPress passa por auditoria contínua e quase não registra execução remota há anos. Quando acontece sem plugin externo, costuma envolver um tema nulled com payload embutido ou uma configuração de servidor frágil, como `allow_url_include` ligado. Na prática, a grande maioria dos casos vem de plugin ou tema de terceiros, não do core.
Porque a execução remota roda código no servidor, enquanto o XSS age no navegador da vítima. Um XSS pode roubar sessão ou injetar script, mas o RCE entrega o back-end inteiro: leitura do wp-config.php, acesso ao banco e instalação de backdoor. Por isso essas falhas recebem CVSS alto, como o 10.0 do CVE-2020-35489 no Contact Form 7.
Consulte o número da versão instalada contra o registro de CVE do plugin. O NVD (NIST) lista cada identificador com a versão afetada e a versão de correção. Por exemplo, o Elementor abaixo da 3.18.2 tinha o CVE-2023-48777, com CVSS 9.9. Um scanner de vulnerabilidade automatiza esse cruzamento e avisa antes da exploração.
Reduz muito, mas não zera. Atualizar fecha as falhas já catalogadas, que respondem pela maioria dos casos explorados. Resta o risco de um zero-day, falha ainda sem patch. Por isso a defesa contra RCE combina atualização com WAF e restrição de upload: as camadas extras protegem na janela entre a descoberta da falha e o lançamento da correção.
Um WAF como o do Wordfence ou All in One Security bloqueia boa parte das requisições maliciosas, mas não substitui o patch. Ele filtra padrões conhecidos de payload e ganha tempo, porém uma falha nova pode escapar das regras. A proteção real vem da soma: WAF na frente, plugin atualizado atrás e upload restrito no meio.