Falha crítica no PHP: o passo a passo do vibe coder

Em 21 de outubro de 2026, o PHP publicou correção de emergência para duas falhas que deixam qualquer pessoa rodar código no servidor, sem login. Site em PHP precisa estar na versão 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, e quem está na 8.1 ou anterior não recebe correção. Se você monta projeto com IA, essa parte é sua: a IA escreve o código, mas não atualiza o servidor onde ele roda. Abaixo estão o que aconteceu, como saber se o seu projeto está exposto e o passo a passo que seguimos na Koko no dia do alerta.

O que aconteceu

As falhas são a CVE-2026-109618 e a CVE-2026-109619, apelidadas de PHP2Shell. O próprio PHP dá nota 9,2 de 10 para as duas, na escala CVSS. Elas estão no núcleo do PHP, então atualizar o WordPress, o tema ou os plugins não resolve.

A primeira aparece quando o PHP fica sem memória enquanto prepara os dados de uma requisição. A segunda deixa restos de uma requisição na memória, e a requisição seguinte pode usar esses restos. Nas duas, o resultado pode ser código rodando no servidor com as permissões do site, sem senha nenhuma. A segunda também pode vazar trechos da memória, que costumam ter senha e chave de API.

O aviso do PHP diz que toda instalação que atende requisição web está em risco, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed, e que o risco é maior no mod_php. Os detalhes vazaram antes da data combinada para a divulgação, e a correção saiu às pressas. A watchTowr registrou exploração em sua rede de servidores-isca no dia 21. Segundo o BleepingComputer, o diretor de tecnologia da Cloudflare disse que a empresa já via os primeiros ataques antes da correção.

Seu projeto usa PHP?

Muito projeto feito com IA não usa. O que sai do Lovable, do Bolt e do v0 costuma ser JavaScript ou TypeScript, rodando na própria plataforma ou na Vercel. O PHP aparece nas outras pontas:

• site ou blog em WordPress;
• projeto em Laravel ou em outro framework PHP;
• landing page em hospedagem compartilhada com cPanel ou painel parecido;
• plugin de WordPress que a IA escreveu para você;
• servidor próprio (VPS) onde você instalou PHP para algum projeto.

Se não souber, pergunte à própria IA, com o projeto aberto: "este projeto usa PHP? em que versão e onde ele roda em produção?". Depois confira no servidor, porque a IA só enxerga o código.

O passo a passo

1. Liste onde cada projeto roda

Para cada projeto, anote a plataforma (Vercel, Lovable, hospedagem, VPS), a linguagem e quem tem o acesso. No dia do alerta, foi por essa lista que começamos na Koko, e ela mostrou sites com PHP fora do servidor principal, em VPS separadas.

2. Veja a versão no servidor

A versão que vale é a do servidor, não a do seu computador. No WordPress, ela aparece em Ferramentas > Saúde do site > Informações > Servidor. Na hospedagem, fica na tela de versão do PHP do painel. Num servidor próprio, php -v mostra a versão da linha de comando, que pode ser diferente da que atende o site; a que vale é a do PHP-FPM (php-fpm8.3 -v, por exemplo) ou a do Apache.

3. Atualize para uma versão corrigida

As versões corrigidas são 8.2.35, 8.3.36, 8.4.27 e 8.5.12, uma para cada linha do PHP. Na hospedagem, troque no painel ou peça ao suporte. Num servidor próprio, atualize pelo gerenciador de pacotes e reinicie o PHP. Depois, abra o site e teste o que importa: home, formulário, login e checkout.

Uma armadilha que encontramos na revisão: num Ubuntu com o PHP instalado por um repositório extra, que é o caminho mais comum para ter versão nova de PHP, a atualização automática do sistema estava ligada, mas não incluía esse repositório. O PHP ficou meses na mesma versão sem ninguém perceber. Confira o que a sua atualização automática cobre de verdade.

4. Em 8.1 ou anterior, mude de versão

O PHP não publica mais correção para a 8.1 e as anteriores. Há remendos de código-fonte para 7.4, 8.0 e 8.1, para quem compila o próprio PHP, e algumas distribuições e empresas de suporte estendido fazem correções por conta própria. Fora isso, o caminho é subir de versão.

