Falha PHP (PHP2Shell): o que aconteceu e como proteger seu site WordPress

Duas falhas críticas no PHP já estão sendo usadas em ataques que executam comandos no servidor sem senha. Veja quem está exposto, como checar o seu site e como corrigir.

Douglas Medina 22 out 2026 13 min de leitura

Atualizado em 23/10/2026, às 22h45

Em 21 de outubro de 2026 o PHP lançou uma correção de emergência para duas falhas críticas. Elas ficaram conhecidas como PHP2Shell e têm os registros CVE-2026-109618 e CVE-2026-109619, as duas com nota 9.2 de 10. Com elas, qualquer pessoa na internet pode executar comandos no servidor de um site sem precisar de senha.

Transcrição do vídeo

Uma falha deixou quase todo site WordPress com a porta aberta. Ela está no PHP, a linguagem que roda por trás do site. Por ela, qualquer pessoa na internet executa comandos no seu servidor, sem senha. Dá pra trocar páginas, levar os leads ou tirar o site do ar. Os detalhes vazaram antes da correção, e os ataques já começaram. Atualizar o WordPress e os plugins não fecha essa porta. Quem cuida do servidor precisa atualizar o PHP. Pergunte hoje se já foi feito. Cuidamos da segurança de sites, e os nossos clientes já estão protegidos.

O que é o PHP, e por que isso pega quase todo site

O PHP é a linguagem que roda no servidor e monta as páginas do site antes de elas chegarem ao navegador. O WordPress é escrito em PHP, assim como o Drupal, o Joomla e o Magento. Segundo a W3Techs, o PHP está em 69,3% dos sites cuja linguagem de servidor é conhecida.

Quando a falha está no PHP, ela fica abaixo do WordPress, do tema e dos plugins. Por isso um site WordPress impecável, com tudo atualizado, continua exposto.

Ataque PHP: o que as duas falhas permitem

O ataque hacker ao PHP já está acontecendo desde 17 de outubro. As duas falhas deixam o invasor rodar comandos no servidor sem login. Com esse acesso ele pode:

trocar páginas do site por conteúdo dele;
levar os dados do formulário, como os leads e os contatos dos clientes;
instalar um programa malicioso que fica escondido no servidor;
tirar o site do ar.

A segunda falha, CVE-2026-109619, também pode vazar dados que estão na memória do servidor. Como o ataque funciona, em linguagem simples, está no post PHP2Shell: como funciona o ataque.

Quem está exposto

A falha existe desde o PHP 5.4. Um servidor está exposto quando roda uma destas versões:

Versão do PHP	Situação	Versão corrigida
8.5	exposta abaixo da 8.5.12	8.5.12
8.4	exposta abaixo da 8.4.27	8.4.27
8.3	exposta abaixo da 8.3.36	8.3.36
8.2	exposta abaixo da 8.2.35	8.2.35
7.4 a 8.1	exposta	sem versão oficial; existe só um remendo no código-fonte
5.4 a 7.3	exposta	sem correção, porque essas versões não recebem mais suporte

O jeito como o PHP roda no servidor não muda a resposta. PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed estão todos expostos. O risco é maior no mod_php, onde o ataque acontece antes de qualquer código do site rodar.

Os pesquisadores que acharam a falha mostraram o ataque funcionando em versões específicas do WordPress, do Drupal, do Joomla e do Magento. As estimativas falam em 1,3 a 1,9 milhão de servidores expostos na internet.

A história, de 2012 até hoje

2012: o defeito entra no PHP. O código com problema chega no PHP 5.4 e fica escondido por 14 anos.

2024: o aviso que ninguém seguiu. Um desenvolvedor do PHP encontra numa auditoria o erro de memória por trás de uma das falhas. A equipe não chega a um acordo sobre a correção. Sem nenhum ataque conhecido, o assunto não vira prioridade.

Agosto de 2026: a inteligência artificial acha a falha. Em 19 de agosto, a Wiz Research encontra a primeira falha usando modelos de IA (Gemini e GPT) e uma ferramenta própria. No dia 20 ela consegue invadir o Drupal sem login, e no dia 21 o WordPress. No dia 24 ela avisa a equipe de segurança do PHP. A Calif achou a mesma falha em agosto por conta própria, com o modelo da OpenAI, dentro do projeto "Patch the Planet".

21 de setembro: começa o sigilo. O PHP confirma as falhas e começa a preparar a correção em segredo, combinada para sair em 22 de outubro. Google Cloud, Cloudflare, AWS, Microsoft, Fastly e Vercel são avisados para preparar proteções.

17 de outubro: o primeiro ataque. Quatro dias antes de qualquer aviso público, a rede de armadilhas da Amazon registra uma tentativa de ataque vinda de uma rede de anonimização. A Amazon não sabe como o atacante soube da falha.

