PHP corrige duas vulnerabilidades críticas de RCE sem autenticação (CVE-2026-109618, CVE-2026-109619): [atualizado para CVE-2026-115560]

Na quarta-feira, 21 de outubro de 2026, às 14h UTC, o projeto PHP lançou as versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir duas vulnerabilidades críticas, ambas com pontuação CVSS v4.0 de 9,2, que podem permitir execução remota de código sem autenticação. A equipe de segurança do PHP recomenda: "Não há mitigações completas; atualizar é a única opção segura."

Esses bugs estão no runtime do PHP, não em um pacote Composer. Isso muda a forma de detectá-los e corrigi-los, como explicamos abaixo.

Resumo Se você usa PHP para atender solicitações da web (PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP, LiteSpeed), atualize hoje para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se estiver usando a versão 8.1 ou anterior, obtenha um pacote com backport da sua distribuição ou fornecedor de LTS, ou faça o upgrade.

O que aconteceu

Os horários estão em UTC.

• 20 de outubro: A equipe de segurança do PHP publicou um aviso prévio sobre um lançamento de segurança crítico, previsto para 21 de outubro às 14h UTC. Ele corrige duas vulnerabilidades avaliadas em CVSS v4.0 9,2, reservando-se o direito de lançá-lo antes caso detalhes vazem ou haja exploração ativa.

• 21 de outubro, antes das 14h UTC: A Snyk publicou avisos sobre as duas CVEs, SNYK-UNMANAGED-PHP-21347795 (CVE-2026-109618) e SNYK-UNMANAGED-PHP-21347796 (CVE-2026-109619), para alertar os clientes sobre as medidas necessárias e garantir que os projetos monitorados fossem sinalizados assim que as versões corrigidas fossem conhecidas.

• 21 de outubro, às 14h UTC: O aviso de segurança do PHP e as quatro versões corrigidas são publicados. Em cerca de 30 minutos, os avisos da Snyk são atualizados com todos os detalhes relevantes, incluindo as faixas afetadas e as versões corrigidas.

• A partir de 21 de outubro: As distribuições Linux (que receberam os patches antecipadamente) começam a publicar seus próprios avisos. A Snyk publica avisos para elas à medida que são divulgados, como SNYK-UBUNTU2604-PHP85-21373920. A lista atualizada está em CVE-2026-109618 e CVE-2026-109619.

Atualização de 23 de outubro: mantenha session.upload_progress.enabled=0

Em 23 de outubro, o projeto PHP publicou um aviso informativo para a CVE-2026-115560, uma CVE reservada, mas ainda não atribuída. Ele descreve um vetor de bypass parcial para a CVE-2026-109619. A configuração que o impede, session.upload_progress.enabled=0, já constava como mitigação para a CVE-2026-109619.

O PHP não está lançando uma correção emergencial porque as condições necessárias para a exploração são raras e provavelmente não se aplicam à maioria das implantações. Um aplicativo precisa configurar session.serialize_handler como php_binary or php_serialize e, em seguida, alterá-lo para php em runtime com ini_set() antes de chamar session_start(), enquanto o progresso de upload da sessão estiver habilitado. Aplicativos que nunca alteram o handler de serialização em runtime podem manter esse recurso ativado.

As vulnerabilidades

Ambas estão no ciclo de vida das solicitações do mecanismo do PHP, tornando-as acessíveis antes da execução de qualquer código do aplicativo. Esse é um dos fatores que tornam essas vulnerabilidades tão disseminadas e perigosas.

Detalhes técnicos

CVE-2026-109618, RCE por corrupção causada por falta de memória: O tratamento de falta de memória pode interromper o PHP enquanto os dados internos da solicitação estão apenas parcialmente inicializados. Em seguida, a limpeza da solicitação trata os dados inválidos como válidos. Um invasor capaz de levar um worker ao limite de memória com uma solicitação maliciosa pode provocar a interrupção.

CVE-2026-109619, RCE por estado global obsoleto: O estado interno associado a uma solicitação pode persistir depois que a memória que o sustenta é liberada. Uma solicitação posterior, processada pelo mesmo worker, pode usar esse estado obsoleto antes que a inicialização normal o redefina. Em um modelo de workers de longa duração, isso configura um use-after-free entre solicitações.

Esses bugs foram encontrados com auxílio de IA em um runtime que está em produção há três décadas. Em um mundo de LLMs e agentes, todo mundo ainda executa servidores — e o modelo que encontrou essas falhas é do mesmo tipo dos modelos que os invasores têm agora. Essa é a premissa por trás de Evo by Snyk: segurança baseada em IA para os aplicativos executados por agentes, não apenas para os próprios agentes. A descoberta com auxílio de IA também explica por que PHP2Shell não será a última falha desse tipo e por que os prazos de resposta agora são medidos em horas.

Quem é afetado

Todas as instalações do PHP que atendem solicitações da web estão em risco. Isso inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP, LiteSpeed e outros. O Apache com mod_php é o mais vulnerável: há um exploit demonstrado em que uma única solicitação sem autenticação dispara o ataque antes da execução do código do aplicativo.

O projeto PHP não fornece mais atualizações para a versão 8.1 e anteriores. Portanto, uma instalação sem patch das versões 8.1, 8.0 ou 7.4 é afetada e não tem correção upstream. Dada a gravidade, a equipe de segurança do PHP publicou backports mínimos do código-fonte para as versões 7.4, 8.0 e 8.1, destinados a quem compila a partir do código-fonte ou não tem um fornecedor de LTS.

O que fazer agora

1. Atualize. As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A versão 8.2 chega ao fim da vida útil em 31 de dezembro de 2026. Se você usa a 8.2, aproveite para planejar a próxima atualização.