Peça à IA para revisar a compatibilidade antes ("rode este projeto em PHP 8.3 e liste o que quebra"), porque função removida em versão nova derruba página antiga. Em servidor com cPanel antigo, olhe a lista de versões disponíveis antes de concluir que precisa trocar de servidor: no que revisamos, um CentOS 7 já fora de suporte ainda oferecia o PHP 8.3.36.

5. Se não dá para atualizar hoje, contenha

O aviso do PHP é claro: não há mitigação completa, e só atualizar resolve. Enquanto a atualização não sai, ele lista medidas parciais. Para a segunda falha, desligar o session.upload_progress.enabled e reiniciar todos os processos do PHP. Para a primeira, ajustar memory_limit e post_max_size e limitar a memória pelo contêiner ou pelo sistema.

Quem estuda as falhas também sugere bloquear no servidor web as requisições do tipo multipart, que são as de envio de arquivo, até a atualização. Foi o que fizemos nas primeiras horas. O bloqueio quebra o upload de imagem no painel do WordPress enquanto durar, então avise quem edita o site.

6. Procure sinal de invasão

Atualizar fecha a porta, mas não tira quem já entrou. Olhe:

• arquivo .php novo ou alterado nos últimos dias, principalmente na pasta de uploads;
• usuário administrador que você não criou;
• tarefa agendada (cron) que você não reconhece;
• no WordPress com WP-CLI, wp core verify-checksums e wp plugin verify-checksums --all, que comparam os arquivos com os oficiais.

Se achar algo, tire o site do ar, guarde os logs e troque senhas e chaves de API, porque a falha pode ter vazado memória. Na nossa revisão, os arquivos alterados naquele dia batiam todos com os oficiais do WordPress.org: eram atualizações normais de plugin.

7. Ligue log de acesso e monitor

Sem log de acesso, não dá para saber se alguém tentou entrar. Sem monitor de disponibilidade, o site pode passar dias fora do ar sem ninguém notar. Num dos servidores que revisamos, o log de acesso estava desligado, e ligamos no mesmo dia. Ligue os dois, com alerta no seu e-mail ou no celular.

E o cadeado também

Na mesma semana, saiu outro problema que pega quem desenvolve. A eMudhra, uma das empresas que garantem que o cadeado do navegador é verdadeiro, gerou em abril de 2025 oito certificados intermediários com chaves fracas demais: o número secreto de cada uma era menor que 256, e bastava testar 256 números para descobri-lo. Quem tem uma chave dessas consegue emitir cadeado falso para qualquer site.

Mozilla e Google bloquearam os certificados em 17 de outubro, a Apple em 19 e a Microsoft em 20. A eMudhra diz não ter sinal de que as chaves foram usadas. O problema é o software fora do navegador que traz a própria lista de certificados confiáveis, como Node.js, Python e programas em Go, e as imagens de container montadas antes da correção. Se a sua aplicação em Node chama API de pagamento ou de IA, ela usa a lista que veio junto com o Node.

O que fazer:

• Servidor: atualize o pacote ca-certificates do sistema.
• Node.js: 22.23.4, 24.22.1 ou 26.12.1. No nosso teste, o Node 22.23.2 abriu normalmente a página de teste montada com o certificado comprometido, e o 22.23.4 recusou com CERT_REVOKED.
• Python: certifi 2026.10.19.
• Go: recompile o programa com 1.27.3 ou 1.26.10.
• Docker: reconstrua a imagem com docker build --pull. Sem o --pull, o build usa a imagem base que já está guardada na máquina, e ela pode ter meses. Foi o que encontramos aqui: as imagens base guardadas tinham dois meses.
• Plataforma (Vercel, Netlify, Railway): confira no painel qual Node o projeto usa e faça um novo deploy.

Para testar, rode curl https://dv-g3b-emudhra.we-have-a-problem.com/ no servidor. Se a página abrir, o servidor ainda confia no certificado comprometido. Se der erro de certificado, está corrigido.