20 de outubro: o vazamento. Um post no Hacker News anuncia as duas falhas, com os números e uma nota 10 de 10. O post é apagado, mas os prints já tinham se espalhado. A watchTowr confirma que as falhas são reais, e a Calif publica por engano um vídeo do ataque. O PHP antecipa a correção para o dia seguinte.

21 de outubro: a correção e a corrida. Na madrugada, a Amazon vê novos ataques vindos de grupos diferentes e conclui que a falha passou a ser explorada em larga escala. Às 10h34 de Brasília, os avisos técnicos aparecem no GitHub, minutos antes da correção oficial. O PHP lança as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e a Cloudflare liga regras de bloqueio para todos os clientes.

21 de outubro: sites tirados do ar por precaução. A pedido de agências de segurança europeias, saem do ar o portal do governo holandês, serviços dos governos da Dinamarca e da Finlândia e sites do Ministério do Interior da França. A NSA, nos Estados Unidos, recomenda tirar do ar quem não puder atualizar. A Wikimedia desliga vários serviços de apoio da Wikipédia enquanto corrige os servidores.

22 de outubro: a falha vira manchete. A CNN, o New York Times e o The Guardian dão a notícia. A Sophos libera bloqueios nos firewalls dela, e a watchTowr alinha as versões afetadas ao aviso oficial do PHP. Os servidores dos clientes do plano mensal da Boldman estão corrigidos desde o dia anterior.

23 de outubro: hoje. Ainda não há invasão confirmada em público. A Amazon diz que não está claro se alguma tentativa funcionou num servidor real, e a Sophos não achou sinal de ataque no portal que tirou do ar. A CISA ainda não pôs as falhas na lista de falhas exploradas. As correções chegam às distribuições: Debian, Red Hat, Ubuntu, cPanel e Plesk já publicaram pacotes corrigidos, inclusive para o PHP 7.4 ao 8.1. A Palo Alto avisa que os próprios firewalls rodam PHP afetado e ainda não têm correção.

O que se sabe e o que ainda não se sabe

Já se sabe	Ainda não se sabe
As duas falhas são reais e graves, com nota 9.2.	Quantos sites foram de fato invadidos. Até 23/10 nenhum caso tinha sido confirmado em público, nem pelo BSI, o órgão de segurança da Alemanha, nem pela Amazon.
A correção existe para o PHP 8.2 ao 8.5.	Quem vazou a falha e como o atacante de 17/10 soube dela.
Houve ataques antes e depois da correção. Segundo a Amazon, as tentativas agora estão espalhadas pela internet.	Se o ataque de 17/10 funcionaria num servidor real.
O WordPress, o Drupal, o Joomla e o Magento podem ser invadidos sem login.	Se a CISA, agência de segurança dos EUA, vai confirmar os ataques. Até 23/10 ela não tinha posto as falhas na lista de falhas exploradas.
Os sites que saíram do ar saíram por precaução.	Se o PHP 7.4 ao 8.1 vai ganhar versão oficial corrigida. Por enquanto existem um remendo no código-fonte e pacotes corrigidos das distribuições.

Este dossiê é atualizado conforme surgem fatos novos, e cada fato tem a fonte listada no fim da página.

Atualizar o WordPress não resolve

Essa é a parte que mais engana. O WordPress.org avisou que não vai lançar atualização, porque a correção é atualizar o PHP. Atualizar o WordPress, o tema e os plugins não protege contra o PHP2Shell.

Quem atualiza o PHP depende de onde o site está hospedado:

Tipo de hospedagem	Quem corrige
Hospedagem gerenciada de WordPress	A empresa de hospedagem corrige. Confira o aviso dela e cobre o suporte se não houver nada até o fim do dia.
Hospedagem compartilhada, com cPanel ou parecido	A empresa de hospedagem libera a correção. No painel costuma dar para escolher a versão do PHP.
VPS ou servidor próprio	Ninguém corrige por você. Quem administra o servidor instala o PHP novo e reinicia o PHP.

Como saber se o seu site está exposto

No painel do WordPress, a versão do PHP aparece em Ferramentas, Saúde do Site, Informação, na seção Servidor. Só o número não basta. Muitos servidores Linux recebem a correção sem mudar o número da versão, e por isso a resposta certa vem de quem cuida do servidor. Na hospedagem com CloudLinux, como a Hostinger, o PHP corrigido continua aparecendo como 8.3.35. A correção entrou no pacote sem mudar o número.

O passo a passo completo, com as perguntas certas para fazer à hospedagem, está no post PHP vulnerabilidade: como saber se o seu site está exposto.

Se não der para atualizar hoje

O PHP diz que atualizar é a única correção completa. Enquanto ela não vem, quem administra o servidor pode reduzir o risco:

desligar o recurso session.upload_progress, que o WordPress não usa e que fecha um caminho da segunda falha;
ajustar o limite de memória do PHP, o que estreita a primeira falha sem fechá-la;
reiniciar o PHP depois de qualquer mudança;
passar o site pela Cloudflare, que ligou regras de bloqueio até no plano grátis. Os atacantes já alteram o código para escapar dessas regras.

