PHP2Shell: falhas críticas no PHP e como proteger seus servidores
Em 21 de outubro de 2026, a equipe de segurança do PHP publicou correções para duas falhas críticas no núcleo da linguagem. Elas receberam os identificadores CVE-2026-109618 e CVE-2026-109619, ficaram conhecidas como PHP2Shell e têm nota 9.2 no CVSS v4.0, a escala usada para medir a gravidade de vulnerabilidades.
O alerta do CISC, o centro de segurança cibernética do Governo Digital, resume o risco: um atacante remoto, sem login, pode executar comandos no servidor. Como o problema está no próprio PHP, e não em um sistema específico, ele atinge sites, lojas virtuais, ERPs web e painéis internos que rodam sobre a linguagem.
O que são as duas falhas
As duas vulnerabilidades envolvem a forma como o PHP cuida da memória enquanto processa requisições HTTP.
- CVE-2026-109618, memória insuficiente: quando o PHP esbarra numa condição de falta de memória (Out-of-Memory), estruturas internas podem ficar em estado inconsistente. Esse estado abre caminho para a execução remota de código.
- CVE-2026-109619, memória reutilizada: uma falha no gerenciamento de estados globais faz com que áreas de memória já liberadas sejam reaproveitadas pela requisição seguinte. Na prática, uma requisição pode deixar "restos" que outra usa de forma indevida.
O nome PHP2Shell vem do resultado da exploração: sair de uma requisição comum ao site e chegar a um shell, ou seja, a uma linha de comando no servidor.
Quem está exposto
O alerta deixa claro que as falhas não dependem de framework nem da aplicação. Estão no caminho de risco os ambientes que usam:
| Forma de rodar o PHP | Situação |
|---|---|
| Apache com mod_php | exploração sem autenticação já demonstrada, antes mesmo do código da aplicação rodar |
| PHP-FPM | afetado |
| php-cgi | afetado |
| FrankenPHP | afetado |
| LiteSpeed | afetado |
Se a empresa tem um site em WordPress, uma loja em Magento, um sistema interno em Laravel ou qualquer outra aplicação PHP, vale tratar o servidor como vulnerável até confirmar a versão instalada.
O que pode acontecer
Segundo o CISC, uma exploração bem-sucedida permite:
- executar comandos remotamente sem autenticação;
- comprometer o servidor e as aplicações web hospedadas nele;
- acessar, alterar ou vazar informações;
- usar o servidor invadido como ponte para atacar outros equipamentos da rede.
O último ponto é o que mais preocupa em empresas pequenas e médias. Um servidor web costuma ter acesso ao banco de dados, a pastas compartilhadas e a outras máquinas. Uma invasão que começa no site raramente fica só no site.
Como corrigir
A única medida que a equipe do PHP considera eficaz é atualizar para uma versão corrigida:
| Linha | Versão corrigida |
|---|---|
| PHP 8.2 | 8.2.35 ou posterior |
| PHP 8.3 | 8.3.36 ou posterior |
| PHP 8.4 | 8.4.27 ou posterior |
| PHP 8.5 | 8.5.12 ou posterior |
Para saber a versão instalada no servidor:
php -vEm servidores com PHP-FPM ou mod_php, confira também a versão que o servidor web carrega, com uma página de teste phpinfo() acessível só pela rede interna, e apague a página depois. Depois de atualizar, reinicie todos os processos PHP (PHP-FPM, Apache ou o serviço da aplicação). Sem reiniciar, o código antigo continua na memória.
O PHP 8.1 e as versões anteriores não recebem mais correções do projeto. Nesses casos, o caminho é migrar para uma versão suportada ou aplicar a correção oferecida pelo fornecedor da distribuição ou da hospedagem.
Se não der para atualizar hoje
Quando a atualização depende de testes ou de uma janela de manutenção, o CISC recomenda medidas temporárias que reduzem a exposição aos caminhos de ataque conhecidos:
; php.ini: mitigação temporária
session.upload_progress.enabled = 0
; só no PHP 8.5:
fatal_error_backtraces = 0- Depois de alterar o
php.ini, reinicie todos os processos PHP. - Avalie configurar
memory_limit=-1, de preferência em nível administrativo, para reduzir os cenários ligados à CVE-2026-109618. Faça isso com cuidado: sem limite, um script com problema pode consumir toda a memória do servidor. - Limite o tamanho das requisições com
post_max_sizeeupload_max_filesize, e configure no servidor web ou no proxy limites de tamanho e de quantidade de campos. - Quando for viável, restrinja temporariamente o acesso pela internet aos serviços expostos.
Essas medidas reduzem o risco, mas não eliminam as falhas. Elas servem para ganhar tempo até a atualização, não para substituí-la.
Por onde começar
- Liste os servidores e sistemas que usam PHP, começando pelos que ficam expostos à internet.
- Confira a versão de cada um e compare com a tabela de versões corrigidas.
- Atualize e reinicie os processos PHP, priorizando os ambientes com mod_php.
- Aplique as mitigações onde a atualização precisar esperar.
- Acompanhe os registros de erro do PHP e do servidor web, os encerramentos inesperados de processos e qualquer atividade estranha nos dias seguintes.
Se a empresa não tem certeza de onde o PHP está rodando ou não sabe como atualizar sem derrubar o sistema, a equipe da TRIAT pode ajudar no levantamento e na correção.
Fontes
Precisa disso rodando na sua empresa?
A TRIAT implanta e monitora Linux, storage, virtualização, redes e segurança — do projeto ao suporte 24/7.
Falar com um especialista
