Resumo rápido
- O quê: duas falhas no PHP,
CVE-2026-109618eCVE-2026-109619, chamadas de “PHP2Shell”, com gravidade 9,2 (crítica). - Risco: execução remota de código sem autenticação, ou seja, invasão do servidor.
- Quem: qualquer instalação de PHP que atende requisições web (Apache com mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP).
- Correção: atualizar para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Versões 8.1 e anteriores não recebem mais atualização oficial.
Atualizações
- : Anatel retira o SEI do acesso externo, e TRF1, TRF4 e TRF6 suspendem sistemas por precaução. O MGI orienta equipes federais a tirar temporariamente do ar sistemas em PHP que não puderem ser corrigidos de imediato.
- : o projeto PHP lança as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 com a correção. A CISA (EUA) e o CISC (Brasil) emitem alertas pedindo atualização imediata.
Esta página é atualizada conforme surgem novas informações oficiais. Veja as versões corrigidas.
O que aconteceu
Em 21 de outubro de 2026, o projeto PHP publicou uma atualização de segurança emergencial para duas falhas descobertas de forma independente por pesquisadores com apoio de modelos de inteligência artificial. As duas permitem execução remota de código sem autenticação: com uma requisição preparada, um atacante pode rodar comandos no servidor antes mesmo de o código do site ser executado.
No Brasil, o Centro Integrado de Segurança Cibernética do Governo Digital (CISC) emitiu alerta, e o Gabinete de Segurança Institucional orientou os gestores de TI federais a atualizar os sistemas imediatamente. A Anatel retirou o SEI do acesso externo, e tribunais como TRF1, TRF4 e TRF6 suspenderam sistemas por precaução. Nos Estados Unidos, a CISA recomendou correção imediata.
Quem está em risco
Segundo o comunicado oficial do PHP, estão em risco todas as instalações de PHP que atendem requisições web. O risco é maior em servidores Apache com mod_php, configuração em que o ataque foi demonstrado com as opções padrão. No PHP-FPM, a execução de código também foi confirmada a partir de certos caminhos da aplicação.
Isso inclui, entre outros:
- sites em WordPress, Joomla e Drupal;
- lojas em Magento, WooCommerce e OpenCart;
- ambientes de ensino em Moodle;
- sistemas em Laravel, CodeIgniter, Symfony ou PHP puro;
- portais de prefeituras e câmaras municipais, sistemas de protocolo, ouvidoria e transparência;
- instalações do SEI e de outros sistemas públicos feitos em PHP.
Versões corrigidas
| Versão em uso | Atualizar para | Situação |
|---|---|---|
| PHP 8.5 | 8.5.12 | Suportada, com correção oficial |
| PHP 8.4 | 8.4.27 | Suportada, com correção oficial |
| PHP 8.3 | 8.3.36 | Suportada, com correção oficial |
| PHP 8.2 | 8.2.35 | Corrigida, mas o suporte termina em 31/12/2026 |
| PHP 7.4, 8.0 e 8.1 | Migrar para 8.3 ou 8.4 | Sem versão oficial; só há patch de código-fonte |
| PHP 7.3 ou anterior, PHP 5.x | Migrar para 8.3 ou 8.4 | Sem correção |
Atenção para quem está no PHP 8.2: a versão 8.2.35 corrige as falhas, mas o PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026. Vale aproveitar a janela para planejar a migração para 8.3 ou 8.4.
Meu sistema usa PHP antigo. E agora?
Muitos sistemas de empresas e órgãos públicos ainda rodam em PHP 5.6, 7.x ou 8.0, versões que não recebem atualização oficial. O projeto PHP publicou apenas correções mínimas de código-fonte para 7.4, 8.0 e 8.1, que exigem recompilar o PHP manualmente. Para as demais versões não há correção.
Nesses casos, a solução definitiva é modernizar o sistema para uma versão suportada. Isso normalmente envolve ajustar trechos de código incompatíveis, atualizar bibliotecas e testar tudo em um ambiente separado antes de publicar. Enquanto isso, é possível conter o risco restringindo o acesso externo e aplicando as mitigações temporárias.
Como verificar se você está vulnerável
- Descubra a versão do PHP que atende o site. No cPanel, veja em “Selecionar versão do PHP” ou “MultiPHP Manager”. Em servidor próprio, confira o pacote do PHP-FPM ou do módulo do Apache, não só o
php -v. - Compare com a tabela acima. Qualquer versão abaixo das listadas como corrigidas deve ser tratada como vulnerável.
- Liste todos os sistemas: site institucional, sistemas internos, subdomínios, ambientes de homologação esquecidos e cópias antigas também contam.
- Pergunte ao seu provedor de hospedagem se a atualização já foi aplicada em todas as versões de PHP disponíveis no servidor.
Não publique o phpinfo() para conferir a versão. Essa página expõe detalhes do servidor que ajudam atacantes. Se usar, remova logo em seguida.
Mitigações temporárias (enquanto não atualiza)
O comunicado oficial do PHP lista ajustes de configuração que bloqueiam os caminhos de ataque já confirmados. Eles não tornam a instalação segura e devem ser aplicados no php.ini, no pool do PHP-FPM ou na configuração do servidor, seguidos de reinício dos processos:
; php.ini
memory_limit = -1
post_max_size = 8M ; 32M se o sistema recebe uploads
session.upload_progress.enabled = 0
; somente no PHP 8.5
fatal_error_backtraces = 0Não use ini_set() nem arquivos .user.ini para essas opções. Se não for possível atualizar logo, restrinja o acesso externo ao sistema, como fizeram os órgãos públicos.
Como a Ambiente Solução pode ajudar
Trabalhamos com PHP, servidores Linux e hospedagem desde 2007, atendendo empresas, instituições de ensino, prefeituras e câmaras municipais. Montamos um atendimento específico para esta falha:
Diagnóstico
Levantamento das versões de PHP, do servidor web e dos sistemas expostos. Você recebe um relatório objetivo dizendo o que está em risco e o que fazer.
Correção emergencial
Atualização do PHP para a versão corrigida, mitigações, regras de proteção na borda, testes de funcionamento e relatório do que foi feito.
Migração de sistema legado
Para sistemas em PHP 5.x, 7.x ou 8.0/8.1: ajuste de código, bibliotecas e banco de dados para rodar em PHP 8.3 ou 8.4 com segurança.
Manutenção contínua
Atualizações de segurança, monitoramento e backup recorrentes para que a próxima falha não pegue seu sistema desprevenido.
Para prefeituras, câmaras e órgãos públicos
Entregamos documentação técnica do diagnóstico e da correção, útil para instruir o processo de contratação e para prestar contas ao controle interno. Atendemos órgãos de Juiz de Fora, da Zona da Mata e de todo o Brasil remotamente. Saiba mais sobre nossa atuação com sites e sistemas para o setor público.
Perguntas frequentes
Meu site em WordPress está vulnerável?
O WordPress roda sobre PHP, então o que importa é a versão do PHP instalada no servidor, e não a do WordPress. Se o servidor usa uma versão anterior a 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou qualquer versão 8.1 ou mais antiga, o site deve ser considerado em risco até ser atualizado. O mesmo vale para Moodle, Magento, Joomla, Laravel e sistemas em PHP puro.
Atualizar o WordPress ou os plugins resolve?
Não. A falha está no interpretador PHP do servidor, e não no código do site. Atualizar o CMS é sempre recomendável, mas a correção exige atualizar o próprio PHP.
Como descubro qual versão do PHP meu servidor usa?
Em hospedagens com cPanel, a versão aparece em “Selecionar versão do PHP” ou “MultiPHP Manager”. Em servidores próprios, o comando php -v mostra a versão de linha de comando, mas o site pode usar outra; o mais seguro é conferir a configuração do PHP-FPM ou do Apache. Se não tiver acesso, pergunte ao seu provedor ou peça nosso diagnóstico.
Meu sistema usa PHP 7.4 ou 8.0. Existe correção?
O projeto PHP não lança mais versões para 8.1 e anteriores. Foram publicados apenas patches mínimos de código-fonte para 7.4, 8.0 e 8.1, que exigem recompilar o PHP. Para versões mais antigas não há correção oficial. Na prática, o caminho seguro é migrar o sistema para uma versão suportada, como 8.3 ou 8.4.
As mitigações de configuração (php.ini) bastam?
Não. O próprio projeto PHP afirma que as mitigações temporárias bloqueiam apenas caminhos de ataque conhecidos e não tornam a instalação segura. Elas servem para ganhar tempo enquanto a atualização é feita.
Tirar o sistema do ar é necessário?
Foi o que órgãos como a Anatel e tribunais federais fizeram por precaução. Se a atualização não puder ser feita de imediato, restringir o acesso externo é a medida mais segura. Com a atualização aplicada e testada, o sistema pode voltar ao ar.
Quanto tempo leva a correção?
Em servidores com PHP 8.2 ou mais novo, a atualização costuma levar poucas horas, incluindo testes. Sistemas em PHP 7.x ou 5.x podem precisar de ajustes de código para rodar em uma versão suportada; nesse caso fazemos primeiro a contenção e depois a migração planejada.