A descoberta de duas vulnerabilidades críticas no PHP, uma das linguagens mais utilizadas no desenvolvimento de aplicações web, colocou organizações públicas e privadas diante de uma decisão difícil: manter serviços digitais disponíveis ou interrompê-los temporariamente para reduzir riscos de segurança?

A pergunta parece operacional, mas revela um desafio muito mais profundo. Em ambientes digitais complexos, especialmente na administração pública, nem sempre é possível corrigir imediatamente uma vulnerabilidade sem afetar serviços essenciais. O desafio dos gestores de tecnologia é compreender a diferença entre reduzir a superfície de ataque, conter uma ameaça e efetivamente eliminar uma vulnerabilidade.

Essa distinção tornou-se particularmente importante após a divulgação, em 21 de outubro de 2026, das vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas classificadas com severidade crítica, com pontuação 9,2 no CVSS 4.0. Segundo o CERT-EU, elas podem permitir execução remota de código sem autenticação.

Por que as falhas críticas do PHP podem ocorrer antes da aplicação

Uma das características mais preocupantes dessas falhas é que sua exploração pode ocorrer durante o processamento interno de requisições pelo próprio PHP, antes mesmo de o código da aplicação começar a executar.

Na CVE-2026-109618, o problema está relacionado ao tratamento de falhas de alocação de memória. Em determinadas circunstâncias, o PHP pode interromper uma operação quando estruturas internas ainda não foram completamente inicializadas, provocando comportamentos inseguros durante a limpeza da memória.

Já a CVE-2026-109619 envolve a possibilidade de estruturas internas continuarem sendo referenciadas após a liberação da memória utilizada, criando condições para que requisições posteriores encontrem estados inconsistentes.

Não se trata, portanto, de uma falha restrita a um portal ou sistema específico. O problema pode afetar diferentes aplicações que utilizam versões vulneráveis do PHP, independentemente de seu código ter sido desenvolvido com boas práticas de programação.

Proxy, redirecionamento e nova requisição HTTP: isso reduz o risco?

Imagine um sistema público que disponibiliza documentos e publicações para consulta na internet. Para proteger uma aplicação legada, a equipe de tecnologia implementa um serviço intermediário que recebe a requisição original, extrai apenas os parâmetros necessários — como a data e o código de uma publicação — e constrói uma requisição completamente nova para o sistema interno.

Todos os parâmetros adicionais são descartados.

Essa arquitetura pode representar um avanço significativo na proteção do serviço, especialmente quando o componente intermediário também restringe métodos HTTP, tamanho das mensagens, formatos aceitos e destinos acessíveis.

Entretanto, existe uma condição fundamental: a requisição original não pode chegar ao componente vulnerável, e o sistema interno não pode permanecer diretamente acessível pela internet.

Mesmo nessa arquitetura, a proteção não é absoluta. O serviço intermediário precisa resistir a entradas maliciosas, evitar encaminhar conteúdo não validado e impedir caminhos alternativos que permitam alcançar diretamente o PHP.

Uma simples regra de redirecionamento HTTP, por exemplo, não oferece necessariamente essas garantias. Há uma diferença importante entre devolver ao navegador uma instrução para acessar outro endereço e implementar um serviço que efetivamente reconstrói, valida e controla a requisição antes de encaminhá-la.

Mitigação não é correção: o que realmente resolve a vulnerabilidade

Na gestão de segurança da informação, os termos mitigação e correção são frequentemente utilizados como sinônimos. Não deveriam.

Mitigar significa reduzir a probabilidade de exploração ou limitar suas consequências. Corrigir significa eliminar a causa técnica conhecida da vulnerabilidade.

Uma organização pode bloquear o acesso externo a um sistema, implementar um proxy de segurança, restringir funcionalidades ou criar uma camada intermediária de acesso. Todas essas medidas podem reduzir riscos. Nenhuma delas, isoladamente, altera o código vulnerável existente na versão do PHP utilizada.

As versões 8.1 e anteriores já não recebem correções oficiais do projeto PHP, embora determinados fornecedores possam disponibilizar correções específicas em seus pacotes.

Como equilibrar disponibilidade e segurança diante de uma vulnerabilidade crítica

A discussão é especialmente relevante para o setor público, onde a indisponibilidade de um serviço pode afetar cidadãos, empresas, servidores e o funcionamento de atividades institucionais.

É comum que as equipes enfrentem uma aparente escolha entre manter um sistema vulnerável disponível ou interromper completamente sua operação.

Mas há alternativas intermediárias que precisam ser avaliadas.

Um portal pode manter a consulta a documentos por meio de uma camada de acesso isolada. Uma aplicação pode ter suas funcionalidades de escrita temporariamente suspensas, preservando consultas de menor risco. Um serviço interno pode continuar funcionando em rede restrita enquanto seus componentes são atualizados.

Essas alternativas, contudo, só são aceitáveis quando sustentadas por análise técnica, testes e documentação das condições de segurança.

Cinco decisões que diferenciam uma resposta improvisada de uma resposta madura

A gestão de uma vulnerabilidade crítica exige decisões coordenadas entre segurança, infraestrutura, desenvolvimento e governança.

Vulnerabilidades críticas também expõem a dívida tecnológica invisível

Episódios como esse também revelam uma fragilidade estrutural: muitas organizações não sabem exatamente quais tecnologias sustentam seus serviços digitais.

Sistemas continuam funcionando durante anos, frequentemente atendendo bem às necessidades dos usuários, enquanto suas dependências envelhecem silenciosamente. Linguagens, bibliotecas, servidores e frameworks deixam de receber atualizações, mas permanecem em produção porque a modernização não parece urgente.

Até que uma vulnerabilidade crítica transforme aquilo que era considerado uma dívida tecnológica administrável em uma ameaça imediata à continuidade do serviço.

A resposta adequada não é apenas corrigir a falha da semana. É construir processos permanentes de gestão de ativos tecnológicos, dependências, vulnerabilidades e ciclos de vida.

Isso requer investimento em observabilidade, automação de atualizações, testes de regressão, ambientes de homologação e arquiteturas que permitam substituir componentes sem comprometer a operação institucional.

Mais importante, requer que a segurança deixe de ser percebida como uma barreira à transformação digital e passe a ser reconhecida como uma condição para sua sustentabilidade.

A pergunta que os gestores deveriam fazer

Diante de uma vulnerabilidade crítica, a pergunta mais frequente costuma ser: “O sistema continua funcionando?”

Mas há uma pergunta muito mais relevante: “Sabemos demonstrar que ele está funcionando dentro de condições aceitáveis de segurança?”

Uma aplicação disponível pode estar insegura. Um sistema protegido por controles intermediários pode continuar vulnerável. E uma atualização aparentemente concluída pode não ter alcançado todos os componentes expostos.

O episódio do PHP reforça uma lição fundamental para a liderança digital: segurança não se resume à instalação de correções, assim como disponibilidade não se resume a manter servidores ligados.

Ambas dependem de arquitetura, governança, capacidade de resposta e decisões baseadas em evidências.

Reduzir a exposição é importante. Isolar um serviço pode ser necessário. Mas nenhuma dessas medidas deve ser confundida com a eliminação de uma vulnerabilidade.