Sinopse: Por que a falha que tirou do ar sites de governos em três continentes deveria mudar a forma como o setor público brasileiro compra, constrói e aposenta sistemas.
Na quarta-feira, 21 de outubro de 2026, a Anatel suspendeu o acesso externo ao SEI. O TRF1 fez o mesmo, e a Justiça Federal da 4ª Região interrompeu sistemas digitais. Na Holanda, saíram do ar o portal do governo, o Porto de Roterdã e hospitais. Nenhum desses órgãos tinha sido invadido. Desligaram por precaução, porque não conseguiam saber, com a rapidez necessária, se estavam expostos.
A causa foi o PHP2Shell com duas falhas críticas no interpretador do PHP (CVE-2026-109618 e CVE-2026-109619, nota 9,2 no CVSS v4.0). O PHP está presente em cerca de 70% dos sites cuja tecnologia de servidor é identificável. As falhas permitem executar código no servidor sem login e, em algumas configurações, antes que a aplicação rode uma única linha. Todas as versões desde a 5.4, de 2012, são afetadas.
Os detalhes vazaram um dia antes da correção, e as tentativas de exploração, aceleradas por IA, começaram horas depois da publicação. O episódio foi tratado como emergência técnica. Quem trabalha com governança deveria observa-lo como um teste de estresse não programado da gestão de ativos, da arquitetura e da responsabilidade sobre dados de cidadãos. O que já sabemos é que muitos órgãos não passaram nesse teste.
O problema não é o PHP
O projeto PHP corrigiu as falhas em 21 de outubro para as quatro versões suportadas, da 8.2 à 8.5. O problema está no que não tem como ser corrigido, pois temos sistemas rodando versões que o projeto abandonou há anos e a tempos a substituição é indicada. Portanto, seria cômodo culpar a linguagem, mas seria muito errado.
Os números das varreduras públicas são duros. Uma simples contagem no Shodan feita em 20 de outubro encontrou cerca de 884 mil servidores expostos à internet com versões do PHP fora de suporte. Isso é 59% de todos os servidores que revelam a versão. Cerca de 371 mil rodam PHP 5.6 ou 7.2, para os quais não existe correção oficial alguma. Na web como um todo, a W3Techs registrava em agosto que 37,5% dos sites em PHP ainda usavam gerações encerradas.
O setor público aparece com clareza onde há dados. Em poucas horas, usando ferramentas abertas, o Centro Nacional de Resposta a Incidentes da Colômbia, encontrou servidores de domínios .gov.co com versões do PHP de mais de 15 anos. No Brasil, a evidência está na própria reação, sistemas como SEI, eproc e outros, que rodam sobre PHP, foram suspensos justamente por causa dessa dependência.
Em gestão, podemos chamar isso de dívida técnica. Ao contrário da dívida financeira, ela não aparece no balanço. Acumula juros em silêncio até que alguém a cobre de uma vez. Esta cobrança ficou mais rápida. A Wiz encontrou a primeira dessas falhas em 19 de agosto, com ferramentas próprias e modelos de IA de fronteira, e o defeito estava no código havia mais de uma década. O que antes exigia meses de pesquisa especializada passa a levar dias. Sistemas legados, que contavam com a obscuridade como proteção, perderam essa camada de segurança.
Dados de cidadãos não aceitam “sistema antigo” como justificativa
O Governo é o maior controlador de dados pessoais do país. Um processo administrativo pode conter CPF, endereço, laudos de perícia médica, informações fiscais, dados de crianças e registros disciplinares. Boa parte são dados pessoais sensíveis, conforme o art. 5º, II, da LGPD.
A lei não permite tratar a obsolescência como problema exclusivo da TI. Três dispositivos merecem leitura atenta de qualquer dirigente público:
- Art. 6º, VII e VIII: segurança e prevenção são princípios da lei, não recomendações.
- Art. 46: o controlador deve adotar medidas técnicas e administrativas aptas a proteger os dados. O §2º exige que essas medidas sejam observadas desde a concepção do produto ou serviço até a sua execução. Basicamente, trata-se do privacy by design escrito na lei.
- Art. 49: os sistemas usados no tratamento devem ser estruturados para atender aos requisitos de segurança, aos padrões de boas práticas e de governança e aos princípios da lei.
Um sistema que depende de um runtime sem suporte, para o qual uma falha crítica conhecida não terá correção, dificilmente atende ao art. 49. Mantê-lo em produção, tratando dados sensíveis e exposto à internet, deixa de ser uma limitação técnica. Passa a ser uma decisão de risco, e toda decisão de risco tem um responsável.
Há um ponto que costuma passar despercebido. Para órgãos públicos, a LGPD não prevê multa, mas prevê publicização da infração, bloqueio e eliminação dos dados (art. 52, §3º). Bloquear os dados de um sistema que sustenta um serviço público equivale, na prática, a interromper o serviço. Somam-se a isso o dever de comunicar incidentes à ANPD e aos titulares (art. 48 e Resolução CD/ANPD nº 15/2024) e a responsabilização de gestores perante os órgãos de controle.
Secure by Design: a segurança é responsabilidade de quem constrói
O conceito ganhou força em 2023, quando a CISA, agência de cibersegurança dos EUA, e parceiros de vários países publicaram os princípios de Secure by Design. A ideia central é simples, que o ônus da segurança não pode ficar com quem usa o sistema, na verdade deve ser assumido por quem o projeta, constrói e mantém. Os princípios são três, e cada um tem uma tradução direta para o setor público:
- Assumir os resultados de segurança do cliente. No Estado, o cliente final é o cidadão, cujo dado está no sistema e que não tem como escolher outro fornecedor.
- Transparência radical e responsabilização. Saber e informar quais componentes existem, quais vulnerabilidades conhecidas carregam e como estão sendo tratadas.
- Liderança a partir do topo. Segurança como objetivo institucional, com patrocínio da alta direção, e não como tarefa delegada à equipe de infraestrutura.
O PHP2Shell traz uma lição técnica que reforça essa agenda. As falhas são de segurança de memória, como use-after-free, no interpretador, que é escrito em C. A aplicação em PHP pode ter sido escrita com todo o cuidado e, mesmo assim, herdar a vulnerabilidade do runtime. Não por acaso, a própria CISA vem pedindo aos fabricantes roteiros de migração para linguagens com segurança de memória.
Para o gestor público, a consequência prática é que o runtime, o sistema operacional e as bibliotecas fazem parte do sistema. Precisam estar no inventário, no contrato e no planejamento de ciclo de vida.
No Estado, Secure by Design começa na contratação. A segurança precisa entrar no estudo técnico preliminar e no termo de referência das contratações regidas pela Lei 14.133/2021, como requisito verificável. Não como cláusula genérica de “atender às boas práticas”, mas com exigências concretas:
- componentes em versões suportadas durante toda a vigência do contrato;
- prazo máximo para aplicar correções críticas;
- entrega de lista de componentes de software (SBOM) a cada versão;
- configurações seguras por padrão;
- testes de segurança antes de cada liberação.
Desenvolvimento seguro é processo, não ferramenta
Utilizar um testador de vulnerabilidades não é ter desenvolvimento seguro. O que muda o resultado é um ciclo de vida em que a segurança tem etapas, responsáveis e evidências. Não faltam referências para estruturar isso:
| Referência |
O que oferece |
Uso prático no órgão |
| NIST SP 800-218 (SSDF) |
Práticas em quatro grupos: preparar a organização, proteger o software, produzir software seguro e responder a vulnerabilidades |
Base para exigências contratuais a fornecedores e fábricas de software |
| OWASP SAMM |
Modelo de maturidade com níveis mensuráveis por prática |
Diagnóstico inicial e metas anuais de evolução |
| ISO/IEC 27001:2022, Anexo A |
Controles 8.8 (vulnerabilidades técnicas), 8.25 a 8.29 (ciclo de desenvolvimento, requisitos, arquitetura, codificação e testes seguros) e 8.30 (desenvolvimento terceirizado) |
Integração ao sistema de gestão e à auditoria interna |
| CISA Secure by Design |
Princípios e práticas a evitar, como vulnerabilidades conhecidas não tratadas e senhas padrão |
Linguagem comum entre alta direção, TI e fornecedores |
O que essas referências têm em comum, e que o PHP2Shell deixou exposto, é a gestão de dependências. Um sistema não é apenas o código contratado. É também o runtime, o servidor web, o sistema operacional e dezenas de bibliotecas. Sem uma lista de componentes (SBOM) e sem acompanhar o fim de vida de cada um, o órgão só descobre que está exposto quando o CERT publica o alerta.
O próximo fim de vida já tem data. O PHP 8.2, uma das versões corrigidas agora, perde o suporte em 31 de dezembro de 2026. Quem atualizou às pressas para a 8.2 está a pouco mais de dois meses de voltar ao mesmo lugar.
Atualizar, encapsular ou substituir
Nem todo sistema legado precisa ser reescrito, e nem todo pode esperar. A decisão deve considerar dois eixos: a criticidade dos dados e do serviço que o sistema sustenta, e a viabilidade de mantê-lo em uma base suportada. Sistemas que tratam dados sensíveis e não têm caminho de atualização são a prioridade de substituição. Os demais seguem para atualização ou encapsulamento, sempre com prazo.
- Alta criticidade com atualização viável. A decisão deve ser atualizar já. Migrar runtime e aplicação para versões suportadas, com testes de regressão e janela planejada. É o caminho de menor custo e deve ser a prioridade imediata.
- Alta criticidade com atualização inviável. A decisão é substituir. Um sistema que trata dados sensíveis e não tem como ser atualizado é o candidato prioritário à troca, com plano, prazo e orçamento. Até lá, fica encapsulado.
- Baixa criticidade com a atualização viável. Planejar para atualizar no ciclo regular, dentro da gestão de mudanças e com monitoramento do fim de vida.
- Baixa criticidade, atualização inviável. Propor para encapsular ou desativar. Retirar da internet, colocar atrás de VPN ou WAF, restringir acesso e registrar a exceção com dono e prazo. Muitas vezes, a melhor resposta é simplesmente “desligar”.
Em qualquer quadrante, aceitar o risco só é legítimo como decisão formal da alta direção, com prazo de validade. Nunca por omissão.
A agenda do CISO público
O PHP2Shell vai sair do noticiário, mas a dívida técnica continua. Proponho uma agenda em três horizontes, que pode ser adaptada ao porte e à maturidade de cada órgão.
1) Próximos 90 dias
- Inventariar todos os ativos que executam PHP e outros runtimes, inclusive sistemas de terceiros, hospedagem contratada e equipamentos, com versão e grau de exposição.
- Confirmar que as correções do PHP2Shell foram aplicadas e procurar indícios de comprometimento a partir de 20 de outubro, quando os detalhes vazaram.
- Classificar cada sistema nos quatro caminhos acima e registrar os riscos aceitos, com responsável e prazo.
- Cruzar o inventário com o encarregado de dados para identificar quais sistemas legados tratam dados sensíveis.
2) Em 12 meses
- Aprovar uma política de ciclo de vida de componentes: nenhum sistema em produção com runtime fora de suporte sem exceção formal.
- Padronizar cláusulas de segurança nos termos de referência: versões suportadas, prazo para correções críticas, SBOM e testes.
- Fazer o diagnóstico de maturidade com o OWASP SAMM e fixar metas anuais.
- Levar indicadores à alta direção: percentual de sistemas em versões suportadas, tempo médio para corrigir vulnerabilidades críticas e exceções vencidas.
3) Em 36 meses
- Executar o plano de substituição dos sistemas críticos sem caminho de atualização, com recursos previstos no planejamento orçamentário.
- Incorporar o desenvolvimento seguro, alinhado ao SSDF, a todas as contratações e equipes internas.
- Exercitar periodicamente o cenário de “falha crítica pública sem correção disponível”, com critérios pré-aprovados para tirar serviços do ar.
O preço de esperar
O PHP2Shell levou dois meses entre a descoberta e a correção. O próximo pode ser descoberto em dias e explorado em horas, porque as mesmas ferramentas de IA usadas pelos pesquisadores também estão ao alcance dos atacantes. A janela entre a divulgação e o ataque está encolhendo, e os sistemas legados estão do lado errado dela.
Os órgãos que tiraram sites do ar fizeram a escolha certa naquele momento. Mas desligar porque não se sabe o que está exposto é sintoma de falha de governança, e não sinal de prudência. O cidadão que entrega seus dados ao Estado não pode trocar de fornecedor, e isso torna a obrigação do poder público maior, não menor.
Atualizar ou substituir sistemas legados custa caro e não rende inauguração. Mas custa menos do que explicar à ANPD, ao Tribunal de Contas e à sociedade por que um dado sensível vazou por uma falha que tinha data de validade conhecida.
Referências
Entrar
