PHP2Shell explicado: quem precisa corrigir o seu site e como fazer isso

Em 21 de outubro de 2026, foi divulgada uma falha de segurança crítica no PHP, a linguagem de programação por trás de cerca de três em cada quatro sites. Sites governamentais da Holanda, da França e do Canadá foram tirados do ar por precaução, e a agência sul-coreana KISA (Korea Internet & Security Agency) publicou orientações de resposta urgente. A comunidade de segurança chama o caso de PHP2Shell.

A boa notícia: as correções já foram lançadas e a maioria das grandes empresas de hospedagem já as aplicou. O problema é que quem corrige o seu site depende totalmente de como ele está hospedado. Este guia explica quem precisa agir agora, quais correções existem e como as principais hospedagens resolveram a situação.

Pontos principais

• O PHP2Shell são duas falhas críticas de execução remota de código no próprio PHP (CVSS 9.2) que podem ser exploradas sem login.
• Atualizar o WordPress ou os plugins não resolve. É o PHP que precisa ser corrigido.
• As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35 ou posteriores. O PHP 8.1 e anteriores não têm versão oficial.
• Em hospedagem compartilhada ou gerenciada, a sua hospedagem corrige o PHP, mas você deve confirmar. Em um VPS ou servidor dedicado, você mesmo precisa corrigir e reiniciar o PHP.
• Uma terceira falha (CVE-2026-115560) tem uma solução temporária: session.upload_progress.enabled = 0.

O que é o PHP2Shell?

PHP2Shell é o nome dado a duas vulnerabilidades de execução remota de código (RCE) encontradas no núcleo do PHP.

• CVE-2026-109618: uma falha de corrupção de memória acionada pelo abuso de situações de falta de memória
• CVE-2026-109619: uma falha que reutiliza um estado global já liberado

As duas têm gravidade CVSS 9.2 de 10, e o mais assustador é que podem ser exploradas sem login e sem conta. As falhas estão no próprio processamento de requisições do PHP, e não no WordPress ou em um plugin, então o ataque funciona antes mesmo de o código do seu site ser executado. Manter o WordPress totalmente atualizado não adianta se o PHP não estiver corrigido.

Acredita-se que praticamente todas as versões do PHP desde a 5.4 sejam afetadas e, segundo a W3Techs, cerca de 75% dos sites com linguagem de servidor conhecida usam PHP. As falhas foram descobertas pelas empresas de segurança Calif e Wiz durante uma análise com modelos de IA (OpenAI GPT-5.6 Sol e Google Gemini 4 Argon) e relatadas à equipe do PHP em agosto. Os detalhes vazaram enquanto as correções eram preparadas, o que antecipou a divulgação em um dia. Tentativas reais de ataque começaram no próprio dia da divulgação, e a Cloudflare registrou milhões delas. Ainda não foi confirmada nenhuma invasão bem-sucedida em grande escala, mas as ferramentas de ataque continuam evoluindo, então “ainda não fomos atacados” não é motivo para relaxar.

Depois, em 23 de outubro, foi divulgada uma terceira falha relacionada, a CVE-2026-115560. Ela só funciona com certas combinações de configuração, por isso a equipe do PHP recomenda uma solução temporária em vez de uma correção de emergência. Os detalhes estão mais abaixo, na seção de correções.

Quem precisa agir?

Tudo se resume a uma pergunta: “Quem administra o PHP do meu site?” A resposta define o que você precisa fazer.

Quais correções estão disponíveis?

Correções oficiais (21 de outubro de 2026)

Se você administra o próprio servidor, o caminho mais comum é atualizar pelos pacotes da sua distribuição. Ubuntu, Debian, AlmaLinux, Amazon Linux e outras já publicaram pacotes corrigidos.

# Exemplo para Debian / Ubuntu
sudo apt update
sudo apt upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

Se você não reiniciar, a correção não é aplicada. Se você atualizar os pacotes mas não reiniciar o PHP-FPM ou o Apache, o PHP antigo que continua carregado na memória segue atendendo às requisições. As orientações da KISA alertam explicitamente sobre isso. Se você usa o repositório Remi em um sistema da família CentOS, saiba que o Remi não tinha atualização no dia da divulgação, então considere os pacotes padrão da sua distribuição ou compilar o PHP por conta própria.

PHP 8.1 ou anterior: backports

O PHP 8.1, 8.0 e 7.4 já não têm suporte, então não há versões oficiais corrigidas. Mesmo assim, há opções.

• A equipe do PHP publicou patches mínimos de código-fonte (backports) para 7.4, 8.0 e 8.1. Você pode aplicá-los se compilar o PHP por conta própria.
• Os pacotes para Ubuntu e Debian do repositório de Ondřej Surý incluem backports da 5.6 até a 8.1.
• Algumas hospedagens (Hostinger, 20i, xCloud e outras) publicaram compilações próprias corrigidas, incluindo versões antigas. Primeiro verifique se a sua hospedagem oferece um backport.

Mas os backports são apenas uma solução provisória. Este é um bom momento para migrar para o PHP 8.3 ou posterior.

Terceira falha CVE-2026-115560: solução temporária até a correção

A terceira falha, divulgada em 23 de outubro, está ligada ao recurso de progresso de upload de sessão (session upload progress) do PHP. Ela é difícil de acionar com configurações comuns, então não há correção de emergência. A correção virá na próxima versão regular. Até lá, a solução oficial é uma única configuração:

; Adicione ao php.ini ou à configuração do pool do PHP-FPM e reinicie o PHP
session.upload_progress.enabled = 0

