Segurança
Falha grave no PHP: entenda o PHP2Shell e como corrigir
Entenda as falhas críticas no PHP divulgadas em outubro de 2026, as versões corrigidas, o impacto no WordPress e o aviso sobre a CVE-2026-115560.
Duas vulnerabilidades críticas no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619, motivaram atualizações emergenciais em 21 de outubro de 2026. Em condições específicas, elas podem permitir que um atacante execute código em um servidor sem autenticação. Para quem administra sites, lojas virtuais ou sistemas internos, a prioridade é identificar o PHP realmente utilizado e aplicar a correção fornecida pelo projeto ou pelo fornecedor da distribuição.
Este artigo reúne informações consultadas em 25 de outubro de 2026. Além das duas falhas principais, explica o aviso complementar sobre a CVE-2026-115560, publicado em 23 de outubro. As recomendações operacionais abaixo são um roteiro de verificação; a atualização de cada ambiente deve seguir o pacote e as instruções do fornecedor responsável.
O Alerta 93/2026 do CTIR.Gov também recomenda identificar instalações afetadas e aplicar imediatamente as atualizações, respeitando compatibilidade e procedimentos de mudança.
O que aconteceu com o PHP em outubro de 2026?
O PHP é o ambiente de execução usado por muitas aplicações web para processar solicitações e gerar conteúdo no servidor. Uma falha nessa camada pode atingir diferentes aplicações que compartilham o mesmo runtime, independentemente de terem sido desenvolvidas por equipes distintas.
A declaração conjunta publicada pela ENISA em 21 de outubro informa que as duas vulnerabilidades podem permitir execução remota de código sem autenticação e orienta a priorização de sistemas expostos à internet. Ambas receberam classificação crítica, com pontuação CVSS v4.0 de 9,2, conforme o alerta da agência de cibersegurança de Singapura, que também usa o nome PHP2Shell para o conjunto.
“Sem autenticação” significa que um ataque bem-sucedido não depende necessariamente de uma conta válida no site. “Execução remota de código” significa executar instruções no contexto do processo afetado. O alcance posterior depende das permissões do serviço, dos segredos acessíveis e das separações existentes entre aplicações.
Isso justifica urgência, mas não permite concluir que todo servidor PHP já foi invadido. É necessário separar a existência da vulnerabilidade, as condições de exploração e as evidências de um incidente em cada ambiente.
Entenda as duas vulnerabilidades principais
CVE-2026-109618: corrupção de memória no tratamento de falta de memória
Segundo o aviso técnico da CVE-2026-109618, uma falha de alocação de memória pode interromper o processamento enquanto estruturas internas ainda estão parcialmente inicializadas. A limpeza posterior da requisição pode lidar com esses dados inválidos de maneira insegura.
Na prática, o problema não se resume a um site ficar lento ou apresentar erro por falta de memória: o estado interno incorreto pode abrir caminho para execução de código. O aviso descreve risco especialmente relevante no Apache com mod_php, em que o caminho demonstrado pode ocorrer antes da execução do código da aplicação.
A correção altera o tratamento dessas situações no próprio PHP. Portanto, acrescentar validação a um formulário específico não equivale a corrigir o runtime.
CVE-2026-109619: estado interno que aponta para memória já liberada
O aviso técnico da CVE-2026-109619 descreve referências internas que podem sobreviver ao encerramento de uma requisição, embora a memória correspondente já tenha sido liberada. Outra requisição atendida pelo mesmo processo pode acessar esse estado antes da reinicialização normal.
Esse tipo de problema é conhecido como use-after-free, ou uso após liberação. A existência de caminhos relacionados a erros e sessões significa que a configuração e o comportamento da aplicação influenciam a exposição. Não é correto assumir que todos os modos de execução tenham exatamente o mesmo caminho de ataque.
Ocultar mensagens de erro no navegador não resolve a causa: o aviso explica que o acesso inseguro pode acontecer antes da decisão de exibir ou registrar um diagnóstico.
Quais versões do PHP receberam correção?
O CTIR.Gov lista as seguintes versões corrigidas para as duas vulnerabilidades divulgadas em 21 de outubro:
| Linha | Versões anteriores afetadas na linha | Versão com correção |
|---|---|---|
| PHP 8.5 | Anteriores à 8.5.12 | 8.5.12 |
| PHP 8.4 | Anteriores à 8.4.27 | 8.4.27 |
| PHP 8.3 | Anteriores à 8.3.36 | 8.3.36 |
| PHP 8.2 | Anteriores à 8.2.35 | 8.2.35 |
Esses são os marcos de correção do lançamento emergencial, não uma recomendação de permanecer indefinidamente nessas versões. Use uma versão suportada que inclua os patches e acompanhe os avisos posteriores. A tabela também não significa que a CVE-2026-115560 esteja corrigida nesses mesmos lançamentos.
E o PHP 8.1, 8.0 ou 7.4?
Conforme o comunicado do projeto PHP, o PHP 8.1 e versões anteriores já não recebem atualizações regulares do projeto. Dada a gravidade, foram disponibilizados patches mínimos de código-fonte para 7.4, 8.0 e 8.1. Isso não restabelece o suporte regular dessas linhas.
Algumas distribuições e fornecedores LTS podem entregar correções por backport, mantendo uma numeração de base antiga. Solicite o boletim de segurança e a identificação completa do pacote: apenas comparar o número principal mostrado na tela pode levar a uma conclusão errada.
Quais sites e servidores precisam de atenção?
O projeto relaciona instalações que atendem requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O maior risco destacado no comunicado é o de mod_php. A lista deve orientar o inventário, sem tratar as condições de exploração de todos esses ambientes como idênticas. Consulte o aviso oficial.
WordPress, Drupal e outros sistemas
Um site que executa PHP precisa ter o runtime avaliado mesmo que seu CMS esteja atualizado. Atualizar plugins, temas e o núcleo da aplicação continua sendo necessário para outras vulnerabilidades, mas não comprova a instalação de um patch no interpretador.
Para quem usa hospedagem gerenciada, a tarefa principal é confirmar a correção com o provedor e verificar a versão atribuída a cada domínio. Em uma VPS administrada pela própria equipe, o inventário deve incluir pools, serviços, containers e instalações mantidas fora do gerenciador de pacotes padrão.
Sites estáticos e serviços auxiliares
Servir apenas arquivos HTML não executa PHP por si só. Porém, isso não permite concluir que toda a infraestrutura esteja fora de risco: painéis, sistemas antigos, formulários e serviços em outros subdomínios podem usar PHP. A avaliação deve considerar o caminho real de cada requisição e os componentes auxiliares.
O alerta canadense recomenda incluir também produtos de terceiros, appliances e containers com PHP embarcado.
Como verificar qual PHP está instalado e em uso
Como ponto de partida, em um servidor sob sua administração, os comandos abaixo consultam o executável disponível no terminal e os arquivos de configuração da interface de linha de comando:
php -v
php --iniEsses resultados não comprovam a versão atendendo o site. O terminal pode usar um PHP diferente daquele carregado pelo Apache, por um pool PHP-FPM ou por um container. Registre a saída como parte do inventário e confronte-a com a configuração do servidor web ou do painel de hospedagem.
Para cada aplicação, recomendamos preencher uma ficha simples: domínio, responsável, modo de execução, versão completa do pacote ou imagem, serviço associado e evidência do patch. Acrescente a data da validação e quem confirmou o resultado. Isso ajuda a evitar que um domínio fique esquecido depois de atualizar os demais.
Evite deixar uma página pública de diagnóstico com phpinfo() para facilitar a conferência. Informações de ambiente podem revelar detalhes desnecessários. Prefira o painel autenticado, inventário administrativo ou uma verificação interna controlada e removida após o uso.
Roteiro para atualizar e validar o ambiente
A sequência abaixo é uma sugestão operacional para organizar a resposta. Não há um comando de atualização universal: distribuição, origem dos pacotes e forma de implantação determinam o procedimento correto.
- Identifique o escopo. Liste os serviços que executam PHP e priorize os acessíveis pela internet. Defina um responsável por cada sistema.
- Confirme a origem da correção. Consulte o boletim da distribuição, do fornecedor da imagem ou do provedor de hospedagem. Registre os dois identificadores CVE na verificação.
- Prepare recuperação e testes. Confira backups, configurações e acesso administrativo. A preparação deve ajudar a executar a mudança urgente com controle.
- Aplique o pacote corrigido. Em containers, atualize a imagem e reimplante as instâncias. Atualizar apenas o host não demonstra que o PHP dentro de uma imagem foi corrigido.
- Substitua os processos antigos. Faça o reinício ou a recriação dos serviços conforme as instruções do fornecedor, abrangendo todas as instâncias e réplicas.
- Valide a aplicação. Teste autenticação, sessão, formulários, uploads, integrações e tarefas de fundo relevantes ao seu sistema.
- Guarde evidências. Registre a versão efetivamente carregada, o pacote instalado, o horário da mudança e o resultado dos testes.
Em um ambiente com balanceador, confira cada servidor de origem. Uma resposta bem-sucedida pode vir de uma instância corrigida enquanto outra continua antiga. Em hospedagem com vários domínios, confirme a associação de cada domínio ao runtime atualizado.
Se surgir incompatibilidade após a mudança, investigue com o fornecedor e mantenha a exposição controlada. Voltar a uma versão vulnerável não deve ser tratado como encerramento do incidente de atualização.
E se não for possível atualizar imediatamente?
O NCSC britânico recomenda considerar retirar o sistema do ar quando a correção imediata não for viável. O NCSC dos Países Baixos reforça que medidas temporárias limitam caminhos específicos e não substituem a atualização.
Como decisão operacional, avalie restringir o acesso à aplicação vulnerável até corrigir, abrangendo também o acesso direto ao servidor de origem. Colocar uma página de manutenção apenas na frente de uma aplicação ainda acessível por outro endereço pode deixar a exposição aberta.
Desabilitar o progresso de upload de sessões
Entre as medidas documentadas para caminhos relacionados a sessões está:
session.upload_progress.enabled=0O aviso técnico orienta aplicar a configuração antes do processamento da requisição e reiniciar todos os workers. Não se deve depender de um ini_set() dentro da aplicação ou do arquivo .user.ini do FPM para esse objetivo. A medida não fecha todas as variantes da CVE-2026-109619.
Por que não copiar ajustes de memória sem avaliar?
Para a CVE-2026-109618, o aviso apresenta uma mitigação parcial baseada em remover o limite de memória por requisição. O mesmo documento deixa claro que falhas de alocação subjacentes ainda podem atingir o caminho vulnerável e discute limites externos de recursos. Veja as condições e limitações oficiais.
Por isso, não recomendamos transformar esse ajuste em uma receita genérica. Alterações nos limites de memória exigem capacidade, isolamento e monitoramento compatíveis; sem isso, podem agravar problemas de disponibilidade. A prioridade continua sendo instalar o patch ou restringir a exposição enquanto ele é aplicado.
HTTPS protege o transporte da conexão, e um WAF pode compor a defesa. Nenhum dos dois demonstra, por si só, que a corrupção de memória no PHP foi corrigida.
O que mudou com a CVE-2026-115560 em 23 de outubro?
O alerta canadense atualizado em 23 de outubro distingue a CVE-2026-115560 das duas falhas anteriores: ela não foi corrigida pelos lançamentos emergenciais de 21 de outubro e exige uma combinação incomum de configuração e comportamento da aplicação.
O aviso informativo do PHP descreve uma aplicação que troca o serializador de sessões em tempo de execução, com progresso de upload de sessões habilitado. Na informação consultada em 25 de outubro, o projeto previa tratar esse problema no ciclo regular de correções e recomendava manter session.upload_progress.enabled=0 como precaução.
A distinção importa para a comunicação: as versões da tabela corrigem as duas vulnerabilidades críticas principais, mas a revisão de configuração e o acompanhamento do terceiro aviso continuam necessários. Não use “atualizamos o PHP” como substituto de uma confirmação sobre quais problemas foram tratados.
Há exploração? Como investigar uma possível invasão?
Os relatos devem ser lidos com data e contexto. Em 23 de outubro, a agência de Singapura relatava tentativas disseminadas de exploração. Já o NCSC neerlandês informou que a exploração era complexa e que um relato de possível ataque no exterior ainda não tinha sucesso confirmado por aquela entidade. A recomendação de atualizar permanecia.
Uma prova de conceito demonstra viabilidade em determinadas condições; uma tentativa registrada não comprova comprometimento. Por outro lado, a ausência de um alerta automático também não comprova que o servidor permaneceu íntegro.
Como roteiro de triagem, recomendamos correlacionar horários de erros e reinícios com alterações de arquivos, novos processos, contas inesperadas e conexões de saída incomuns. Preserve os registros antes de rotacionar ou reinstalar componentes. Erros isolados têm causas variadas e precisam de investigação contextual.
Se houver suspeita consistente, envolva a equipe de resposta a incidentes, mantenha o serviço isolado e avalie reconstrução a partir de uma base confiável. Atualizar o PHP interrompe a exposição corrigida, mas não remove automaticamente arquivos maliciosos ou credenciais obtidas anteriormente.
O que perguntar à empresa de hospedagem
Quem não administra o servidor pode enviar uma solicitação objetiva pelo suporte autenticado. Uma resposta útil deve identificar o serviço corrigido e a evidência correspondente.
- Qual versão e pacote de PHP atendem cada domínio da minha conta?
- As CVE-2026-109618 e CVE-2026-109619 foram corrigidas, inclusive por backport quando aplicável?
- Todos os processos e réplicas passaram a executar o código atualizado?
- A orientação complementar sobre a CVE-2026-115560 foi avaliada?
- Há registros de atividade suspeita que exijam investigação adicional?
Guarde a confirmação junto ao inventário e repita a verificação para serviços contratados separadamente. Para conhecer os critérios de fontes usados neste site, consulte a nossa política editorial e a página Como avaliamos.
Perguntas frequentes
- Qual é a falha grave no PHP divulgada em outubro de 2026?
- O alerta principal envolve duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, com atualizações publicadas em 21 de outubro. Elas podem permitir execução remota de código sem autenticação, dependendo das condições do ambiente.
- Quais versões corrigem as duas vulnerabilidades principais?
- Os lançamentos emergenciais corrigidos são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Distribuições podem fornecer backports, que devem ser confirmados pelo boletim e pela identificação completa do pacote.
- Atualizar o WordPress resolve o problema?
- A atualização do CMS não comprova a correção do interpretador. É necessário verificar o PHP efetivamente utilizado pela hospedagem ou pelo servidor e aplicar o patch apropriado.
- PHP-FPM também precisa ser verificado?
- Sim. Ele está entre os ambientes relacionados no comunicado do PHP. As condições de exploração variam, e usar FPM não substitui a atualização nem a avaliação da configuração.
- O comando php -v confirma que o site está corrigido?
- Não sozinho. Ele mostra o PHP disponível no terminal, que pode ser diferente do runtime carregado pelo servidor web, pelo pool FPM ou pelo container.
- As atualizações de 21 de outubro corrigem a CVE-2026-115560?
- Segundo o aviso complementar consultado em 25 de outubro, não. Esse problema tem condições específicas e exige acompanhar a orientação sobre progresso de upload de sessões e as próximas correções do projeto.
- Um site que só serve HTML estático é afetado?
- Arquivos HTML não executam PHP por si só. Mesmo assim, devem ser inventariados painéis, aplicações auxiliares, subdomínios e outros serviços que possam usar PHP na mesma infraestrutura.
- Instalar o patch remove uma invasão já ocorrida?
- Não. A atualização corrige as vulnerabilidades correspondentes, mas suspeitas de comprometimento exigem investigação, preservação de evidências e tratamento de persistência ou credenciais expostas.
Fontes oficiais e acompanhamento
Informações verificadas em 25 de outubro de 2026. Consulte os avisos a seguir para mudanças posteriores de escopo, mitigação e versões:
