Duas vulnerabilidades críticas descobertas no PHP levaram administradores de servidores no mundo inteiro a atualizar sistemas às pressas e fizeram órgãos do governo federal brasileiro retirar temporariamente alguns serviços do ar. As falhas, identificadas como CVE-2026-109618 e CVE-2026-109619, podem permitir execução remota de código em servidores vulneráveis sem necessidade de autenticação. Isso é grave, mas não significa que “70% da internet foi invadida” nem que todos os sites construídos com PHP tenham sido comprometidos. No Brasil, o Sistema Eletrônico de Informações, o SEI, foi suspenso preventivamente em órgãos públicos enquanto correções eram aplicadas.
O PHP publicou em 21 de outubro de 2026 correções para duas vulnerabilidades críticas com pontuação CVSS 9,2.
As falhas receberam os identificadores CVE-2026-109618 e CVE-2026-109619 e podem permitir execução remota de código sem autenticação em determinadas instalações vulneráveis.
No governo federal brasileiro, sistemas baseados em PHP foram temporariamente isolados ou retirados do acesso externo como medida preventiva. O SEI esteve entre eles.
Suspender um sistema preventivamente não comprova invasão. Até a publicação desta matéria, as fontes oficiais consultadas descreviam principalmente medidas de mitigação e atualização.
O que foi descoberto no PHP e por que a falha foi considerada crítica
PHP é uma linguagem amplamente utilizada no desenvolvimento de aplicações web. Ela funciona principalmente no servidor, processando requisições e entregando ao navegador o resultado produzido pela aplicação.
Em 20 de outubro, a equipe responsável pelo PHP publicou um aviso antecipando que disponibilizaria no dia seguinte uma atualização crítica de segurança. A comunicação era incomum justamente pela gravidade das duas vulnerabilidades, ambas classificadas com pontuação 9,2 no CVSS versão 4.
Quando as correções foram publicadas em 21 de outubro, as falhas passaram a ser identificadas como CVE-2026-109618 e CVE-2026-109619.
O Centro de Prevenção, Tratamento e Resposta a Incidentes Cibernéticos de Governo, o CTIR Gov, informou que ambas podem possibilitar execução remota de código, conhecida pela sigla RCE. Em termos práticos, significa que um atacante pode, em determinadas condições, conseguir fazer um servidor vulnerável executar comandos que não deveriam ser aceitos.
Isso é muito diferente de uma falha que apenas derruba uma página ou produz uma mensagem de erro.
As vulnerabilidades envolvem gerenciamento de memória e estados internos do PHP durante o processamento de requisições. O alerta brasileiro destacou risco particularmente elevado em alguns ambientes com Apache e mod_php, embora outras formas de implantação do PHP também precisem ser avaliadas e atualizadas.
As versões corrigidas divulgadas pelas autoridades brasileiras incluem PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Versões posteriores dentro das respectivas linhas também incorporam a correção.
Servidor vulnerável: determinada combinação de versão, configuração e exposição permite alcançar a falha.
Exploração: um atacante consegue acionar o comportamento defeituoso.
Consequência potencial: comandos podem ser executados no servidor, criando risco para aplicações, dados e outros componentes da infraestrutura.
Esse cenário ajuda a entender por que administradores foram orientados a atualizar rapidamente. Quando uma falha permite execução de comandos sem autenticação, simplesmente exigir senha dos usuários da aplicação não elimina o problema.
Por que sistemas brasileiros foram retirados do ar sem que isso prove uma invasão
No Brasil, o CTIR Gov e o Centro Integrado de Segurança Cibernética do Governo Digital distribuíram alertas às equipes de tecnologia.
A orientação incluiu identificar instalações PHP, aplicar as versões corrigidas e, quando a atualização imediata não fosse possível, restringir temporariamente o acesso externo.
O Ministério da Gestão informou em 22 de outubro que unidades do governo federal haviam sido orientadas a proteger sistemas, desabilitar acessos externos e atualizar servidores.
O SEI, utilizado para tramitação de processos e documentos em diversos órgãos públicos, foi um dos sistemas retirados preventivamente do ar.
Essa distinção é central.
Um órgão desligar temporariamente um serviço pode significar justamente que sua equipe decidiu reduzir exposição antes de aplicar a correção.
Não é evidência automática de que atacantes entraram no sistema.
O Ministério da Gestão informou também que os sites institucionais do governo utilizavam outra tecnologia e não foram afetados pela mesma medida, assim como a plataforma GOV.BR permanecia funcionando normalmente.
Isso desmonta outra interpretação exagerada, a de que uma vulnerabilidade no PHP teria automaticamente paralisado toda a infraestrutura digital do governo.
Sistemas compartilham tecnologias, mas não compartilham necessariamente a mesma arquitetura, versão ou grau de exposição.
É exatamente por isso que estatísticas sobre popularidade de PHP não podem ser convertidas diretamente em porcentagem da internet comprometida.
Quem precisa tomar providências e o que muda para o usuário comum
O grupo que precisa agir diretamente é formado principalmente por administradores de servidores, empresas de hospedagem, equipes de infraestrutura, desenvolvedores responsáveis por ambientes produtivos e organizações que mantêm aplicações PHP.
É necessário identificar versões utilizadas e atualizar instalações vulneráveis.
Ambientes antigos merecem cuidado adicional. O Processo Eletrônico Nacional alertou, por exemplo, que instalações antigas do SEI baseadas em versões sem suporte também precisam ser atualizadas.
Para o usuário comum de um portal, não existe uma atualização de PHP para instalar no computador ou telefone.
PHP normalmente está do outro lado da conexão, no servidor.
Isso não elimina impactos indiretos. Um serviço pode ficar temporariamente indisponível enquanto a equipe executa manutenção.
Se uma organização confirmar posteriormente comprometimento e vazamento de dados, poderão surgir orientações adicionais, como troca de senha. Essa ação precisa ser baseada em evidência do incidente, não apenas na existência da vulnerabilidade.
Uma tecnologia ser muito utilizada não significa que todos os sistemas construídos com ela tenham sido invadidos. O risco depende de versão, configuração, exposição e aplicação das correções. A retirada preventiva de um serviço pode ser justamente sinal de resposta de segurança, não prova de comprometimento.
.png)