Nenhuma dessas medidas deixa o site seguro sozinha. Em hospedagem compartilhada ou gerenciada, peça isso à hospedagem em vez de mexer na configuração.

Sites no PHP 8.1 ou anterior

Para essas versões o PHP não lança correção. O caminho é migrar para o PHP 8.2 ou mais novo. O WordPress.org e o centro de segurança do Reino Unido (NCSC) recomendam tirar do ar o site em servidor próprio que não possa ser atualizado logo. A CISA, agência de segurança dos EUA, recomenda o mesmo para todo sistema com PHP 8.1 ou anterior. No Brasil, o CTIR Gov pede na Recomendação Técnica 19/2026 que o acesso pela internet seja restrito no que não der para corrigir.

Tema e plugin antigos podem quebrar no PHP novo. Antes de trocar, faça um backup completo, teste numa cópia do site e confira as páginas e os formulários principais depois da troca.

O passo a passo da troca, painel por painel, está no post Como atualizar o PHP do WordPress sem quebrar o site.

Depois de corrigir

Os ataques começaram antes da correção. Por isso, atualizar fecha a porta mas não diz se alguém já entrou. Vale checar se apareceram usuários administradores novos, arquivos alterados no servidor, páginas com conteúdo estranho e redirecionamentos que você não criou.

Os detalhes técnicos das duas falhas, com versões, configurações e formas de detecção, estão na ficha técnica do CVE-2026-109618 e do CVE-2026-109619.

Perguntas frequentes

Meu site é pequeno. Alguém vai atacar?
O ataque é automático. Os robôs varrem a internet atrás de servidores expostos, sem olhar o tamanho da empresa.

Minha hospedagem é grande. Já estou protegido?
Várias hospedagens corrigiram em 21/10, e outras ainda estavam corrigindo. Confirme com a sua hospedagem se o PHP foi atualizado depois de 21 de outubro.

Tenho Cloudflare. Preciso fazer algo?
Sim. A Cloudflare bloqueia os ataques conhecidos que passam por ela, mas o invasor pode chegar direto ao servidor. Ela ajuda enquanto a correção não vem e não substitui a correção.

Existe código de ataque público?
Circulam códigos que dizem explorar a falha, e o centro de segurança do Canadá confirma que eles existem. Na data da correção, a equipe do PHP não tinha achado nenhum que funcionasse. Código de ataque não verificado pode trazer vírus para quem o roda.

Algum site já foi invadido?
Até 23/10 nenhuma invasão foi confirmada em público. As tentativas existem desde 17/10, mas a Amazon diz que ainda não está claro se alguma funcionou num servidor real. Não ter caso confirmado não quer dizer que o seu servidor esteja seguro.

A CISA confirmou os ataques?
Ainda não. Até 23/10 as duas falhas não estavam no catálogo de falhas exploradas da CISA. A agência pede que quem não pode atualizar, ou roda PHP 8.1 ou anterior, tire o site do ar até corrigir.

Meu site roda PHP 7.4, 8.0 ou 8.1. Tem correção?
Não existe versão oficial nova. Existe um remendo no código-fonte, e Debian, Red Hat, Ubuntu, cPanel e Plesk publicaram pacotes corrigidos para esses ramos. Na hospedagem compartilhada, pergunte se o pacote do PHP foi atualizado depois de 21/10. O caminho seguro continua sendo migrar para o PHP 8.2 ou mais novo.

Desligar o “upload progress” do PHP resolve?
Não sozinho. O PHP diz que nenhuma mudança de configuração fecha a falha por completo. A Amazon sugere bloquear envio de arquivo em formulário só como medida de emergência, testando antes se o site continua funcionando.

Já corrigi. Preciso verificar mais alguma coisa?
Sim. Os ataques começaram antes da correção, então vale procurar no registro do servidor pedidos com o texto PHP_SESSION_UPLOAD_PROGRESS desde 17/10. Também vale conferir usuários administradores novos, arquivos alterados e programas estranhos rodando no servidor.

Como saber se o meu servidor foi corrigido, se o número da versão não mudou?
Pergunte a quem cuida do servidor se o pacote do PHP foi atualizado depois de 21/10. Em CloudLinux, Debian e Red Hat a correção entra no pacote sem mudar o número. Ferramentas de varredura como Nessus e Greenbone já detectam a falha.

Como a Boldman tratou a falha

Os clientes do plano mensal da Boldman não precisaram fazer nada. Os servidores foram atualizados em 21 de outubro, no mesmo dia em que a correção saiu.

Se o seu site ainda não foi corrigido, a gente faz a correção, um teste de segurança ou assume o cuidado do site num plano mensal. Fale com a gente no WhatsApp: (51) 2165-9690.

Fontes

Continue lendo

Ver todos os posts

Segurança

O próximo post de segurança no seu e-mail

Um e-mail quando sair conteúdo novo sobre o assunto que você acabou de ler. Nada além disso.