PHP2Shell e WordPress: 7 medidas para proteger o site sem trocar de CMS

O WordPress roda sobre o PHP. Por isso, a primeira defesa contra falhas como a PHP2Shell é manter o PHP em uma versão suportada e corrigida, 8.2 ou superior. As outras medidas não corrigem a falha no PHP. Elas reduzem a superfície de ataque e o estrago caso algo passe.

TL;DR: atualize o PHP para uma versão corrigida (8.5.12, 8.4.27, 8.3.36 ou 8.2.35). Em seguida, enxugue plugins, ative atualizações automáticas, coloque um proxy na frente do site, reforce o login, teste antes de atualizar e mantenha um backup diário com restauração testada.

Por equipe Rollin Host

O que é a PHP2Shell e por que ela afeta o WordPress?

Segundo a CyberSec Brazil, o projeto PHP anunciou em 21 de outubro de 2026 a correção emergencial de duas vulnerabilidades críticas: CVE-2026-109618 e CVE-2026-109619, apelidadas de PHP2Shell. As duas receberam nota 9,2 no CVSS v4.0.

O tipo de falha é execução remota de código (RCE) sem autenticação. Os pesquisadores também demonstraram leitura de memória dos processos PHP. O aviso oficial fala em "praticamente todas as versões desde o PHP 5.4".

Os componentes afetados incluem PHP-FPM, Apache mod_php e php-cgi, entre outros runtimes. Com mod_php, uma técnica demonstrada executa código com uma única requisição não autenticada, antes de a aplicação iniciar. Com PHP-FPM, uma das falhas é potencialmente explorável, sem cadeia completa demonstrada. A outra teve execução comprovada, mas depende de uma operação feita pela aplicação.

Há sinais de exploração ativa. A Cloudflare detectou tentativas antes da publicação dos patches, e a watchTowr confirmou tentativas em andamento. Até a última atualização da matéria, não havia confirmação pública de servidor comprometido, e as falhas não constavam no catálogo KEV da CISA.

Resumo: é uma falha grave, ativa e anterior a qualquer plugin.

O que a PHP2Shell ensina sobre segurança no WordPress?

A maior parte dos incidentes em WordPress começa em um plugin desatualizado. A PHP2Shell inverte essa lógica: o risco estava no mecanismo de execução, não em um plugin nem no núcleo do WordPress.

Na prática, um WordPress impecável, com tudo atualizado, continuava exposto se o PHP por baixo estivesse vulnerável. A camada de baixo define o teto da segurança da camada de cima.

Segurança de WordPress não termina no painel do WordPress. Ela começa no servidor.

O recado oficial é direto: "a atualização é a única medida capaz de corrigir completamente as vulnerabilidades". Existem mitigações temporárias que fecham alguns caminhos, mas não protegem por completo:

• CVE-2026-109619: desativar o session.upload_progress (valor 0) e reiniciar os processos PHP.
• CVE-2026-109618: memory_limit = -1 e post_max_size reduzido.

São paliativos para ganhar horas, não para substituir o patch. Daí a ordem das medidas a seguir.

Quais são as 7 medidas para proteger um WordPress, em ordem de impacto?

1. Como saber se o PHP do site está em uma versão corrigida?

Mantenha o PHP sempre em um branch suportado, 8.2 ou superior. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para 7.4, 8.0 e 8.1, que não recebem atualizações regulares, o projeto publicou apenas correções de código-fonte nos branches. Isso exige recompilar e, na prática, é sinal de que é hora de migrar.

Em uma VPS, a verificação é rápida:

php -v
php-fpm -v   # ou php-fpm8.3 -v, conforme a distribuição

Na hospedagem compartilhada, a versão é escolhida no painel DirectAdmin da conta. Se não encontrar a opção, chame o suporte. Antes de subir de versão, confirme a compatibilidade dos plugins (veja o item 6).

2. Quantos plugins um WordPress deveria ter?

Não existe número mágico. A regra é manter só o que é usado e mantido. Plugin sem atualização há muitos meses, tema abandonado ou "tema reserva" instalado é código que roda sem ninguém olhando.

wp plugin list --status=inactive
wp theme list

Remova o que estiver inativo. Desativar não basta, porque o arquivo continua no servidor.

3. Vale a pena ativar atualizações automáticas no WordPress?

Para núcleo e plugins de segurança, sim. A janela entre a publicação de um patch e a exploração encurtou. A própria PHP2Shell já tinha tentativas de ataque antes dos patches.

// wp-config.php
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

wp plugin auto-updates enable --all

O trade-off é que uma atualização automática pode quebrar layout ou integração. Por isso ela anda junto com o backup (item 7).

4. Um proxy/CDN protege contra falhas no PHP?

