A vulnerabilidade não estava no seu site

Um site pode funcionar perfeitamente e, ainda assim, estar exposto a uma vulnerabilidade crítica.

As páginas carregam normalmente, os formulários respondem, os utilizadores conseguem aceder às suas contas e os serviços continuam a funcionar sem incidentes aparentes. Não há erros visíveis nem sinais de que algo exija a nossa atenção imediata.

Até surgir um aviso de segurança que altera por completo a situação.

A 21 de outubro de 2026, a equipa de desenvolvimento do PHP publicou atualizações urgentes para corrigir duas vulnerabilidades críticas, identificadas como CVE-2026-109618 e CVE-2026-109619, ambas com uma pontuação de 9,2 em 10 segundo o CVSS v4.0.

As falhas estavam relacionadas com a gestão interna da memória e do estado dos pedidos. Em determinadas condições, podiam permitir que um atacante executasse código remotamente sem necessidade de autenticação. A recomendação oficial foi atualizar imediatamente as instalações afetadas que processassem pedidos web, uma vez que as medidas temporárias de mitigação não ofereciam proteção completa.

A gravidade do incidente rapidamente ultrapassou o âmbito estritamente técnico. A Agência de Segurança Nacional dos Estados Unidos (NSA) recomendou às organizações que utilizavam PHP que preparassem as atualizações e considerassem desligar temporariamente os sistemas quando não fosse possível corrigi-los de imediato.

A resposta também partiu das próprias plataformas. O Drupal.org e outros serviços relacionados foram temporariamente retirados da rede enquanto os seus responsáveis aplicavam as correções. A Drupal Association esclareceu que o problema não estava no Drupal, mas sim no PHP, e que os seus mecanismos habituais de proteção não resolviam esta vulnerabilidade.

O que era especialmente preocupante não era apenas a gravidade das vulnerabilidades, mas o local onde se encontravam.

Não falamos necessariamente de um erro num plugin de WordPress nem de uma funcionalidade desenvolvida sem as precauções necessárias. As falhas encontravam-se no interpretador de PHP, uma tecnologia da qual dependem numerosas aplicações web.

Isto significa que uma organização podia ter mantido corretamente a sua aplicação, aplicado as suas atualizações e seguido as recomendações habituais de segurança e, ainda assim, continuar exposta devido a uma vulnerabilidade num dos componentes de que precisava para funcionar.

Durante anos, associámos boa parte da segurança web à atualização do nosso software, à correção de erros de programação e à configuração adequada das ferramentas que utilizamos. São práticas fundamentais, mas incidentes como este recordam-nos que a segurança de uma aplicação também depende de elementos que nem sempre vemos e sobre os quais não temos controlo direto.

O facto de um site funcionar corretamente não significa que tudo aquilo de que necessita para funcionar seja seguro.

As vulnerabilidades publicadas a 21 de outubro convidam-nos a analisar não só como se corrige uma falha crítica, mas também o que significa manter a infraestrutura sobre a qual uma aplicação funciona.

O código que não escrevemos também nos pode comprometer

Quando desenvolvemos uma aplicação web, costumamos concentrar boa parte dos nossos esforços de segurança no código que escrevemos: validar os dados que recebemos, controlar as permissões de acesso, proteger as sessões ou impedir que uma entrada maliciosa acabe por ser executada como uma instrução.

No entanto, antes de a nossa aplicação poder realizar qualquer uma destas operações, intervêm outras tecnologias que tratam de receber, interpretar e processar os pedidos.

Numa aplicação desenvolvida com PHP, parte desse trabalho cabe ao próprio interpretador. É o componente responsável por executar o nosso código, mas também realiza operações internas relacionadas com a gestão de memória, as sessões e o processamento dos pedidos HTTP.

As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 afetam precisamente este nível.

A primeira está relacionada com o tratamento de erros quando se esgota a memória disponível. A segunda, com a reutilização incorreta de determinados estados internos entre pedidos. Em ambos os casos, as falhas podem permitir que um atacante altere o comportamento do interpretador e chegue a executar código não autorizado.

O mais relevante é que, segundo a análise técnica publicada pela Datadog Security Labs, a exploração pode ocorrer antes de o PHP chegar a executar o código da aplicação.

Podemos ter desenvolvido corretamente os nossos mecanismos de autenticação, aplicado controlos aos formulários e revisto as funcionalidades expostas ao exterior. Mas, se um pedido malicioso explorar uma falha no processamento interno do PHP, essas proteções podem nem chegar a intervir.

Isto não significa que todas as instalações sejam igualmente vulneráveis nem que qualquer pedido permita comprometer um servidor. A exposição efetiva depende das versões, configurações e condições de execução.