A menos que o seu site mostre uma barra de progresso de upload, você não perde quase nada. Como mostra a tabela de hospedagens abaixo, as grandes empresas já desativaram essa opção no nível do servidor.

Mitigações temporárias antes da correção (não resolvem por completo)

• Desativar o session.upload_progress: o mesmo que acima. Bloqueia um caminho de ataque conhecido da CVE-2026-109619.
• Regras WAF da Cloudflare: a Cloudflare aplicou regras de emergência em todos os planos, incluindo o gratuito, pouco antes da divulgação. Mas a própria Cloudflare diz que é “uma proteção temporária, não um substituto da correção”, e já foram vistas tentativas de contorná-la.
• Regras de firewall da sua hospedagem: ferramentas como o ModSecurity bloqueiam padrões de ataque na frente do servidor. Elas ganham tempo, mas não resolvem a raiz do problema.

A posição oficial da equipe do PHP é clara: “Não existe mitigação completa. Atualizar é a única opção segura.”

Como as principais hospedagens responderam

Felizmente, as hospedagens conhecidas agiram rápido. Abaixo está a situação de cada empresa, com base nos comunicados oficiais. O padrão em comum: primeiro bloquear os ataques com regras de firewall e configurações, e depois distribuir a correção para todos os servidores assim que ela foi lançada.

A situação de cada hospedagem continua mudando, então, se a sua não estiver na lista ou se você não tiver certeza, confira diretamente a página de status e os comunicados dela. Visto pelo outro lado: se a sua hospedagem ficou em silêncio, sem nenhum comunicado, isso por si só já é um sinal de alerta.

Como verificar o seu site (3 minutos)

1. Verifique a versão do PHP: no WordPress, vá em Ferramentas → Saúde do site → Informação → Servidor e veja a versão do PHP.
2. Compare com as versões corrigidas: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 ou posterior significa que o seu site está corrigido.
3. Não conclua que um número menor significa que você está exposto: algumas hospedagens, como a Hostinger, mantêm o número da versão e corrigem a compilação. Nesse caso, o critério é se a Build Date no PHP Info do painel da hospedagem é de 21 de outubro de 2026 ou posterior.
4. Com PHP 8.1 ou anterior: confira os comunicados da sua hospedagem ou pergunte se ela oferece backport. Se não oferecer, agende uma atualização.
5. Em um VPS ou servidor dedicado: execute php -v no terminal e confirme que é o mesmo PHP que o seu servidor web realmente usa (segundo o phpinfo). É comum várias versões do PHP conviverem no mesmo servidor.

Corrigir não é o fim: verificações pós-correção

Uma correção só bloqueia ataques futuros. Se o seu site foi invadido antes da correção, ela não desfaz o estrago. Como os detalhes vazaram antes da correção e os ataques começaram antes da divulgação, a KISA recomenda o seguinte:

• Revise os logs: procure requisições suspeitas nos logs do servidor web e do PHP, incluindo o período anterior à correção.
• Procure web shells: verifique se há arquivos PHP criados ou modificados recentemente, contas de administrador desconhecidas ou tarefas cron estranhas.
• Troque as credenciais: nos servidores que ficaram expostos, troque as senhas do banco de dados, as chaves de API e as senhas de administrador.
• Garanta os backups: guarde fora do servidor backups testados e restauráveis de antes e depois da correção.
• Se encontrar sinais de invasão, não reinicie o servidor (você perderia as evidências na memória). Corte o acesso à rede e comunique um profissional.

Checklist final

• Confirme a versão do PHP do seu site e quem administra o PHP
• Verifique se você está em uma versão corrigida (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) ou se a data de compilação é de 21 de outubro ou posterior
• Em VPS ou servidor dedicado, atualize o PHP você mesmo e sempre reinicie o serviço do PHP
• Com PHP 8.1 ou anterior, verifique se há backport e planeje a atualização para o 8.3 ou posterior
• Desative o session.upload_progress por causa da terceira falha (ou confirme que a hospedagem fez isso)
• Revise os logs e procure web shells do período anterior à correção
• Inclua no inventário os sites de teste, staging e eventos esquecidos

Perguntas frequentes

Atualizar o WordPress me protege do PHP2Shell?

Não. As falhas estão no próprio PHP, não no WordPress nem nos plugins. Só uma compilação corrigida do PHP protege o seu site.

Uso hospedagem compartilhada. Preciso fazer alguma coisa?

Normalmente a hospedagem corrige o PHP por você, mas confirme. Verifique se a sua versão do PHP está corrigida ou se a data de compilação do PHP é de 21 de outubro de 2026 ou posterior.

A Cloudflare basta para manter o meu site seguro?

Não. As regras WAF da Cloudflare são uma proteção temporária, e já foram vistas tentativas de contorná-las. O seu servidor de origem continua precisando da correção do PHP.

Plataformas que não usam PHP, como o Wix, são afetadas?

Não. O PHP2Shell é uma falha do PHP no servidor, então plataformas que não rodam em PHP, como o Wix, e sites estáticos não são afetados.

Precisa de ajuda?

Se você administra vários sites ou não tem certeza se a sua hospedagem já aplicou a correção, fale com a We Design Orange. Ajudamos em tudo: desde verificar a versão e a compilação do PHP de cada site até corrigir o seu VPS, procurar sinais de invasão e testar o site depois da atualização do PHP.

Este artigo resume informações públicas disponíveis em 23 de outubro de 2026. É uma informação técnica, não uma avaliação de segurança nem aconselhamento jurídico. A situação de cada hospedagem se baseia nos comunicados oficiais de cada empresa e pode mudar. Se suspeitar de uma invasão, procure uma empresa de segurança ou a equipe de resposta a incidentes de segurança (CERT) do seu país.