2. Consulte seu fornecedor. As distribuições Linux e os fornecedores de LTS receberam os patches antes do lançamento. Instale os pacotes atualizados deles em vez de esperar por uma compilação do código-fonte. Uma compilação corrigida da distribuição pode manter um número de versão antigo, então consulte também o aviso ou o nível de patch da distribuição.

3. Confirme o que está realmente em execução. Verifique a versão do PHP em cada host e imagem (php -v ou a tag da imagem). Os resultados de uma verificação, por si só, não confirmam que a instalação está corrigida.

4. Se não puder atualizar hoje, o PHP lista mitigações que reduzem a exposição a vetores específicos, mas não tornam a instalação segura: definir memory_limit=-1 em um contexto que os aplicativos não possam substituir, usar um post_max_size baixo, definir session.upload_progress.enabled=0 e reiniciar todos os workers e, na versão 8.5, definir fatal_error_backtraces=0. Consulte o aviso pertinente para conhecer as ressalvas de cada medida.

5. Independentemente de ter atualizado ou não, mantenha session.upload_progress.enabled=0 até o próximo lançamento regular de correção de bugs, caso seu aplicativo altere session.serialize_handler em runtime. Consulte a atualização acima para ver os detalhes.

6. Se você usa PHP 8.1 ou anterior, faça upgrade para uma versão com suporte ou obtenha um pacote com backport da sua distribuição ou fornecedor de LTS. Os backports do código-fonte do PHP para as versões 7.4, 8.0 e 8.1 são o último recurso para equipes que compilam a partir do código-fonte.

O lado do código aberto

A equipe de segurança do PHP avisou o ecossistema com um dia de antecedência, informando o horário exato, a gravidade e sem divulgar detalhes de exploração. Compartilhou os patches antecipadamente com as distribuições Linux para que as correções empacotadas pudessem ser lançadas junto com a versão do código-fonte. Publicou backports para versões sem suporte (7.4, 8.0, 8.1). Avisou os usuários de um popular repositório mantido por voluntários (rpms.remirepo.net) que ele não seria atualizado no primeiro dia e explicou o que fazer. E as orientações de mitigação deixam muito claro o que cada configuração não protege.

É assim que funciona uma divulgação coordenada quando um projeto mantido por voluntários faz tudo certo. Também é por isso que, na Snyk, conseguimos publicar os avisos antes do lançamento e concluí-los pouco depois: um cronograma divulgado permite que todos os envolvidos se preparem.

Como funciona o Snyk SCA

Snyk Open Source analisa o que seu aplicativo declara em arquivos de manifesto ou de build, como composer.json e composer.lock. O interpretador PHP não é uma dependência declarada. Ele é instalado por um Dockerfile, um pacote de distribuição, uma imagem de plataforma ou manualmente. Uma restrição como "php": ">=8.2" em composer.json informa quais versões o aplicativo aceita, mas não exatamente qual versão está implantada.

Como a plataforma Snyk ajuda você a encontrar PHP exposto

Encontre sua superfície de ataque PHP com Snyk API & Web

Antes de aplicar patches, você precisa da lista. A aba Discovery do Snyk API & Web enumera os ativos encontrados nos seus domínios e identifica a pilha tecnológica. Abra Discovery, defina o filtro Tecnologia como PHP e você verá todos os hosts e endpoints identificados como PHP, com classificação de risco, pontuação e data da última detecção, prontos para serem verificados ou adicionados como alvo.

O mesmo filtro Tecnologia também está disponível na lista Alvos. Assim, você pode filtrar da mesma forma os aplicativos adicionados.

Isso não informa a versão do PHP. Mas mostra onde procurar, uma etapa essencial para corrigir o problema.

Teste a vulnerabilidade com Snyk API & Web

O Snyk API & Web permite verificar seus aplicativos e APIs para detectar se estão vulneráveis ao PHP2Shell.

Uma verificação com perfil completo agora testa a vulnerabilidade PHP2Shell. Você também pode criar um perfil de verificação personalizado que teste exclusivamente o PHP2Shell, para descobrir rapidamente se seus aplicativos estão vulneráveis ou se a correção já foi aplicada.

O que estamos fazendo

• Os avisos sobre as duas CVEs foram publicados antes do lançamento do PHP, às 14h UTC, e atualizados com as versões afetadas e os detalhes das correções em cerca de 30 minutos.

• Também foi publicado um aviso para a CVE-2026-115560, que será atualizado à medida que novos detalhes e a correção forem divulgados.

• Os avisos das distribuições estão sendo importados à medida que cada distribuição Linux os publica. Ubuntu e Red Hat já estão disponíveis.

• Há um relatório Zero Day para este evento, disponível para projetos de dependências não gerenciadas e de contêineres.

Como sempre, a equipe de pesquisa de segurança da Snyk está acompanhando esta divulgação e atualizará os avisos conforme novas informações forem disponibilizadas. Em caso de dúvidas, entre em contato com sua equipe de conta da Snyk ou com o suporte.

Referências

• Aviso de segurança do PHP: vulnerabilidades críticas de execução remota de código; atualize agora (21 de outubro de 2026)

• Aviso informativo do PHP: progresso de upload da sessão (23 de outubro de 2026)

• Aviso da Snyk sobre dependências não gerenciadas para a CVE-2026-109618

• Aviso da Snyk sobre dependências não gerenciadas para a CVE-2026-109619

• Todos os avisos da Snyk para a CVE-2026-109618 e CVE-2026-109619

• Documentação do Snyk Open Source

• Documentação da verificação de dependências não gerenciadas do Snyk C/C++