Hoje, 21 de outubro de 2026, o time do PHP lançou uma atualização de emergência para corrigir duas falhas críticas, chamadas de PHP2Shell. O nome vem de uma ferramenta de ataque que vazou antes da correção ficar pronta.
Se o seu site roda em PHP, isso inclui você. WordPress, WooCommerce, Magento, OpenCart, Joomla, Laravel e a maioria dos sistemas feitos sob medida usam PHP por baixo. E a falha não está no seu site, nem em um plugin. Está no próprio PHP, a base em cima da qual tudo roda.
Este artigo explica, em linguagem simples, o que aconteceu, quem corre risco, qual versão você precisa instalar e o que fazer em cada tipo de hospedagem. No final, tem um checklist para você conferir ainda hoje.
PHP2Shell é o apelido de duas falhas de segurança no PHP:
As duas receberam nota 9.2 de 10 na escala CVSS 4.0, o que as coloca na faixa crítica. Ambas permitem execução remota de código, o famoso RCE.
Em português claro: um desconhecido, sem senha e sem conta, consegue mandar o servidor rodar comandos que ele escolheu. Na prática, é como se alguém de fora ganhasse as chaves do servidor.
Quem encontrou e avisou o time do PHP foram pesquisadores da Wiz, da Calif e da OpenAI.
Esse último ponto muda a urgência. Quando uma falha vaza e já tem ferramenta pronta, o tempo entre a correção sair e o primeiro ataque em massa costuma ser de minutos ou poucas horas, não de semanas.
O PHP afirma que qualquer instalação que atende pedidos web está em risco. Isso cobre as formas mais comuns de rodar PHP:
Ou seja, tanto o servidor pequeno de uma loja quanto uma hospedagem compartilhada de centenas de sites.
Sobre quais versões são afetadas, existe uma diferença que vale entender. Algumas empresas de segurança disseram que a falha existe desde o PHP 5.4. O próprio PHP não confirmou esse ponto. O que é seguro dizer é que todas as versões sem a correção estão vulneráveis, e que versões muito antigas, como a 7.x e a 5.x, merecem ser tratadas como vulneráveis também.
Estas são as versões que trazem a correção:
| Ramo do PHP | Versão corrigida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Se a sua versão está abaixo da indicada no seu ramo, ela está vulnerável. Por exemplo, PHP 8.3.30 precisa subir para 8.3.36.
E quem usa PHP 8.1 ou mais antigo? O projeto PHP não vai lançar correção para essas versões, porque elas já saíram do período de suporte. Isso não significa que você está sem saída:
O PHP ainda não precisa que você entenda o código, mas ajuda saber a ideia por trás. Os dois problemas têm a ver com memória.
CVE-2026-109618: quando o servidor fica sem memória no meio de um pedido, o PHP pode ser interrompido enquanto os dados internos daquele pedido ainda estão pela metade. Na hora de limpar tudo, o PHP trata esses dados quebrados como se estivessem corretos. Um atacante que consegue provocar esse cenário pode aproveitar a bagunça para rodar o próprio código.
CVE-2026-109619: depois que um pedido termina, o PHP libera a memória que ele usou. Mas, em alguns casos, uma referência a essa memória fica guardada. Quando o próximo pedido chega no mesmo processo, ele pode usar essa referência velha antes de tudo ser reiniciado. É como pegar uma chave que já foi trocada, mas que ainda abre a porta.
Repare em um detalhe importante: nas duas falhas, o problema acontece dentro do PHP, antes e fora do código do seu site. Por isso um plugin de segurança ou uma regra no seu sistema não resolve. A correção precisa acontecer no PHP.
Muita gente pergunta se um firewall (WAF) ou um plugin de segurança de WordPress protege contra isso. A resposta honesta é: pode ajudar a dificultar, mas não é a solução.
O motivo é simples. Esses recursos olham o que chega no site e tentam bloquear padrões conhecidos de ataque. Só que a falha está no motor que roda seu site, e ela pode ser explorada de formas que o firewall nem reconhece ainda. Tratar firewall como solução seria como trocar a tranca da porta quando o problema é a parede.
Use essas proteções como camada extra, mas atualize o PHP.
O caminho muda conforme onde o seu site está.
Você normalmente não consegue atualizar o PHP do servidor inteiro. Quem faz isso é a empresa de hospedagem.
Se a hospedagem demorar ou der respostas vagas, vale considerar seriamente uma troca. Hospedagem que não corrige falha crítica no mesmo dia é um risco para o seu negócio. Entenda melhor o que cada tipo de hospedagem entrega antes de decidir.
Aqui a responsabilidade é sua (ou de quem cuida do servidor para você). O processo geral é:
apt ou dnf.php-fpm ou o Apache. Sem reiniciar, o processo antigo continua na memória e o servidor segue vulnerável.Se você usa um VPS e não tem ninguém para cuidar disso, esse é um bom momento para contratar suporte técnico.
Se o seu site roda em container, não basta atualizar a máquina. É preciso trocar a imagem por uma que já tenha a versão corrigida e subir o container de novo. As imagens oficiais do PHP já estão sendo atualizadas para as versões corrigidas. Confira o número da versão da sua imagem e refaça o deploy.
Um detalhe que confunde muita gente: nessas distribuições, o número da versão do PHP pode não mudar mesmo depois da correção. Um servidor que mostra PHP 8.3.6 pode estar totalmente corrigido, porque a distribuição aplicou o conserto sem mudar o número.
Por isso, nesse caso, não confie só em php -v. Veja o aviso de segurança da própria distribuição e confira se o pacote instalado já inclui a correção das duas CVEs.
Atualizar não adianta se o site continua rodando no PHP antigo. Faça esta checagem:
php -v para ver a versão da linha de comando. Mas atenção: ela pode ser diferente da versão que atende o site.Anote a versão que atende o site e compare com a tabela acima, lembrando da exceção das distribuições Linux.
Atualizar fecha a porta, mas não expulsa quem já entrou. Como existem relatos de ataque em andamento, vale olhar com atenção nos próximos dias. Alguns sinais de alerta:
uploads, wp-content ou pastas temporárias.Se algo disso aparecer, não tente resolver sozinho no improviso. Leia o guia como saber se meu site WordPress foi hackeado e guarde os logs do servidor, porque eles ajudam a entender o que aconteceu.
Para quem monitora servidores, o time de segurança recomenda ficar de olho em alguns comportamentos: o processo do PHP abrindo um terminal ou rodando ferramentas de download, comandos de reconhecimento rodando com o usuário do servidor web, e criação de arquivos novos na pasta pública.
Se você quer um passo a passo direto, é este:
Uma atualização de emergência dentro do mesmo ramo (por exemplo, de 8.3.30 para 8.3.36) costuma ser tranquila, porque traz só correções. Já pular de versão grande, como de 7.4 para 8.3, pode quebrar plugins e temas antigos.
Se você precisa subir de versão grande:
Mas atenção: quando o risco é de invasão total do servidor, site fora do ar por algumas horas costuma custar menos do que site invadido. Se não der para testar com calma, priorize a segurança e corrija o que quebrar depois.
Esse caso deixa uma lição que serve para qualquer empresa com site: a segurança não depende só do que você instala, mas do que está por baixo. Você pode ter o plugin mais bem feito do mundo e, mesmo assim, ficar exposto por causa da versão do PHP.
Quem tem manutenção de site contratada geralmente nem fica sabendo da correria de hoje, porque alguém já está olhando as versões, confirmando a atualização e monitorando o servidor. Quem não tem acaba descobrindo o problema só quando o site cai ou é invadido.
Se você quer entender o risco de deixar isso de lado, leia o que acontece sem manutenção no WordPress e quanto custa a manutenção de um site WordPress. O custo de manter costuma ser bem menor do que o custo de limpar um site invadido, recuperar a reputação do domínio e explicar para clientes o que aconteceu.
É o apelido de duas falhas críticas no PHP, a CVE-2026-109618 e a CVE-2026-109619. Elas permitem que alguém sem login rode comandos no servidor. O nome vem de uma ferramenta de ataque que vazou antes da correção ser lançada.
Sim, se ele roda em um PHP sem a correção. O WordPress não tem culpa nenhuma aqui, o problema está no PHP, que roda por baixo de qualquer site WordPress, WooCommerce e da maioria dos CMS.
As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem está em uma versão menor dentro desses ramos precisa atualizar.
O projeto PHP não vai lançar correção para essas versões. Você pode pedir ao seu fornecedor (distribuição Linux ou empresa de suporte de longo prazo) se existe uma versão corrigida por conta deles, ou subir para uma versão com suporte. Deixar uma versão sem suporte aberta na internet não é uma boa ideia.
Entre em contato com a hospedagem hoje e pergunte se o servidor já recebeu a correção das duas CVEs. Você normalmente não consegue atualizar o PHP do servidor inteiro, mas consegue confirmar a versão do seu site no painel e escolher uma mais nova.
Pode ajudar como camada extra, mas não resolve. A falha está no próprio PHP, então a correção definitiva é atualizar o PHP.
Não necessariamente. Nessas distribuições, a correção costuma ser aplicada sem mudar o número da versão. Consulte o aviso de segurança da sua distribuição e confira se o pacote instalado já inclui a correção das duas CVEs.
Há relatos de tentativas de exploração. Como o código de ataque vazou e a correção acabou de sair, a recomendação é atualizar imediatamente, sem esperar a próxima janela de manutenção.
Sim: reinicie o serviço do PHP (quando você administra o servidor), confirme a versão que realmente atende o site e procure sinais de invasão, como arquivos novos, usuários desconhecidos e tarefas agendadas estranhas.
Dentro do mesmo ramo, é raro. Já subir de uma versão muito antiga para uma bem nova pode causar incompatibilidades com plugins e temas. Faça backup e, se possível, teste antes em um ambiente separado.
O PHP2Shell é um daqueles casos em que não dá para deixar para depois. São duas falhas críticas no PHP, que permitem rodar comandos no servidor sem login, com correção já disponível e com relatos de ataque acontecendo.
O caminho é direto: descobrir qual PHP o seu site usa, atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou confirmar o backport da sua distribuição), reiniciar o serviço, conferir a versão que atende o site e olhar com atenção os sinais de invasão. Quem está em PHP 8.1 ou mais antigo precisa de um plano de subida de versão ou de um fornecedor que garanta a correção.
Se você não tem certeza de qual PHP seu site usa, não sabe falar com a hospedagem ou quer alguém conferindo isso por você, a manutenção de sites WordPress cobre exatamente esse tipo de situação: versão do PHP, atualizações, backup e monitoramento. Para empresas que cuidam de vários sistemas, o suporte de TI para pequenas empresas também entra nessa conta.
Help Net Security. “PHP2Shell: Critical PHP vulnerabilities patched, update now!”. Resume as duas falhas, o tipo de problema de cada uma e as versões corrigidas.
The Hacker News. “PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge”. Cobre a antecipação do lançamento, os pesquisadores que encontraram as falhas e os relatos de tentativas de ataque.
Brandefense. “PHP2Shell: Two Critical PHP Flaws Reported as RCE”. Detalha quais formas de rodar PHP estão em risco e esclarece quais faixas de versão o PHP confirmou e quais não.
Aikido. “What you need to know about PHP2shell”. Linha do tempo do vazamento, da divulgação antecipada e orientações para imagens Docker.
PatchMon. “PHP2Shell: Patching the Critical PHP RCE Across Your Fleet”. Explica por que o número de versão de distribuições Linux pode não refletir a correção.
Sansec. “php2shell”. Pesquisa que chamou atenção para o vazamento da ferramenta e para o alcance das falhas.
Seu site WordPress abre normalmente, mas isso não significa que está seguro. Entenda os problemas silenciosos que a manutenção profissional resolve antes que você perceba.
A stack certa ajuda, mas não substitui experiência. Entenda por que um site de alta performance depende mais de quem desenvolve do que da tecnologia escolhida.
Aprenda como fazer um site HTTPS do zero: o que é SSL, como instalar o certificado, forçar o redirecionamento 301, evitar conteúdo misto e manter o ranking no Google.