PHP corrige duas falhas críticas de RCE que já estavam sob ataque

O que foi corrigido

Em 21 de outubro, o projeto PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) → liberou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para fechar duas vulnerabilidades apelidadas de "php2shell": CVE-2026-109618 e CVE-2026-109619, ambas com nota 9.2 em CVSS v4.0. Segundo reportagem da InfoQ, as duas são falhas de segurança de memória no ciclo de vida da requisição: uma no tratamento de falta de memória, outra em estado que sobrevive à memória que deveria contê-lo.

A empresa de segurança Sansec afirma que as falhas existem em toda versão de PHP sem patch desde a série 5.4. O aviso oficial é direto sobre as opções disponíveis:

Não há mitigações completas; atualizar é a única escolha segura.

Aviso de segurança do projeto PHPThere are no complete mitigations; updating is the only safe choice.

A corrida contra o exploit

O patch não chegou antes do ataque. A Amazon Threat Intelligence identificou uma tentativa de exploração em 17 de outubro, quatro dias antes da correção existir, partindo de um endereço IP associado a uma rede comercial de anonimização, segundo a InfoQ. A empresa orientou clientes a investigar logs a partir daquela data.

A Cloudflare reagiu antes mesmo do release oficial: implantou regras de WAF às 03h02 UTC do dia 21 de outubro, cerca de nove horas antes de o patch ficar disponível. Isso mostra que fornecedores de infraestrutura já tinham informação suficiente para agir enquanto parte da comunidade ainda nem sabia do problema.

Quem está exposto: mod_php, FPM e FrankenPHP

A exposição real depende de como o PHP é servido, e os avisos são cautelosos sobre o que foi de fato comprovado. Para Apache com mod_php, a execução remota de código foi validada em ambas as falhas, testada via HTTP contra uma instalação com limites padrão de entrada e memória.

Já no PHP-FPM, só o caso ligado ao ciclo de vida de sessão foi validado como exploit completo; para a falha de falta de memória, o aviso afirma que "nenhum exploit completo para esse SAPI foi demonstrado" até o momento. O FrankenPHP é apontado como provavelmente vulnerável, mas só com base em análise de código-fonte, sem exploit demonstrado publicamente.

O colapso da divulgação coordenada

O processo de divulgação responsável não durou até o fim. Segundo o próprio relato da PHP Foundation, citado pela InfoQ, os identificadores CVE começaram a circular dois dias antes do previsto, um pesquisador "publicou por engano um vídeo" mostrando uma prova de conceito, e a Chainguard "quebrou unilateralmente o embargo e publicou imagens já com a correção".

A consequência, segundo a Foundation, foi que qualquer atacante podia estudar a correção em forma binária enquanto o restante dos usuários de PHP ainda esperava o release oficial. A política pública da Chainguard, atualizada um mês antes do incidente, permite à empresa encurtar prazos de divulgação quando uma vulnerabilidade é identificada como já sob exploração ativa, o que a empresa usou para justificar a decisão.

Comunidade reage: sites saem do ar

Alguns operadores preferiram desligar serviços a esperar o patch. No r/selfhosted, o usuário iamShorteh descreveu a decisão:

Tirei todos os meus sites do ar (desliguei o apache2). Alguém vazou o passo a passo do RCE no Twitter há poucas horas. Não vou arriscar esperar mais 5 ou 6 horas até o hotfix sair.

iamShorteh, comentário no r/selfhostedI've taken all of my websites offline (turned off apache2). Somebody leaked the step by step for RCE on twitter a few hours ago. Not going to risk sitting around another 5-6 hours until the hotfix lands.

O centro nacional de segurança cibernética↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → da Holanda tirou seu próprio site do ar por precaução, assim como a Câmara dos Deputados holandesa. A Sansec, por outro lado, informou a lojas que usam sua plataforma que a medida não era necessária para elas.

Checklist: o que fazer agora

Quem roda PHP em produção enfrenta dois problemas em sequência: primeiro descobrir onde o PHP está rodando, depois confirmar que o patch realmente pegou. No r/selfhosted, usuários relataram encontrar PHP escondido atrás de OPNsense, OpenMediaVault, Nextcloud e Coolify sem saber de cara.

O comentário do usuário spartacle resume o problema:

Para boa parte das coisas do meu homelab, é bem ruim, mas eu nem sei que linguagem cada coisa usa, containers escondem isso de mim.

