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

> O PHP corrigiu em 21/10 duas falhas que deixam invadir o servidor sem senha. Veja se o seu projeto feito com IA está exposto e o passo a passo para proteger.

**Autor:** Murilo Souza · **Categoria:** IA & Tecnologia · **Publicado:** 2026-10-21
**Canonical:** https://koko.ag/blog/falha-php-vibe-coder-passo-a-passo

---
**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

> **Gráfico:** Passo a passo em sete etapas para proteger um projeto da falha PHP2Shell. 1, listar onde cada projeto roda, com plataforma, linguagem e quem tem o acesso. 2, ver a versão do PHP no servidor, não no computador. 3, atualizar para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 e testar home, formulário e login. 4, em 8.1 ou anterior, mudar de versão, porque não há correção oficial. 5, se não der para atualizar hoje, conter com as medidas parciais do aviso oficial. 6, procurar sinal de invasão: arquivo PHP novo, administrador que você não criou, tarefa agendada estranha. 7, ligar log de acesso e monitor de disponibilidade. Atualizar fecha a porta, mas não tira quem já entrou

### 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.

<figure class="fala" data-especialista="murilo">
<blockquote><p>Projeto feito com IA costuma ter dono até o deploy. Depois, ninguém olha o servidor. Põe na agenda uma revisão por mês: peça para a IA listar a versão de tudo que roda em produção e compare com a versão atual de cada coisa. Leva poucos minutos, e é a hora em que você descobre o que ficou para trás.</p></blockquote>
<figcaption><a href="/diario/murilo/">Murilo Souza</a>, especialista de martech</figcaption>
</figure>

### 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.

> **Gráfico:** Tabela com as versões que corrigem as duas falhas desta semana. PHP: 8.2.35, 8.3.36, 8.4.27 ou 8.5.12; 8.1 e anteriores não recebem correção oficial. Node.js: 22.23.4, 24.22.1 ou 26.12.1, porque ele traz a própria lista de certificados; o Node 20 já está fora de suporte. Python: certifi 2026.10.19, para quem usa requests ou httpx. Go: recompilar com 1.27.3 ou 1.26.10. Ubuntu: pacote ca-certificates 20260816. Docker: reconstruir com docker build --pull, porque sem o pull o build usa a imagem base guardada na máquina

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.

```text
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](/#contato).

## Leia também

- [IA pro conteúdo em 2026: 7 faz e não faz](/blog/ia-para-conteudo-7-faz-e-nao-faz/) · onde a IA ajuda e onde atrapalha
- [Landing page para Instagram: o que a página precisa entregar](/blog/landing-page-trafego-instagram/) · a página que costuma morar em hospedagem com PHP
- [JSON no marketing: ler payload de IA, CAPI e GA4](/blog/o-que-e-json-marketing/) · para entender o que a IA e as APIs devolvem
- [Diagnóstico de martech gratuito](/diagnostico/) · 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](https://www.php.net/archive/2026.php#2026-10-21-5)
2. [GitHub · php-src, GHSA-w8hw-w9fx-j79w (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
3. [GitHub · php-src, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
4. [watchTowr · PHP Remote Code Execution FAQ: CVE-2026-109618](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)
5. [BleepingComputer · PHP ships emergency patches for critical PHP2Shell flaws](https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/)
6. [Help Net Security · PHP2Shell: Critical PHP vulnerabilities patched, update now!](https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/)
7. [Mattias Geniar · PHP CVE-2026-109618 and CVE-2026-109619: early mitigation steps](https://ma.ttias.be/php-cve-2026-109618-early-mitigation/)
8. [BleepingComputer · Mozilla, Google, Apple block compromised eMudhra CA certificates](https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/)
9. [eMudhra Intermediate CA Compromise · página do incidente com os testes](https://emudhra.we-have-a-problem.com/)
10. [Node.js · histórico de versões](https://nodejs.org/en/about/previous-releases)