Lisboa, 22 de outubro de 2026

Na sequência do alerta publicado ontem pela CpC: Cidadãos pela Cibersegurança, fazemos o ponto de situação sobre as duas vulnerabilidades críticas no PHP, agora conhecidas como PHP2Shell. Chamamos também a atenção para a exposição de Portugal e para um segundo incidente, ocorrido na mesma semana, que atinge outro alicerce da internet: os certificados que garantem a autenticidade dos sítios.

Não é alarmismo!

Para quem considere exagerados os alertas destes dias, convém dizer com clareza: não são. A gravidade não está apenas nas falhas em si, mas onde onde estas se encontram. Nenhuma das duas está numa aplicação que o utilizador veja ou que o responsável por um sítio pudesse evitar. Estão nos alicerces dos sites: no motor que faz funcionar uma enorme parte da web e no sistema que certifica que um sítio é quem diz ser.

O que está confirmado sobre o PHP2Shell

As duas falhas estão identificadas como CVE-2026-109618 e CVE-2026-109619. A equipa de segurança do PHP atribui a ambas a pontuação de 9,2 na escala CVSS v4.0 e reconhece que podem permitir a execução remota de código sem autenticação. Isto significa que um atacante pode executar instruções num servidor sem conhecer qualquer palavra-passe.

A gravidade decorre do facto de a falha estar no próprio motor da linguagem, e não numa aplicação concreta. Em certas configurações, o ataque ocorre antes de ser executada uma única linha da aplicação, pelo que não importa quão bem esta esteja programada. As correções foram publicadas a 21 de outubro e as falhas afetam todos os servidores web com PHP 5.4 ou posterior. Investigadores demonstraram execução de código sem autenticação em Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony e WHMCS. Muitos sítios públicos portugueses assentam precisamente nalgumas destas plataformas.

As versões corrigidas são o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O projeto PHP sublinha que as versões 8.1 e anteriores já não recebem atualizações diretamente do projeto. Este é o ponto mais preocupante: segundo dados da Censys, cerca de 1,5 milhões de 2,6 milhões de servidores analisados correm uma versão de PHP para a qual não existe correção.

Para estes servidores, a solução não é carregar num botão. Os responsáveis dependem de a sua distribuição ou o seu fornecedor de alojamento disponibilizarem uma correção adaptada. A alternativa, migrar para uma versão moderna do PHP, pode deixar de funcionar com aplicações antigas que não sejam compatíveis. É exatamente o cenário de muitos sítios públicos desenvolvidos há anos por empresas externas e nunca atualizados.

Como foram descobertas e como se tornaram públicas

A Calif encontrou uma das falhas com o modelo GPT-5.6 Sol, da OpenAI, e a Wiz encontrou ambas, de forma independente, com a sua ferramenta Atlas e os modelos Gemini 4 Argon, da Google, e GPT-5.6 Sol. A Fundação PHP indicou que um programador já tinha detetado sinais do problema de memória durante a auditoria externa de 2024, mas sem identificar, nessa altura, uma via concreta de exploração.

A divulgação coordenada estava prevista para 22 de outubro. Segundo a Fundação PHP, a publicação foi antecipada um dia depois de os identificadores das vulnerabilidades terem sido divulgados indevidamente.

A exploração está em curso e a crescer

A Cloudflare registou os primeiros ataques às 07h43 UTC de 21 de outubro, antes da publicação das correções. Números atribuídos a responsáveis da Cloudflare e divulgados nas redes sociais, ainda não confirmados em comunicado oficial, dão uma ideia da escala. Nas dez horas anteriores ao anúncio público, a rede da empresa terá registado milhares de tentativas de exploração. Nos 45 minutos seguintes, dezenas de milhares. Duas horas depois, centenas de milhares. Atualmente, milhões.

A Hadrian refere ter observado exploração em larga escala a partir das 11h35 UTC de 21 de outubro, e a Patchstack afirma ter confirmado vários incidentes de exploração ativa. Há também avaliações mais prudentes: a watchTowr viu tentativas de exploração nos seus sensores, mas sem casos bem-sucedidos até então. Com o código de exploração já público, a CpC considera prudente presumir que a exploração automatizada em massa está em curso.

A reação europeia: desligar primeiro, corrigir depois

Vários Estados europeus optaram por retirar sítios públicos do ar por precaução. Em França, por instrução da ANSSI, foram colocados fora de linha os sítios das prefeituras, incluindo a da Polícia de Paris, o portal dos impostos e, mais tarde, o sítio da Météo-France.