Protege parcialmente. Um proxy com proteção anti-DDoS na frente do site absorve volume, esconde o IP de origem e permite bloquear padrões de requisição conhecidos. Ele não substitui o patch, porque não corrige o PHP. O que ele faz é ganhar tempo e reduzir ruído.

5. Como proteger o login do WordPress?

Siga três regras:

• Nenhum usuário chamado "admin" ou com o nome do site.
• Senha longa e única, guardada em gerenciador de senhas.
• Autenticação em dois fatores para todo perfil com permissão de administrador.

wp user list --role=administrator

6. Por que testar atualizações antes de aplicar no site?

Subir do PHP 7.4 para o 8.x, por exemplo, pode quebrar plugins antigos. Um ambiente de teste (staging) com cópia do site permite validar a nova versão do PHP e as atualizações sem derrubar a produção. Em uma VPS, basta um subdomínio com cópia dos arquivos e do banco.

7. Qual backup é suficiente para um WordPress?

Backup diário, guardado fora do servidor de produção, com restauração já testada pelo menos uma vez. Backup nunca restaurado é hipótese, não plano.

Resumo: o item 1 corrige a falha, e os itens 2 a 7 limitam o estrago.

O que a hospedagem WordPress gerenciada tira das suas costas?

Na hospedagem compartilhada, de revenda e WordPress da Rollin Host, parte dessa lista já vem resolvida pela infraestrutura. Segundo a nossa Política de Backup:

• Backup automático diário de arquivos, bancos MySQL/MariaDB, e-mail e configurações de domínio, entre 00h e 06h (horário de Brasília).
• 14 pontos diários em rodízio, guardados em infraestrutura externa e geograficamente isolada do servidor de produção, com criptografia em repouso e em trânsito. O RPO é de até 24 h.
• Restauração por ticket em painel.rollinhost.com.br. O prazo de referência é de até 4 horas úteis para arquivo ou banco específico e de até 8 horas úteis para a conta DirectAdmin completa. Uma restauração assistida por mês é gratuita.

Além disso, oferecemos proxy/CDN com borda no Brasil e anti-DDoS, suporte 24/7 em português, migração gratuita e 30 dias de garantia.

Os limites também valem ser ditos. Caches, sessões PHP, filas, /tmp, logs rotativos e buckets de terceiros ficam fora do backup. A responsabilidade é compartilhada: somos a rede de segurança operacional, e dados que não toleram perda acima de 24 h pedem cópia própria.

Em VPS, cloud e dedicados, o backup automático não está incluso, salvo com o add-on "Backup Automático". Snapshots de VPS ajudam em rollback rápido, mas expiram em 30 dias, ficam na mesma infraestrutura do servidor e não substituem backup.

Quer tirar o backup e o suporte da sua lista? Fale com a gente no WhatsApp.

Todo site precisa de PHP?

Não. Um site institucional sem área logada pode ser estático, sem PHP rodando a cada visita. A Agência Rollin, marca irmã, desenvolve esse tipo de site com Astro.

Principais aprendizados

• A PHP2Shell (CVE-2026-109618 e CVE-2026-109619, CVSS 9,2) está no mecanismo do PHP, não no WordPress.
• Só atualizar o PHP corrige a falha. As versões corrigidas vão de 8.2.35 a 8.5.12.
• Mitigações de php.ini são temporárias e parciais.
• Menos plugins, atualização automática, proxy e 2FA reduzem a superfície de ataque.
• Backup diário fora do servidor, com restauração testada, define o tempo de recuperação.

Perguntas frequentes

A PHP2Shell é uma falha do WordPress?

Não. A PHP2Shell está no mecanismo de execução do PHP. O WordPress é afetado porque roda sobre o PHP, assim como qualquer outra aplicação PHP.

Um plugin de segurança resolve a PHP2Shell?

Não. Com mod_php, a exploração demonstrada acontece antes de a aplicação iniciar, ou seja, antes de qualquer plugin carregar. A correção é atualizar o PHP.

Ainda uso PHP 7.4. Estou exposto?

O PHP 7.4 está no intervalo afetado e não recebe atualizações regulares. Há correções apenas em código-fonte. O caminho recomendado é migrar para o PHP 8.2 ou superior após testar o site em staging.

As mitigações no php.ini bastam?

Não. Segundo o aviso oficial, elas reduzem alguns caminhos de ataque, mas não protegem por completo. Servem para ganhar tempo até a atualização.

Snapshot de VPS serve como backup?

Não. O snapshot fica na mesma infraestrutura do servidor e expira em 30 dias. Backup precisa estar em local isolado da produção.

Quer o seu WordPress em uma hospedagem com backup diário e suporte 24/7? Fale com a gente no WhatsApp. A migração é por nossa conta.