O prompt para colar na sua IA

Este pedido funciona no Claude, no Cursor, no Lovable ou em qualquer IA com o projeto aberto. Ele só pede o diagnóstico e o plano. Nenhum arquivo muda sem você ver antes.

Revise a segurança deste projeto sem alterar nenhum arquivo.

1. Liste cada parte do projeto (site, API, painel, scripts), com a linguagem,
   o runtime e a versão usada em produção. Se não der para saber pelo código,
   me diga o comando para eu rodar no servidor.
2. Compare com as versões corrigidas em outubro de 2026: PHP 8.2.35, 8.3.36,
   8.4.27 ou 8.5.12; Node.js 22.23.4, 24.22.1 ou 26.12.1; certifi 2026.10.19;
   Go 1.27.3 ou 1.26.10.
3. Aponte o que está em versão sem suporte (PHP 8.1 ou anterior, Node 20,
   sistema operacional vencido).
4. Se houver Dockerfile, diga se o build puxa a imagem base nova.
5. Monte um plano em ordem de risco e me mostre antes de mudar qualquer coisa.

FAQ

O que é o PHP2Shell? É o apelido de duas falhas no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619, corrigidas em 21 de outubro de 2026. Elas permitem rodar código no servidor sem login e têm nota 9,2 de 10.

Meu site em WordPress está em risco? Se o servidor roda uma versão do PHP anterior a 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, sim. A falha está no PHP, não no WordPress, então o que precisa ser atualizado é o PHP do servidor.

Atualizar o WordPress e os plugins resolve? Não. Continua sendo uma boa prática, mas a correção desta falha só vem com a versão nova do PHP.

Projeto feito no Lovable ou no Bolt está em risco? O código dessas ferramentas costuma ser JavaScript, sem PHP, e a parte de servidor fica com a plataforma. Confira se você não tem também um site ou uma landing page em hospedagem com PHP, e se o seu backend em Node já está numa versão corrigida.

E se a minha hospedagem ainda não atualizou? Veja se o painel oferece uma versão mais nova do PHP e troque. Se não oferecer, cobre o suporte e, enquanto isso, aplique as medidas parciais do aviso oficial.

O que é a falha da eMudhra? Oito certificados intermediários da certificadora indiana eMudhra foram gerados com chaves fáceis de descobrir. Os navegadores já bloquearam. Node, Python, programas em Go e containers antigos continuam confiando neles até serem atualizados.

Conclusão

A IA tirou de você o trabalho de escrever o código. Manter o servidor em dia continua sendo trabalho de quem publica. Uma revisão por mês, com a lista do passo 1 e o prompt acima, mostra o que ficou para trás antes que alguém de fora encontre.

Se você quer ajuda para revisar os seus projetos, fala com a gente.

Leia também

• IA pro conteúdo em 2026: 7 faz e não faz · onde a IA ajuda e onde atrapalha
• Landing page para Instagram: o que a página precisa entregar · a página que costuma morar em hospedagem com PHP
• JSON no marketing: ler payload de IA, CAPI e GA4 · para entender o que a IA e as APIs devolvem
• Diagnóstico de martech gratuito · a IA analisa os pixels e o rastreamento do seu site

Fontes e referências

1. PHP · Security advisory: Critical remote code execution vulnerabilities, update now
2. GitHub · php-src, GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
3. GitHub · php-src, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
4. watchTowr · PHP Remote Code Execution FAQ: CVE-2026-109618
5. BleepingComputer · PHP ships emergency patches for critical PHP2Shell flaws
6. Help Net Security · PHP2Shell: Critical PHP vulnerabilities patched, update now!
7. Mattias Geniar · PHP CVE-2026-109618 and CVE-2026-109619: early mitigation steps
8. BleepingComputer · Mozilla, Google, Apple block compromised eMudhra CA certificates
9. eMudhra Intermediate CA Compromise · página do incidente com os testes
10. Node.js · histórico de versões

Como este texto foi feito. Escrito com apoio de IA na pesquisa e no rascunho.

Diário do Murilo

Murilo Souza

Especialista em Martech

Ver toda a coluna →