Nos Países Baixos, ficaram fora de linha, entre outros, a Câmara dos Representantes e o próprio NCSC. Um fornecedor que serve mais de cem autarquias neerlandesas desligou os sítios municipais de cidades como Den Bosch, Breda e Eindhoven. Circulam ainda relatos, não confirmados pela CpC, de que serviços de identificação digital e portais do cidadão, como o DigiD e o MijnOverheid, e vários hospitais terão sido desligados preventivamente.

Na Alemanha, depois do alerta oficial do BSI, ficaram inacessíveis os sítios dos Bombeiros de Berlim, a esquadra digital da Polícia e a Polícia Federal, bem como o da Charité.

Do outro lado do Atlântico, a Casa Branca afirma ter tido conhecimento das falhas na sexta-feira, 16 de outubro. A OpenAI indica que envolveu, antes da divulgação, a Super Intelligence Force da Casa Branca, o Gabinete do Diretor Nacional de Cibersegurança e a CISA, para que as orientações chegassem a entidades de infraestruturas críticas. A OpenAI refere também “parceiros internacionais”, sem os identificar.

Na mesma semana: certificados falsificáveis

O PHP2Shell não chegou sozinho. A 17 de outubro, um investigador conhecido como Wayne descobriu que oito certificados intermédios da autoridade de certificação indiana eMudhra tinham chaves privadas de tal forma fracas que qualquer pessoa as conseguia recuperar a partir dos certificados públicos em menos de um segundo. As chaves foram geradas em abril de 2025 com valores inferiores a 256. Um investigador demonstrou que a chave privada de um desses certificados era literalmente o número 4.

Para perceber a gravidade, pode comparar-se um certificado HTTPS ao cartão de identificação de um sítio: é o que permite ao navegador confirmar que o utilizador está no sítio verdadeiro e não numa imitação. As autoridades de certificação emitem esses cartões, e a sua chave privada é o selo que os torna válidos. Com essas chaves, um atacante podia criar um certificado falso para qualquer domínio e fazer-se passar por servidores legítimos para intercetar ou alterar tráfego. Isto inclui o sítio de um banco, das Finanças ou do correio eletrónico. Dois dos oito certificados destinavam-se também à assinatura de software, o que permitiria fazer passar código malicioso por legítimo.

O Chrome e o Firefox bloquearam os certificados no próprio dia da comunicação, a Apple a 19 de outubro e a Microsoft a 20. A eMudhra revogou-os a 18. A empresa afirma não ter encontrado indícios de utilização indevida, mas não se sabe se alguém recuperou e usou as chaves nos 17 meses anteriores à descoberta. O restante software que confia nestes certificados está a ser corrigido a ritmo mais lento. A linguagem Go, por exemplo, publicou as versões 1.27.3 e 1.26.10 para resolver a questão.

Há também uma consequência prática para entidades portuguesas: o Chrome deixará de confiar na raiz emSign ECC Root CA – G3 a 27 de outubro. Quem tenha certificados ligados a essa raiz deve substituí-los imediatamente por certificados de outra hierarquia, sob pena de os seus sítios deixarem de abrir.

E em Portugal?

O Centro Nacional de Cibersegurança emitiu recomendações às organizações na quarta-feira, incluindo a aplicação imediata da atualização e o inventário de todas as instalações de PHP, incluindo as menos evidentes. Até ao fecho deste texto, a CpC não encontrou relatos públicos de sítios da Administração Pública portuguesa retirados do ar por precaução, como sucedeu em França, nos Países Baixos e na Alemanha.

Não existe um levantamento oficial e público do número de sítios portugueses que correm PHP. Para obter uma primeira indicação, a CpC fez uma pesquisa passiva no Shodan, um motor de busca que indexa servidores ligados à internet. Os resultados indicam que correm PHP pelo menos:

23 sítios de câmaras municipais;
7 sítios do domínio gov.pt.

O número obtido é um mínimo, não o total. Muitos servidores escondem o cabeçalho que identifica o PHP (X-Powered-By), e o Cloudflare ou outros intermediários ocultam o servidor de origem. Os dados do Shodan podem também ter dias ou semanas, pelo que um sítio identificado pode já ter sido atualizado e outros não identificados podem estar vulneráveis. A pesquisa limitou-se a informação publicamente indexada; a CpC não testou nenhum servidor.

Considerando a quota do PHP na web e a prevalência de plataformas como WordPress, Joomla e Drupal no setor público, é razoável admitir que o universo real seja muito superior e que, contando todos os setores, estejam em causa milhares de sítios em Portugal. Entre eles contam-se portais de câmaras municipais e juntas de freguesia, sítios de organismos da Administração Central, escolas, agrupamentos, universidades, hospitais, associações e comércio eletrónico. O país tem 308 municípios e mais de três mil freguesias, muitos com sítios desenvolvidos por empresas externas, alojados em servidores partilhados e sem manutenção regular. São precisamente estes os que mais provavelmente correm versões antigas do PHP, sem correção disponível.

