Em 21 de outubro o centro nacional holandês de segurança cibernética tirou seu próprio site offline. Não porque WordPress tivesse sido hackeado, mas porque o interpretador PHP embaixo dele poderia ser.
Naquele dia o projeto PHP enviou correções para dois bugs de execução remota de código não autenticados no interpretador em si, CVE-2026-109618 e CVE-2026-109619. Qualquer site onde PHP respondesse solicitações públicas tinha de fazer patch ou ficar offline. Sites que serviam HTML estático de um CDN não tinham nenhum processo PHP no caminho da solicitação, então não havia nada para fazer patch na borda. Headless WordPress ainda precisava de seu backend atualizado, mas o site público continuava online. Abaixo: a cronologia, o argumento arquitetônico, uma tabela de decisão por stack, um plano 30/60/90 dias, e uma checklist se você está permanecendo no PHP por enquanto.
Se você roda PHP, faça isso hoje.
- Confirme que a versão em execução é 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou um backport de fornecedor cuja notificação você leu, e reinicie cada worker.
- Verifique o que seu painel de controle de hospedagem realmente enviou, não o que o dashboard diz.
- Trate as mitigações ini do PHP e qualquer regra WAF como uma ponte para o patch, não como um substituto para ele.
- Em 7.4 a 8.1, pergunte ao seu host se ele construiu os backports do código-fonte do time de segurança, e agende a atualização de qualquer forma.
O que aconteceu em 21 de outubro de 2026
A linha do tempo importa porque explica o pânico. De acordo com a Tenable, os identificadores CVE circularam no Hacker News e redes sociais em 20 de outubro. Mais tarde naquele dia a equipe de segurança PHP publicou um aviso prévio de um lançamento para 21 de outubro às 14:00 UTC, dizendo que poderia ser lançado mais cedo se os detalhes se tornassem públicos. A Tenable também relata, citando watchTowr, que a divulgação havia sido originalmente marcada para 22 de outubro sob embargo.
A equipe de segurança PHP publicou seu aviso em 21 de outubro, com o título "Security advisory: Critical remote code execution vulnerabilities, update now" (arquivo de notícias php.net). A declaração conjunta ENISA coloca as atualizações às 13:40 UTC. As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Os dois bugs, dos avisos do GitHub:
- CVE-2026-109618: execução remota de código via corrupção de memória insuficiente.
- CVE-2026-109619: execução remota de código via estado global obsoleto, um use-after-free entre requisições tratadas pelo mesmo worker.
A equipe de segurança PHP classifica ambas como CVSS v4.0 9.2. A Tenable observa que alguns relatórios iniciais, incluindo watchTowr e um post no Hacker News, disseram 10.0. Todo SAPI de servidor web está no escopo: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. O aviso de OOM destaca mod_php como o mais exposto, porque a falha acontece inteiramente antes de qualquer código de aplicação ser executado. Calif diz que o caminho de código mais antigo afetado remonta a PHP 5.4.0. A descoberta é creditada a Wiz, Calif e OpenAI, com pesquisa assistida por IA.
Depois as interrupções. Reuters e RTE relataram serviços governamentais tirados do ar nos Países Baixos, Finlândia, França e Austrália, incluindo o site do próprio centro nacional de segurança cibernética holandês. CERT-EU recomendou isolar aplicações voltadas para a internet até serem corrigidas, e CISA instou a correção imediata. Krebs relata que Cloudflare implementou regras de WAF às 3:02 am UTC. Amazon Threat Intelligence diz que viu uma tentativa em 17 de outubro e depois descreveu a exploração como ampla.
Sobre exploração, as fontes discordam, e você deve saber disso. A Fundação PHP disse que não havia identificado exploits funcionais no momento do lançamento. Krebs relata especialistas dizendo que exploits funcionando existem. Tenable disse que código alegando explorar os bugs estava circulando mas não havia verificado nenhum deles.
Por que o conselho foi fazer patch agora ou ficar offline
Execução remota de código não autenticada no caminho de requisição significa que o servidor web é o alvo. Não há login para colocar na frente dele, nenhum plugin para desativar. Uma requisição chega, PHP analisa, e o bug já está em jogo. O aviso de OOM confirma impacto como execução de código não autenticada como a conta do web worker, validada sobre HTTP contra mod_php com limites padrão de entrada e memória.
As mitigações que PHP listou são reais, e são paliativos. Os avisos dizem:
- Configure
memory_limit=-1administrativamente (viaphp_admin_value), mantenhapost_max_sizeconservador, e bloqueie solicitações multipart no frontend se você não as usa. - Defina
session.upload_progress.enabled=0. - Em PHP 8.5, defina
fatal_error_backtraces=0. - Reinicie todo worker após qualquer um destes.
Os mesmos avisos são diretos: atualizar é o único reparo completo. Para o bug de stale-state não existe nenhuma mitigação genérica completa em configuração. O desenvolvedor do PHP core Gina Peter Banyard, citado pela Tenable, disse que a única mitigação é aplicar patch ou atualizar PHP, e o gerenciador de lançamento PHP 8.6 Joe Ferguson disse que configurações ini não vão salvá-lo. Então trate a lista como uma ponte ao longo de uma tarde, não como uma postura.
Dois problemas práticos tornaram o dia mais difícil que um bump de versão. Hospedagem compartilhada e painéis de controle distribuem pacotes PHP em seu próprio cronograma, então a versão que você acredita rodar pode não ser a versão em execução. Plesk publicou seu próprio aviso para o PHP que distribui, que é o tipo de página que você precisa ler em vez de assumir.
E depois os ramos mais antigos. O aviso do php.net diz que PHP 8.1 e versões anteriores não recebem mais atualizações do projeto e aponta para distribuições e fornecedores de LTS para backports. O time de segurança publicou ramos de backport de fonte mínimos para 7.4, 8.0 e 8.1 no GitHub, mas um patch de fonte não é um lançamento: alguém ainda precisa compilá-lo e enviá-lo para seu host. PHP 5.4 até 7.3 não recebem nada. Se você nunca atualizou, esse foi seu 21 de outubro.
Alguns números sobre escala. W3Techs mostra PHP em 69,3% dos sites com uma linguagem server-side conhecida em 22 de outubro, com 65,3% deles na versão 8, 26,9% na versão 7 e 7,7% na versão 5. Censys conta 2,58 milhões de hosts voltados para a internet e 54,9 milhões de propriedades web executando PHP. Esse é um monte de workers para reiniciar.
Quem não tinha nada a fazer em 21 de outubro
Aqui está a exposição em termos de caminho de requisição. Faça uma pergunta de qualquer site: quando um visitante carrega uma página, que código é executado para responder a ele?
HTML estático em uma CDN
Se a resposta for "nada, a CDN retorna um arquivo", PHP2Shell não toca o site público. Nenhum processo PHP responde requisições, então não há nada para fazer patch na edge e nenhuma razão para desativar qualquer coisa. Executo gautamkhorana.com no Astro com saída estática. HostList, que construí em Next.js e Supabase com cerca de 28.000 páginas programáticas, não tinha nenhum processo PHP para fazer patch. Tampouco tinha Deluxe Astrology, que executa 91.000+ páginas em 30 idiomas. Ninguém recebeu uma ligação em 21 de outubro.
Headless WordPress
Headless é uma história diferente, e prefiro ser preciso a lisonjeador. O backend PHP ainda precisava de 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 naquele dia, porque WordPress ainda roda em PHP. A diferença é onde ele fica. Atrás de um firewall ou uma allowlist de IP, com o site público servido por Astro ou Next.js, o backend não estava no caminho de uma requisição do visitante. O patch era uma tarefa de manutenção, não uma interrupção pública.
Diga claramente: isto não é "headless é inquebrável". Um atacante que consegue alcançar o backend ainda pode alcançar o bug, é por isso que a allowlist importa. Frameworks SSR carregam riscos de runtime de servidor próprios, cobertos no artigo de segurança Next.js, Astro e Nuxt, e a comparação mais ampla está em segurança headless vs WordPress. Não vou repetir nenhum deles aqui.
Um padrão, não um caso isolado
Não era a primeira vez que o caminho de requisição do PHP fazia manchetes. Injeção de argumento PHP-CGI, CVE-2024-4577, apareceu em 2024. Havia um bug PHP-CGI mais antigo em 2012. Agora PHP2Shell. Falhas diferentes, mesma forma: código que fica na frente de cada requisição pública é atingido, e todos a jusante correm.
Agora a lição que corta do outro lado. React2Shell no Next.js mostrou que runtimes SSR carregam sua própria exposição no caminho de requisição. Se um servidor JavaScript responde cada requisição de página, é o novo PHP para fins de patch. Passar de WordPress para um site server-rendered Next.js move a superfície de ataque. Não a deleta. Saída estática é a afirmação forte; SSR é uma troca.
Então a pergunta nunca foi "qual linguagem". É "que código responde uma requisição pública". Reduza essa lista e seus dias de incidente ficam mais curtos seja qual for o próximo CVE escrito.
Há um ponto de futuro também. Os pesquisadores Wiz escreveram que as falhas estavam presentes por décadas, que explorá-las levava uma cadeia de passos "no limite do que pesquisadores humanos poderiam praticamente alcançar", e que "modelos de IA de fronteira reduziram substancialmente essa barreira" (Krebs). A implicação, que é minha em vez deles: se falhas antigas ficam mais baratas para virar exploits, a cadência de divulgação sobe para todo runtime. Planeje mais dias como este, não menos.
O que 21 de outubro custou, por stack
| Stack | PHP no caminho de requisição pública? | O que você teve que fazer em 21 de outubro | O que o próximo CVE de PHP custa para você | Caminho de migração sensato |
|---|---|---|---|---|
| WordPress clássico ou outro CMS PHP | Sim, todas as páginas | Atualizar PHP para uma versão corrigida, reiniciar cada worker ou isolar o site até conseguir | A mesma correria, no site público | Vá Headless, tipo de página por tipo de página |
| Headless WordPress (backend PHP atrás de um firewall, front end Next.js ou Astro) | Não, apenas backend | Corrigir o backend PHP; o site público continuou sendo servido | Uma janela de patch em um host bloqueado, sem indisponibilidade pública | Ficar; manter o backend na lista de permissão |
| Laravel ou aplicação PHP customizada | Sim | Atualizar o runtime, reiniciar workers, verificar o que seu host forneceu | A mesma correria | Colocar um front end estático ou SSR na frente e mover tipos de página gradualmente |
| Jamstack estático (Astro, Next.js static export, Nuxt generate, Eleventy) | Não | Nada na borda; verificar ferramentas de build e qualquer origem | Nada na borda | Ficar |
| Next.js ou Nuxt com SSR | Sem PHP, mas um servidor JavaScript responde às requisições | Nada para PHP; seus próprios avisos de runtime se aplicam | Um CVE de runtime diferente com a mesma forma | Mover páginas que não precisam de renderização por requisição para saída estática |
WordPress clássico ou outro CMS PHP. Drupal, Magento, Joomla e WordPress todos rodam em PHP, e Calif relata confirmação de execução remota de código pré-autenticada contra versões específicas dos quatro, conforme FAQ da Tenable. Esta linha carregou todo o custo do dia.
WordPress Headless. Você corrigiu, mas no seu cronograma e atrás de um firewall. Editores continuaram editando. Visitantes não viram nada.
Laravel ou PHP customizado. A mesma exposição que o CMS clássico, com um detalhe: ninguém publica um aviso de produto para sua app customizada, então você controla o inventário. O repositório php2shell da NCSC-NL diz que aplicações PHP customizadas não estão registradas em sua visão geral.
Static Jamstack. Nada para fazer na borda. Se seu build roda em uma CI box, corrija quando conveniente, já que não está servindo visitantes.
SSR com Next.js ou Nuxt. Sem PHP, sem PHP2Shell. Mas um processo de servidor ainda responde requisições, e React2Shell é o lembrete de que este processo tem seus próprios dias ruins.
O plano 30/60/90 dias
O objetivo é tirar a superfície pública do PHP sem reconstruir a experiência de edição.
- Até o dia 30: liste seus tipos de página (posts, landing pages, product pages, arquivos) e marque quais genuinamente precisam de lógica por requisição. Confirme a versão PHP em cada host. Coloque um CDN na frente da origem e restrinja o admin a uma lista de permissões.
- Até o dia 60: monte um front end Astro ou Next.js para um ou dois tipos de página estática com mais tráfego, construído a partir da API de conteúdo do WordPress. Dispare um rebuild ao publicar. Adicione redirecionamentos 301 para cada URL que você mover.
- Até o dia 90: migre os tipos de página restantes que podem ser estáticos. Feche a origem PHP para tráfego público para que apenas o processo de build e seus editores na lista de permissões a alcancem. Qualquer coisa que realmente precise de um servidor (busca, formulários, contas) vai para um serviço pequeno e nomeado que você pode corrigir por conta própria.
Tirando a superfície pública do PHP sem perder o CMS
Você não precisa descartar WordPress para tirar PHP do caminho da requisição. WordPress Headless mantém editores, conteúdo e o fluxo de plugins para escrita e aprovações, enquanto Astro ou Next.js serve o site. Editores mantêm a tela que conhecem. Visitantes recebem arquivos de um CDN.
Migre progressivamente. Escolha um tipo de página, reconstrua-o no novo front end, redirecione as URLs antigas com 301, e siga em frente. O admin fica em PHP, atrás de uma lista de permissões. O padrão de hospedagem é simples: origem trancada, CDN na frente, build ao publicar.
Sobre escolha de framework: Astro para sites de conteúdo, Next.js quando o site precisa de uma camada de aplicação, Nuxt para times Vue. Os trade-offs mais profundos estão na comparação de geradores de site estático e no guia WordPress Headless.
Sobre esforço, usando apenas os preços iniciais: migração de WordPress para Astro é a partir de $7k, desenvolvimento WordPress Headless é a partir de $10k, e migração de CMS legado começa a partir de $5k. Se o site precisa de uma camada de aplicação, migração de WordPress para Next.js a partir de $10k é a rota que se encaixa. Estes são pontos de partida, e o valor real depende de tipos de página, integrações e quanto do fluxo de edição você quer preservar. Se você está considerando sair completamente do PHP, a página leave-WordPress cobre esse caminho.
O dia mais barato para começar isso não é o dia depois de um aviso. Mas o dia depois de um aviso é quando orçamentos são aprovados, então use-o.
Se você está permanecendo em PHP por enquanto
Alguns sites ficarão parados por um ou três anos. Tudo bem. Enquanto isso, faça isto:
- Confirme se a versão PHP em execução é 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou um backport do fornecedor que você leu o aviso), e que todo worker foi reiniciado. Uma atualização de pacote que deixa workers antigos em execução não resolveu nada.
- Verifique o que seu painel de controle de hospedagem realmente enviou, em vez do que o dashboard diz.
- Aplique apenas as mitigações listadas do PHP como uma ponte. Os avisos dizem que não deixam uma instalação segura, e o aviso de OOM adverte contra
RLIMIT_ASeRLIMIT_DATA, que disparam o caminho vulnerável. - Planeje agora a saída de 7.4 para 8.1. O projeto PHP não atualiza mais 8.1 e versões anteriores, e você está dependendo de um backport de outro.
- Coloque o site atrás de um WAF enquanto você corrige. O CTO da Cloudflare, Dane Knecht, chamou suas regras de "uma SOLUÇÃO TEMPORÁRIA apenas", e a Tenable observa que elas cobrem apenas o tráfego roteado através da Cloudflare.
- Fique atento a web shells e arquivos PHP que não deveriam existir. A Wiz espera exploração em massa para instalá-los, então verifique diretórios de upload e arquivos modificados recentemente.
Para sites que permanecerão no WordPress, o suporte de segurança WordPress a partir de $150/mês cobre a correção contínua e o monitoramento.
O fato mais agudo de 21 de outubro é que o bug vivia no único lugar que cada visitante PHP toca, então os únicos sites sem nada a fazer eram aqueles onde PHP nunca respondeu a uma requisição pública. A saída estática é a versão forte dessa afirmação; WordPress headless ainda precisava que seu backend fosse corrigido, e SSR apenas troca um runtime por outro.
FAQ
O WordPress é afetado por PHP2Shell?
WordPress em si não é o bug. As falhas estão em PHP, e WordPress roda em PHP, então qualquer site WordPress em um PHP sem patch estava exposto. O FAQ da Tenable, citando Calif, relata execução remota de código pré-autenticada confirmada contra versões específicas do WordPress, o que esclarece a questão.
O WordPress headless ainda precisa do patch?
Sim. O backend roda PHP, e um invasor que puder alcançá-lo pode alcançar o bug. O que headless muda é exposição: o backend pode ficar atrás de um firewall ou lista de permissões enquanto um front end separado atende ao público.
Um site Next.js ou Astro é mais seguro que PHP?
A saída estática de ambos é mais segura contra esta classe de bug, porque nenhum runtime do lado do servidor responde requisições. SSR é uma troca: você substitui PHP por um runtime de servidor JavaScript com seus próprios avisos, como React2Shell mostrou.
Um WAF me protege?
Em parte, e apenas por um tempo. A Cloudflare chamou suas regras de solução temporária e elas cobrem apenas tráfego através da Cloudflare. Um WAF te dá tempo para corrigir. Não é um patch.
Devo tirar meu site do ar?
CERT-EU recomendou considerar isolamento de aplicações voltadas para a internet até que uma correção esteja disponível, e a declaração conjunta da ENISA diz o mesmo quando remediação imediata não é viável. Se você conseguir corrigir rapidamente, corrija. Se não conseguir, isolamento é uma decisão razoável.
Quais versões PHP estão corrigidas?
PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, conforme os avisos do PHP.
PHP 7.4, 8.0 e 8.1 foram corrigidos?
Não com lançamentos. O aviso do php.net diz que 8.1 e versões anteriores não recebem mais atualizações do projeto PHP, e o time de segurança publicou ramos de backport de fonte mínimos para 7.4, 8.0 e 8.1 em vez disso. Pergunte ao seu host ou distribuição se compilou eles; de qualquer forma, planeje a atualização.