O PHP2Shell não é o wp2shell, e desta vez não há patch de CMS
O PHP2Shell não é o wp2shell
Em setembro, o email na tua caixa era sobre o wp2shell, um erro no núcleo do WordPress. Esta semana é o PHP2Shell, e a diferença importa porque quase toda a gente está a ler o segundo com o primeiro ainda na cabeça.
O wp2shell eram dois erros de WordPress, corrigidos no 7.0.2, e a correção chegou como atualização de CMS. O PHP2Shell são o CVE-2026-109618 e o CVE-2026-109619, ambos com 9.2 no CVSS v4.0, ambos a permitir execução remota de código sem autenticação. Estão no motor do PHP, portanto nem uma versão de WordPress nem um plugin os corrigem. Se corres PHP, estás no âmbito, e a única correção é o binário.
O que saiu, e a que velocidade andou
A 21 de outubro de 2026 a equipa do PHP lançou 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Os detalhes saíram a 20 de outubro, a Cloudflare viu tráfego de ataque às 07:43 UTC do dia 21, e as correções apareceram às 13:30 UTC, no mínimo. A watchTowr reporta exploração em curso. Governos tiraram sites do ar em vez de os deixar sem correção: a Câmara dos Deputados neerlandesa, a Tweakers, o Porto de Roterdão, a Valtori da Finlândia, a Kombit da Dinamarca e o Ministério do Interior francês.
O email do teu alojamento acertou no essencial
A DigitalOcean escreveu a toda a base de clientes, e se recebeste o mesmo do teu alojamento, as partes úteis aguentaram: corrige já, o 8.1 e anteriores não têm correção oficial, e não há mitigação completa. O que ficou por baixo foi a urgência. Aqui, a distância entre patch disponível e varrimento em massa foram horas, e o varrimento começou antes de o patch existir.
Duas frases desse email estão erradas
O email diz que, se usas WordPress ou Laravel, podes "precisar de patches específicos diretamente desses fornecedores". Não precisas. Nenhum dos dois traz o próprio PHP, e não há patch de CMS para esperar. A Sansec põe isso no primeiro parágrafo: não consegues corrigir o PHP2Shell a partir do código da tua loja. Segues aquela frase à letra e perdes um dia à espera de uma versão do WordPress que não vem.
O que precisa mesmo de patches de fornecedor é outra coisa: equipamentos e firmware que embarcam PHP, onde não consegues atualizar o PHP sozinho. O NCSC neerlandês mantém uma lista pública exatamente desses. O email juntou duas situações numa frase.
O mesmo email diz que as falhas afetam o PHP a partir da versão 5. O código vulnerável data do 5.4.0, de 2012. É menor, exceto que saber que ramos estão realmente no âmbito é o trabalho todo durante um patch em massa, e só do 8.2 ao 8.5 há correção oficial.
O que os erros são, em breve
Ambos são use-after-free. No CVE-2026-109618, o PHP aborta um pedido a meio da leitura quando atinge o memory_limit, e a limpeza passa a confiar em dados parcialmente inicializados. Também vaza memória do worker pelo cookie PHPSESSID: palavras-passe, tokens de sessão e chaves TLS de outros pedidos, mesmo que a aplicação nunca chame session_start(). No CVE-2026-109619, o estado do pedido sobrevive a um free e o pedido seguinte no mesmo worker usa-o antes de a inicialização o repor. A Calif, a Wiz Research e a OpenAI encontraram-nos, e a Sansec confirmou execução de código sem autenticação contra Magento 2.4.9 e mais dez aplicações antes de o patch existir.
Não há mitigação, só patch
O php.net: "There are no complete mitigations, updating is the only safe choice." session.upload_progress=0 fecha a rota de sessão confirmada e mais nada. memory_limit=-1 elimina a falha controlável e deixa um pedido comer a máquina. O PHP diz para pôr isso no php.ini principal ou no pool FPM, não em ini_set() nem num .user.ini, o que é incómodo porque foi o que muitos alojamentos partilhados fizeram.
Verifiquei o meu alojamento
Este site está em alojamento partilhado da HostGator, portanto não controlo o binário. Por SSH: ea-php83, versão 8.3.36 compilada a 20 de outubro de 2026, a build corrigida, entregue antes do lançamento público. O php.ini principal tem session.upload_progress.enabled = 0 na linha 1388, repetido no .user.ini da conta sob "added by webhost (mitigation)". O php -v reporta a CLI, não a camada web, mas o session.save_path aponta para ea-php83, portanto aqui coincidem.
O que fazer agora
Arranja a versão que a camada web serve, por phpinfo(), pelo painel ou pelo Site Health do WordPress. 8.5.12, 8.4.27, 8.3.36 e 8.2.35 estão corrigidas; abaixo disso, no mesmo ramo, estás vulnerável. Num servidor teu, atualiza o pacote e confirma a versão depois do reload, porque um upgrade que falhou parece um que funcionou até ires ver. Em RHEL, o repositório Remi não teria atualizações no dia do lançamento, portanto usa os pacotes da distribuição. Se estás em 8.2, repara no fim de vida a 31 de dezembro de 2026.
Não descarregues esse exploit
Há código no GitHub a afirmar ser um exploit funcional do PHP2Shell, e parte dele instala malware em quem o corre. Não descarregues um PoC para testar o teu servidor. O teste que importa é a verificação de versão acima.
Tens um site WordPress que não para de se partir? Vê o que faço e como trabalho.