spartacle, comentário no r/selfhostedFor quite a bit of homelab stuff, it's really bad but I don't know what languages a bunch of stuff uses, containers obfuscated this away from me.

Confirmar a atualização também tem armadilhas, listadas pelo usuário SirRobinBlibs no r/PHP:

Builds de distribuição fazem backport. O pacote corrigido do Ubuntu 24.04 é 8.3.6-0ubuntu0.24.04.13, mas ainda reporta 8.3.6. Confira a versão completa do pacote no tracker da sua distro, não com php -v. A CLI não é o servidor web. Os workers do FPM e do Apache mantêm o engine antigo em memória até serem reiniciados.

SirRobinBlibs, comentário no r/PHPDistro builds backport. Ubuntu 24.04's fixed package is 8.3.6-0ubuntu0.24.04.13, which still reports 8.3.6. Check the full package version against your distro's tracker, not php -v. The CLI isn't the web server. FPM/Apache workers keep the old engine in memory until restarted.

Na prática, isso dá um checklist mínimo:

• Não confie em php -v: compare a versão completa do pacote com o changelog oficial da sua distro.
• Depois de atualizar, reinicie todos os workers de PHP-FPM e Apache, os dois avisos exigem isso explicitamente.
• Não teste com provas de conceito do GitHub: a JFrog documentou repositórios falsos circulando, incluindo um que só trocava o papel de parede da vítima como pegadinha.
• Enquanto o pacote da distro não chega, o Debian Trixie já tinha o patch disponível rapidamente, mas Ubuntu, Red Hat e as imagens oficiais do Docker demoraram mais.

O atraso gerou gargalo: o PPA do mantenedor Ondřej Surý, um dos mais usados para PHP em Ubuntu, travou sob a demanda extra, levando operadores a migrar para packages.sury.org, onde o PPA está sendo incorporado.

A disputa sobre a gravidade real

Nem todo mundo concorda sobre o tamanho do risco prático. As duas CVEs têm atributos AC:H (alta complexidade de ataque) e AT:P (requisitos adicionais de ataque) no CVSS, o que limita quem consegue explorá-las de fato. A própria Sansec revisou sua expectativa inicial:

Os exploits públicos não funcionam contra uma instalação padrão de PHP.

SansecThe public exploits do not work against a default PHP installation.

Isso não significa que o risco seja baixo, só que depende de configuração específica. Para quem administra infraestrutura PHP em produção, a recomendação prática não muda: atualizar continua sendo o único caminho seguro, já que não existe mitigação completa fora do patch.

O problema de fundo: poucas mãos cuidando da segurança do PHP

Usuários do r/PHP perguntaram quantas pessoas, de fato, cuidam da segurança da linguagem. A própria PHP Foundation respondeu no mesmo post de divulgação do incidente, admitindo que o trabalho de segurança "ainda depende de um pequeno grupo de desenvolvedores financiados pela fundação" e que "hoje são poucos demais".

Isso expõe um ponto estrutural que vai além deste incidente específico: PHP roda em uma fatia enorme da web, mas a capacidade de resposta a vulnerabilidades críticas é limitada. Para quem decide stack em empresas que ainda dependem de PHP legado, esse é um dado a pesar junto com o roadmap de versões suportadas.

Nesse ponto, a política de fim de vida também pesa. PHP 8.1 e versões anteriores não recebem mais nada do projeto oficial, embora backports mínimos tenham sido publicados para 7.4, 8.0 e 8.1; o Ubuntu, por sua vez, emitiu correções até para a versão 14.04 sob seu programa de suporte estendido (ESM). PHP 8.2 chega ao fim de vida em 31 de dezembro de 2026, o que deixa pouco tempo para quem ainda está nessa versão planejar a migração.

O terceiro problema, ainda sem patch

Uma terceira falha, CVE-2026-115560, segue sem correção publicada. Enquanto isso, o projeto PHP recomenda configurar session.upload_progress.enabled=0 como mitigação temporária, até que a próxima versão de correção de bugs seja lançada com o aviso completo.

Para quem administra ambientes PHP em produção, o caso reforça uma rotina que vale manter mesmo depois que a poeira baixar: monitorar os canais oficiais de segurança do projeto, automatizar a checagem de versão completa de pacote (não só php -v) e garantir que o processo de deploy sempre inclua reinício de workers após patch de segurança.

Fonte: InfoQ