O PHP2Shell colocou a atualização do PHP na lista de prioridades das equipes de TI e segurança. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 podem permitir execução remota de código sem autenticação, comprometendo o ambiente que processa as requisições das aplicações.

Para as empresas, a resposta começa com uma pergunta: onde há PHP em execução e quais dessas instalações já receberam as correções? A resposta precisa incluir servidores, containers, imagens de implantação e serviços administrados por terceiros.

O caso também reforça a necessidade de olhar além do código desenvolvido internamente. Uma aplicação pode ter passado por revisões e continuar exposta por causa de uma falha no runtime, o componente responsável por executar o PHP.

O que é o PHP2Shell?

PHP2Shell é o nome associado a duas vulnerabilidades críticas de segurança de memória no núcleo do PHP. Elas foram corrigidas na atualização de segurança publicada pelo projeto PHP em 21 de outubro de 2026.

Na CVE-2026-109618, o tratamento de uma condição de falta de memória pode interromper o processamento quando estruturas internas ainda não foram completamente inicializadas. A etapa de encerramento da requisição pode então utilizar esses dados inválidos, abrindo caminho para execução remota de código.

Já a CVE-2026-109619 envolve referências a dados de uma requisição que permanecem acessíveis depois que a memória correspondente foi liberada. Uma requisição posterior, atendida pelo mesmo processo de trabalho, pode acessar esse estado residual.

As condições de exploração variam conforme a vulnerabilidade, a configuração e o modo de execução do PHP. O alerta oficial inclui instalações que atendem requisições web e destaca o risco do Apache com mod_php, para o qual foi demonstrada exploração antes da execução do código da aplicação.

Por que o impacto exige atenção

Execução remota de código, ou RCE, significa que um invasor pode executar código no ambiente afetado. O alcance inicial acompanha os privilégios do processo comprometido. Portanto, o impacto depende também das permissões, dos arquivos acessíveis e das conexões disponíveis para esse processo.

Isso pode colocar em risco credenciais de serviços, informações da aplicação e dados acessíveis a ela. Se houver permissões excessivas ou pouca segmentação, o comprometimento também pode abrir caminhos para outros componentes da infraestrutura.

Uma avaliação de risco deve considerar essas relações. Um serviço exposto à internet, com acesso a dados sensíveis e credenciais amplas, merece prioridade na resposta. Essa análise ajuda a organizar o trabalho sem tratar ambientes internos como automaticamente seguros.

Atualizar o CMS pode não corrigir o PHP2Shell

A localização da falha muda a estratégia de correção. Atualizar um CMS, framework ou plugin é parte da manutenção da aplicação, mas a equipe também precisa verificar a versão e o pacote do PHP utilizados na execução.

Em ambientes com containers, vale conferir tanto as instâncias em produção quanto as imagens usadas em novas implantações. Corrigir apenas uma instância deixa a possibilidade de uma imagem antiga recolocar o componente vulnerável no ambiente.

Para organizar essa verificação, registre:

• A aplicação e seu responsável técnico.
• A versão, a origem do pacote e a imagem utilizada.
• A exposição à internet e os acessos a dados e serviços.
• A correção adotada e a evidência de implantação.

Esse registro cria uma base para acompanhar a resposta e identificar pendências que poderiam ficar dispersas entre desenvolvimento, infraestrutura e fornecedores.

Como priorizar a correção

O projeto PHP publicou as correções nas versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Esses números são referências das versões que corrigiram as duas CVEs. Na implantação, consulte a atualização de segurança mais recente disponível para a linha adotada.

Distribuições Linux e fornecedores de suporte estendido podem disponibilizar correções por backport, incorporando o patch a um pacote com numeração própria. Por isso, a conferência deve incluir o boletim do fornecedor, além do número de versão exibido pelo PHP.

A execução pode ser organizada em quatro etapas:

1. Localizar as instalações: mapear ambientes ativos e artefatos de implantação que utilizam PHP.
2. Definir a prioridade: considerar exposição, criticidade da aplicação e acessos disponíveis.
3. Aplicar e validar: instalar o pacote corrigido, testar os fluxos críticos e confirmar que os processos ativos utilizam a correção.
4. Registrar a conclusão: guardar as evidências e acompanhar exceções com responsável e prazo.

Em paralelo, a equipe deve avaliar a necessidade de investigar comprometimento. Aplicar um patch impede a exploração da falha corrigida, mas não desfaz ações que um invasor eventualmente tenha realizado antes da atualização.

Como lidar com aplicações legadas

O PHP 8.1 e as versões anteriores já não recebem atualizações regulares do projeto PHP. Nesses ambientes, é necessário verificar a existência de correções mantidas por fornecedores ou planejar a migração para uma versão suportada.

A Aikido disponibilizou imagens de containers com correções do PHP2Shell, incluindo backports para diversas linhas antigas. Essa alternativa permite tratar as falhas específicas enquanto a migração é preparada, desde que exista uma imagem compatível com o ambiente.

A disponibilidade deve ser conferida por versão e variante. Na publicação consultada, a Aikido informa cobertura de linhas entre PHP 5.5 e 8.5, com exceção do PHP 8.0. A adoção exige testes de compatibilidade, reconstrução das imagens e nova implantação.

Corrigir essas CVEs em uma versão antiga não resolve todo o passivo de segurança do legado. A atualização estrutural deve continuar no planejamento, com responsáveis e critérios de validação.

O papel da IA e a preparação para novos casos

Pesquisas sobre o PHP2Shell relatam o uso de inteligência artificial na análise das falhas e no desenvolvimento de provas de exploração. Para as empresas, isso reforça a importância de ter um processo de resposta pronto antes do próximo alerta crítico.

Um inventário atualizado, responsáveis definidos e um fluxo de correção testado ajudam a reduzir o tempo gasto descobrindo quem deve agir. Também permitem separar uma instalação potencialmente afetada de um ambiente cuja correção já foi comprovada.

O PHP2Shell oferece um motivo concreto para revisar como sua empresa identifica componentes vulneráveis e acompanha a remediação. A segurança da aplicação depende também da visibilidade sobre aquilo que a executa.

Converse com a Elosoft para conhecer a Aikido e avaliar como a solução pode apoiar sua estratégia de segurança de aplicações.

Fontes

• PHP — alerta oficial e versões corrigidas: https://www.php.net/archive/2026.php#2026-10-21-5
• PHP — CVE-2026-109618: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• PHP — CVE-2026-109619: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Aikido — imagens corrigidas e cobertura de versões: https://www.aikido.dev/blog/how-to-patch-php2shell-with-free-aikido-images
• Wiz — pesquisa sobre o PHP2Shell: https://www.wiz.io/blog/php2shell-php-rce

Informações verificadas em 5 de novembro de 2026.