PHP2Shell: Como a IA Revelou Vulnerabilidades Críticas no Núcleo do PHP e Acelerou a Defesa de Servidores
Fala pessoal do TabNews!
Nesta última semana de outubro de 2026, fomos pegos por um daqueles incidentes que mexem com a infraestrutura da internet inteira: as vulnerabilidades apelidadas de PHP2Shell (CVE-2026-109618 e CVE-2026-109619), somadas a uma terceira divulgada de surpresa no dia 23 (CVE-2026-115560).
O que torna esse caso fascinante — e ao mesmo tempo um aviso sério para quem administra servidores — não é apenas a gravidade (CVSS 9.2 com RCE sem autenticação), mas o fato de que as falhas estavam adormecidas no código C do núcleo do PHP há mais de uma década e foram mapeadas com auxílio direto de IA avançada (Wiz Atlas, Gemini Argon e GPT-5.6 Sol).
Queria trazer uma síntese puramente técnica e pragmática do que realmente aconteceu, separando os fatos dos mitos de pânico que circularam nas redes.
Onde estava o problema real na memória?
Não foi bug em plugin do WordPress ou biblioteca de terceiro. A falha é no próprio interpretador do PHP:
-
CVE-2026-109618 (Corrupção de Memória em Out-of-Memory):
O PHP interrompe uma requisição quando os limites de memória estouram. O problema é que, se o estouro ocorrer enquanto estruturas internas ainda estão sendo alocadas (inicialização parcial), a rotina de limpeza (cleanup) trata lixo de memória como se fossem dados estruturados válidos. Isso corrompe ponteiros e permite escalada até execução remota de código sem autenticação. -
CVE-2026-109619 (Use-After-Free no OPcache e Backtraces):
Determinados estados internos sobreviviam no processo trabalhador (worker) mesmo após a memória ser liberada. Uma nova requisição atendida pelo mesmo worker herdava referências a regiões de memória recicladas. Como o OPcache compartilha estruturas em memória para acelerar scripts compilados, o isolamento entre requisições era quebrado.
A pegadinha da terceira CVE (CVE-2026-115560)
O projeto PHP lançou correções no dia 21 de outubro (8.5.12, 8.4.27, 8.3.36 e 8.2.35). Porém, dois dias depois (23 de outubro), foi emitido um alerta adicional para a CVE-2026-115560, outra RCE ligada ao progresso de upload de sessão (upload_progress), que não foi resolvida pelos patches do dia 21.
A recomendação expressa dos mantenedores e do CERT-EU é desabilitar essa flag no php.ini enquanto o patch definitivo não sai:
; /etc/php/8.x/fpm/php.ini ou /etc/php.ini
session.upload_progress.enabled = 0
Tabela de versões mínimas corrigidas:
| Série do PHP | Versão Mínima Segura |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 ou anterior | Exige backports da distro (Debian/Ubuntu/RHEL) |
Cuidado com o php -v: verifique o pacote real
Lembrete vital para quem usa Debian, Ubuntu ou RHEL: o comando php -v pode mostrar uma versão antiga mesmo se o patch de segurança já tiver sido aplicado via backport. Confirme sempre pelo gerenciador de pacotes:
# Debian / Ubuntu
dpkg -l | grep -E "php.*(fpm|common|cli)"
# RHEL / CentOS / AlmaLinux
rpm -qa | grep -E "php.*(fpm|common|cli)"
E não esqueça de reiniciar os processos persistentes (sudo systemctl restart php8.x-fpm e nginx/apache2), senão o binário antigo continua rodando na memória RAM.
O verdadeiro divisor de águas: a velocidade da IA
A IA não inventou o erro de código — ele foi introduzido por mãos humanas anos atrás. O que mudou é a assimetria de tempo: o que levava semanas de engenharia reversa e fuzzing manual agora pode ser mapeado em horas por agentes de análise estática e raciocínio de código.
Isso significa que o tempo de janela entre a descoberta de uma falha e o surgimento de PoCs na internet caiu para quase zero.
Artigo com análise aprofundada de engenharia e mitigação de borda:
👉 PHP2Shell: Análise Completa no Sentinel
Como foi a rotina de atualização nos servidores de vocês essa semana? Tiveram que lidar com sistemas legados em PHP 7.x/8.0 ou as distros de vocês já entregaram os backports tranquilos?