A questão é que a segurança do nosso código e a segurança do ambiente que o executa são responsabilidades diferentes, embora inseparáveis.

Podemos controlar a forma como desenvolvemos uma aplicação, mas nem sempre podemos corrigir diretamente os defeitos das ferramentas sobre as quais ela funciona. Nesses casos, dependemos das correções publicadas pelos seus responsáveis e da nossa capacidade para as incorporar corretamente.

E é aí que surge um novo desafio: depois de o fornecedor publicar uma solução, ainda temos de conseguir que essa correção chegue de forma segura aos nossos sistemas.

Atualizar não é o mesmo que estar protegido

Quando é publicada uma correção para uma vulnerabilidade crítica, a recomendação costuma ser imediata: atualizar o mais depressa possível. Mas entre a disponibilidade de um patch e a certeza de que um sistema está protegido existe um processo que nem sempre é tão simples como parece.

Um dos aspetos que pode gerar confusão é a numeração das versões.

Distribuições como o Ubuntu mantêm determinadas versões do PHP durante anos e aplicam-lhes correções de segurança através de um procedimento conhecido como backporting. Isto permite incorporar patches de versões posteriores sem necessidade de alterar toda a versão do interpretador, algo especialmente importante em servidores de produção onde as aplicações dependem de versões específicas.

Assim, por exemplo, o PHP 8.1 distribuído pelo Ubuntu 22.04 pode receber correções de segurança específicas, embora essa versão já não receba atualizações do projeto PHP. Não devemos confundir o suporte do fabricante da distribuição com o do projeto original.

Uma versão aparentemente antiga não significa necessariamente que seja vulnerável, da mesma forma que uma versão mais recente não garante, por si só, que inclua uma correção concreta.

No caso das vulnerabilidades de 21 de outubro, o Ubuntu publicou pacotes corrigidos para as suas distribuições compatíveis. A verificação adequada não consistia apenas em consultar a versão do PHP, mas também em confirmar a origem dos pacotes e que as correções correspondentes aos CVE estavam efetivamente incorporadas.

Mas a verificação não termina com a instalação dos pacotes. Também é necessário confirmar que versão o serviço web utiliza realmente, se os processos foram reiniciados quando necessário e se as aplicações continuam a funcionar corretamente.

Uma atualização pode ter sido concluída sem erros e, ainda assim, deixar processos a executar código anterior ou provocar incompatibilidades que não são detetadas até alguém utilizar uma funcionalidade específica.

Por isso, convém distinguir entre três situações: ter uma correção disponível, tê-la instalado e ter confirmado que está aplicada no ambiente que efetivamente presta o serviço.

A segurança não deveria basear-se apenas na confiança de ter atualizado, mas na capacidade de demonstrar o que foi corrigido e o que continua a funcionar.

E essa verificação exige algo que nem sempre podemos improvisar durante uma emergência: tempo para intervir, verificar os resultados e reagir se surgirem problemas.

A segurança também é uma questão de tempo

Um dos aspetos mais relevantes deste incidente é o papel da inteligência artificial na investigação. Segundo a OpenAI, a Calif identificou uma das falhas com a ajuda do GPT-5.6 Sol; a Wiz, de forma independente, descobriu e comunicou ambos os problemas, utilizando também modelos de IA na sua investigação, segundo a Google Cloud. Estas ferramentas contribuíram para a análise técnica e para a verificação das correções.

Isto não significa que a inteligência artificial tenha substituído os investigadores de segurança. A descoberta, a avaliação dos riscos e a coordenação com os responsáveis pelo PHP continuaram a exigir intervenção humana. Mas demonstra como estas ferramentas podem ampliar a capacidade de analisar grandes quantidades de código e identificar problemas difíceis de detetar através dos procedimentos tradicionais.

Se cada vez conseguimos descobrir vulnerabilidades mais depressa, estamos preparados para as corrigir ao mesmo ritmo?

Identificar uma falha não significa que todos os sistemas afetados possam ser atualizados imediatamente. As correções têm de ser desenvolvidas, distribuídas e aplicadas em infraestruturas com características muito diferentes. Algumas organizações dispõem de equipas especializadas e de processos de implementação automatizados. Outras dependem de intervenções manuais, de fornecedores externos ou de aplicações antigas que exigem verificações adicionais.

A inteligência artificial pode ajudar a reduzir o tempo necessário para descobrir uma vulnerabilidade, mas não elimina automaticamente o trabalho necessário para a corrigir em produção. E essa aceleração também pode beneficiar quem procura explorar as falhas antes de as organizações terem aplicado as atualizações.