Um sítio autárquico comprometido não é apenas um problema de imagem. Pode expor dados pessoais de munícipes recolhidos em formulários, servir para distribuir software malicioso ou páginas de phishing com aparência oficial, ou funcionar como porta de entrada para outros sistemas da autarquia.

Questões que a CpC deixa às autoridades

1. O CNCS e o CERT.PT estiveram entre os “parceiros internacionais” informados antes da divulgação pública? Em caso afirmativo, as entidades públicas portuguesas foram alertadas antecipadamente?
2. Existe um inventário no CNCS, ainda que aproximado, dos sítios da Administração Central e Local que correm PHP, e das versões em uso?
3. Por que razão Portugal não seguiu a abordagem preventiva adotada pela ANSSI e pelo NCSC neerlandês? Houve uma avaliação de risco que a justifique?
4. Que apoio técnico será disponibilizado às autarquias e freguesias de menor dimensão, que dependem de prestadores externos e não têm equipas próprias de segurança?
5. Foi verificado se algum serviço público português utiliza certificados emitidos sob a hierarquia emSign afetada, e se esses certificados serão substituídos antes de 27 de outubro?
   

O que fazer agora: responsáveis por sítios e servidores

As recomendações do CNCS e dos investigadores convergem:

1. Atualizar de imediato para uma versão corrigida e reiniciar todos os processos PHP. Quem use PHP 8.1 ou anterior deve confirmar junto da distribuição ou do fornecedor se existe uma correção adaptada, ou planear a migração para uma versão suportada, testando a compatibilidade das aplicações. Se não for possível atualizar, ponderar seriamente retirar o sítio do ar até à correção.
2. Verificar se o servidor já foi comprometido. A análise deve cobrir todo o período desde 20 de outubro, data em que a vulnerabilidade se tornou conhecida, porque a atualização trava novos ataques mas não remove acessos já instalados. Havendo indícios de comprometimento, o CNCS recomenda isolar o servidor, preservar os registos e procurar webshells, ficheiros novos, tarefas agendadas e contas criadas recentemente.
3. Quem usa alojamento partilhado deve contactar hoje o fornecedor e confirmar por escrito que a atualização foi aplicada. Atualizar o WordPress não basta, porque a falha está numa camada abaixo. As associações, coletividades e juntas que dependem de um técnico externo devem fazer-lhe chegar este alerta.
4. Ocultar o cabeçalho X-Powered-By reduz a exposição a pesquisas automáticas, mas não corrige nada: só a atualização protege.
5. Verificar se algum certificado em uso foi emitido sob a raiz emSign ECC Root CA – G3 e, em caso afirmativo, substituí-lo antes de 27 de outubro.

As entidades abrangidas pelo regime jurídico da segurança do ciberespaço devem avaliar se uma eventual exploração configura um incidente de notificação obrigatória ao CERT.PT.

O que fazer agora: cidadãos

Os nossos dados não estão no nosso computador. Estão nos servidores das lojas, entidades públicas e serviços que usamos, e muitos deles correm PHP. Se algum não for atualizado a tempo, quem lá entrar pode roubar esses dados ou alterar o sítio para enganar os visitantes. O cidadão pouco pode fazer quanto a isso, mas pode reduzir o impacto:

1. Usar uma palavra-passe diferente em cada sítio e ativar a autenticação de dois fatores sempre que exista. Assim, uma fuga num serviço não abre a porta aos outros.
2. Estar atento a avisos dos serviços que utiliza e desconfiar, nos próximos dias, de pedidos invulgares de dados pessoais ou de pagamentos, mesmo em sítios oficiais. Em caso de dúvida, confirmar por outro canal antes de preencher formulários.
3. Manter o telemóvel, o computador, o navegador e as aplicações atualizados. No caso eMudhra, alguém que controle a ligação, por exemplo numa rede Wi-Fi pública ou num router comprometido, poderia encaminhar o utilizador para um sítio falso sem que este notasse. Os navegadores já bloquearam os certificados afetados, mas só nas versões atualizadas.
4. Quem tenha um blogue ou um pequeno sítio deve perguntar ao fornecedor de alojamento se já atualizou o PHP.

Conclusão

Numa só semana, ficaram expostos dois dos alicerces em que assenta a confiança na internet: quem certifica que um sítio é autêntico e o motor que faz funcionar grande parte da web. Em ambos os casos, as falhas existiam há muito tempo e foram encontradas com recurso a ferramentas cada vez mais capazes, incluindo inteligência artificial. Estas ferramentas estão também ao alcance de quem ataca. Para Portugal, a questão não é se haverá sítios públicos comprometidos, mas quantos, e se as entidades responsáveis terão agido a tempo de o evitar. Estaremos atentos.