Por isso, o verdadeiro desafio não consiste apenas em detetar mais problemas e fazê-lo mais cedo. Também precisamos de reduzir o tempo que decorre entre conhecer uma vulnerabilidade e conseguir que os sistemas afetados voltem a operar com as correções necessárias.

A velocidade da descoberta está a mudar. A nossa capacidade de resposta também terá de mudar.

O dia da emergência não é o momento de descobrir o que temos

Quando é anunciada uma vulnerabilidade crítica, uma das primeiras perguntas deveria ser relativamente simples: que sistemas temos afetados?

No entanto, respondê-la nem sempre é fácil.

Em muitas organizações, a infraestrutura tecnológica evoluiu ao longo de anos. Foram migradas aplicações, contratados novos fornecedores, incorporados serviços e mantidos servidores antigos porque ainda alojam alguma funcionalidade necessária. Parte dessa informação está documentada, mas outra parte depende do conhecimento de quem participou em cada projeto.

Enquanto tudo funciona, esta situação pode passar despercebida. O problema surge quando precisamos de intervir com urgência.

Identificar que servidores utilizam uma determinada versão de PHP, que aplicações dependem dela ou que repositórios fornecem as atualizações pode então transformar-se numa investigação que consome um tempo especialmente valioso.

Também precisamos de saber se existem cópias de segurança recuperáveis, se podemos testar as alterações antes de as aplicar em produção e que procedimento seguiremos se uma atualização provocar uma incompatibilidade. Mesmo aspetos aparentemente secundários, como o espaço disponível em disco, podem condicionar uma intervenção urgente.

A diferença não está apenas em dispor de ferramentas de monitorização ou de uma equipa especializada. Também reside em decisões muito mais básicas: manter atualizado o inventário tecnológico, documentar as configurações relevantes, definir responsabilidades e verificar periodicamente que os mecanismos de recuperação funcionam.

Estas tarefas raramente têm a visibilidade de um novo desenvolvimento ou de uma funcionalidade que melhora a experiência do utilizador. O seu valor costuma tornar-se evidente precisamente quando algo falha.

Durante este incidente, algumas organizações também optaram por desligar temporariamente determinados serviços enquanto aplicavam as correções de segurança. É o caso da ICANN e do Instituto Europeu de Patentes. Estas decisões mostram que responder a uma vulnerabilidade nem sempre consiste em manter tudo a funcionar: em determinadas circunstâncias, interromper temporariamente um serviço pode ser a opção mais prudente para reduzir a exposição enquanto se aplica uma solução.

Por isso, uma organização preparada não é aquela que pode garantir que nunca terá problemas de segurança. É aquela que, quando surge uma ameaça, não precisa de começar por descobrir como funciona a sua própria infraestrutura.

A capacidade de responder a uma vulnerabilidade não se constrói durante a emergência. É o resultado da manutenção e das decisões que tomámos muito antes de ela surgir.

Conclusão

As vulnerabilidades do PHP recordam-nos que nenhum sistema pode garantir a ausência absoluta de falhas. As boas práticas de desenvolvimento e a manutenção reduzem os riscos, mas não eliminam a possibilidade de surgirem vulnerabilidades desconhecidas em tecnologias consolidadas.

Por isso, talvez devêssemos deixar de entender a segurança como um estado que alcançamos depois de instalar determinadas ferramentas ou concluir uma série de verificações.

A segurança não é algo que conseguimos uma vez e podemos dar por terminado. É uma responsabilidade que devemos manter ao longo do tempo.

Isto implica assumir que, mais cedo ou mais tarde, alguma das tecnologias que utilizamos necessitará de uma correção urgente. E que a nossa capacidade para identificar o problema, avaliar o seu alcance, intervir e verificar os resultados será tão importante como as medidas preventivas que tenhamos adotado.

Uma infraestrutura fiável não é aquela que nunca necessita de uma intervenção, mas aquela que consegue enfrentar as alterações e os incidentes sem perder o controlo sobre o seu funcionamento.

No final, não podemos garantir que nenhuma tecnologia falhe, mas podemos decidir até que ponto estamos preparados para responder quando isso acontecer.

E essa é a pergunta que convém fazer mesmo quando os nossos sistemas não foram afetados:

Conhecemos suficientemente bem a nossa infraestrutura para responder quando uma tecnologia da qual dependemos deixa de ser segura?

Sabe em que estado se encontra a sua infraestrutura web?

Uma vulnerabilidade crítica não deveria ser o momento em que descobre como estão configurados os seus servidores ou quem é realmente responsável pela sua manutenção.

Na ITDO, podemos ajudá-lo a analisar a sua infraestrutura, identificar possíveis riscos e definir uma estratégia de manutenção e atualização adaptada às necessidades do seu projeto.

Vamos falar sobre o seu projeto