Outubro negro na segurança: agentes de IA, PHP, Node.js e chaves expostas. O que a sua empresa deve fazer

Entre 14 e 23 de outubro de 2026, a segurança da Internet teve vários sustos seguidos: duas falhas críticas no PHP, uma falha grave no Node.js, duas plataformas de alojamento com as chaves dos clientes expostas, uma autoridade de certificação com chaves privadas que se adivinhavam num segundo e relatórios da Microsoft e da CrowdStrike sobre ataques conduzidos por agentes de inteligência artificial. Nas redes sociais, já lhe chamam o "outubro negro".

Sobre a falha do PHP já escrevemos três artigos práticos: PHP2Shell: a falha crítica do PHP e o que fazer no seu site, Actualizar o PHP sem partir o site e O site foi pirateado: o que fazer nas primeiras horas. Aqui olhamos para a vaga inteira: o que aconteceu e o que está confirmado, porque é que a IA encurta o tempo entre a correção e o ataque e o que uma empresa portuguesa deve verificar esta semana.

Prefere ver? Resumimos o outubro negro e o que verificar em minuto e meio neste vídeo:

Primeiro, o vocabulário: o que é cada coisa

PHP é a linguagem de programação que corre no servidor e monta as páginas de grande parte dos sites. A Wiz estima que esteja por trás de 70% dos sites. Se o site é em WordPress, WooCommerce, Joomla ou Drupal, usa PHP.
Node.js é outro "motor" para correr código no servidor, em JavaScript. É usado por sites e lojas modernas (por exemplo, feitos com Next.js), por APIs e por integrações.
Variáveis de ambiente e chaves secretas são as "chaves do cofre" de uma aplicação: a palavra-passe da base de dados, a chave da API de pagamentos, o acesso ao serviço de email ou à IA. Ficam guardadas na plataforma de alojamento, fora do código. Quem as lê pode fazer-se passar pela sua aplicação.
Certificados TLS são o que permite o cadeado e o "https://" no navegador. Garantem que o visitante está mesmo no seu site e que ninguém lê os dados pelo caminho. São emitidos por autoridades de certificação em que os navegadores confiam.

Por fim, execução remota de código quer dizer que um atacante, a partir da Internet, põe o seu servidor a fazer o que quiser. É o tipo de falha mais grave.

O que aconteceu, caso a caso

PHP: duas falhas 9,2 e governos a desligar servidores por precaução

A 21 de outubro, o PHP corrigiu duas falhas no próprio motor da linguagem, a CVE-2026-109618 e a CVE-2026-109619. Ambas têm nota 9,2 em 10 e permitem executar código no servidor sem qualquer autenticação. Segundo a Wiz, o problema está no próprio PHP, não na aplicação, e permite também ler da memória palavras-passe e chaves de API.

A Wiz diz que usou modelos de IA de fronteira para encontrar as falhas e construir o ataque: um investigador fez numa semana o que antes levaria meses a uma equipa de topo. A PHP Foundation conta que ferramentas de revisão de código com IA levaram também a Calif, a OpenAI e a Trail of Bits às mesmas falhas.

A janela para corrigir foi curtíssima. Segundo a Fundação, uma empresa publicou imagens já corrigidas horas antes do anúncio, e a partir daí "qualquer atacante podia estudar a correção". A Amazon viu uma tentativa de ataque a 17 de outubro, quatro dias antes da divulgação, e várias provas de conceito na madrugada de dia 21.

No Brasil, vários organismos desligaram sistemas:

O Governo federal mandou retirar temporariamente do ar os sistemas feitos em PHP, segundo uma nota do Ministério da Gestão.
A Anatel desligou o seu sistema de processos (SEI) entre as 12h15 e as 22h05 de dia 21, e vários tribunais regionais federais cortaram o acesso externo, como relata o iG.
Em Rondónia, os portais do Governo do estado e do Tribunal de Justiça continuavam bloqueados a 23 de outubro. O portal de Porto Velho voltou no próprio dia.
No Rio de Janeiro, portais do estado e de municípios saíram do ar e voltaram a 22.

Até agora, não há confirmação de invasões nestes organismos: as paragens foram preventivas. Em Portugal, o Centro Nacional de Cibersegurança recomendou a atualização imediata, um inventário das instalações de PHP e a monitorização dos processos que o PHP cria.

Node.js: uma falha grave no mesmo dia

Também a 21 de outubro, o Node.js corrigiu a CVE-2026-111497, de gravidade alta. Quando uma aplicação descomprime dados em formato Brotli preparados por um atacante, este pode corromper a memória, ler dados do processo ou executar código. Foi a equipa de segurança do Codex, da OpenAI, que a comunicou. As versões corrigidas são a 22.23.4, a 24.22.1 e a 26.12.1. O Node.js 20 já chegou ao fim de vida e não recebe esta correção.

Nas redes, diz-se que a Vercel protegeu os sites antes da correção. A Vercel escreve que ativou regras de firewall (WAF) "no mesmo dia" para todos os projetos que aloja, enquanto atualiza o Node.js. E avisa que essas regras não protegem servidores Node.js fora da Vercel.

Railway e Zeabur: as chaves guardadas no alojamento

Na manhã de 21 de outubro, a plataforma de alojamento Railway detetou atividade anómala nos sistemas que guardam as variáveis de ambiente dos clientes. Um terceiro pode ter lido algumas delas já desencriptadas. A Railway pediu a todos os clientes que trocassem todas as chaves e pausou os deploys. Diz que o ataque faz parte de uma série contra plataformas, para chegar a fornecedores de IA.

A Zeabur, popular entre quem cria aplicações e automações com IA, foi atacada a 14 e 15 de outubro. O atacante usou credenciais internas que estavam guardadas em texto simples e leu os dados de 321 810 contas e mais de 3,2 milhões de variáveis de ambiente. Procurava sobretudo chaves de serviços de IA. Era o segundo incidente em dois meses, e a Zeabur anunciou que encerra a 31 de dezembro.

Certificados: a chave privada era o número 4

A 17 de outubro, a Mozilla recebeu um alerta: as chaves privadas de oito certificados intermédios da autoridade de certificação indiana eMudhra estavam comprometidas. Segundo The Register, o investigador Scott Helme descobriu que uma delas era, literalmente, o número 4; outras eram 56 e 115. Deviam ser números aleatórios enormes, impossíveis de adivinhar. Com elas, um atacante podia criar certificados falsos para qualquer domínio e fazer-se passar por qualquer site. Os certificados foram revogados, e a Mozilla, o Chrome, a Apple e o próprio Node.js deixaram de confiar neles.

Ataques conduzidos por agentes de IA

A Microsoft atribui a um grupo alinhado com o Estado chinês, o Storm-0940, o uso de uma plataforma de agentes de IA, o ARTEX, para automatizar ataques. Depois de comprometer o serviço de cópias de segurança ConnectWise Cloud Backup, o grupo tentou entrar em mais de 2250 ambientes Microsoft 365 de clientes. Aproveitou o acesso que os clientes já tinham dado à aplicação.

Antes, entre 10 e 14 de outubro, o grupo tentou adivinhar palavras-passe de 327 contas, com picos de 2900 tentativas falhadas por minuto, sem conseguir entrar. Noutros ataques, passaram menos de três horas entre a escolha do alvo e o acesso de administrador à cloud.

A CrowdStrike descreveu quatro grupos que deixaram os seus sistemas de agentes expostos na Internet, com casos documentados entre maio e agosto. Um deles comprometeu pelo menos 15 entidades de saúde na Argentina com dois agentes: um "Supervisor", que escolhe a próxima etapa do ataque, e um "Executor", que a cumpre. De pelo menos uma vítima, levou credenciais e registos médicos.

Porque é que a IA acelera tudo isto

Quando sai uma correção, qualquer pessoa pode comparar o código antes e depois e perceber o que foi corrigido. A esta técnica chama-se patch diffing. Antes, transformar essa diferença num ataque exigia dias de trabalho especializado. A Amazon escreveu, a propósito do PHP, que a análise assistida por IA torna mais barato transformar uma correção num ataque. Com isso, mais atacantes conseguem agir "em horas ou até minutos".

A IA também adapta o ataque a cada servidor: segundo a Wiz, os modelos analisam o erro e tentam de novo até acertar. Foi isso que tornou praticável uma falha com mais de uma década.

Depois, os agentes trabalham dia e noite, tentam vários caminhos ao mesmo tempo e não se cansam. A CrowdStrike prevê que, nos próximos 12 meses, atacantes com pouca experiência consigam campanhas que antes só grupos organizados faziam. Já tínhamos falado disto em A inteligência artificial já entra nos ataques às PME.

A IA também serve a defesa: foi com ela que estas falhas foram encontradas. Mas um prazo de 30 dias para atualizar um sistema exposto à Internet já não serve. Nas falhas críticas, a Amazon recomenda contar em horas.

O que isto significa para uma empresa portuguesa

Não é preciso ser um governo para ser alvo. Estes ataques são automáticos: os robôs procuram qualquer servidor com a versão vulnerável, seja de quem for. Uma loja em WordPress com o PHP desatualizado tem dados de clientes e um servidor que pode servir para outros ataques.

Três lições para quase todas as PME:

O fornecedor também conta. Na Railway, na Zeabur e na ConnectWise, foi o fornecedor que falhou, não o cliente. A NIS2 já obriga as empresas abrangidas a avaliar os fornecedores, como explicamos em O meu cliente está na NIS2: o que me vai pedir.
As chaves são o novo alvo. Quem rouba uma chave de API não precisa de invadir nada: usa-a.
Saber o que tem é metade do trabalho. O primeiro conselho do CNCS foi fazer um inventário. Muitas empresas não sabem que versão de PHP usam nem que aplicações têm acesso ao email.

Lista de verificação para esta semana

PHP atualizado. Confirme com o alojamento se o servidor usa o PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou mais recente, e se o PHP-FPM foi reiniciado. O PHP 8.1 ou anterior não tem correção oficial, por isso está na altura de mudar de versão. Inclua sites antigos e subdomínios.
Node.js atualizado. Se o site, a loja ou uma API correm em Node.js num servidor próprio, num contentor ou em CI, passe para a 22.23.4, a 24.22.1 ou a 26.12.1. Na Vercel, quem está no Node.js 20 tem de mudar para o 22 ou o 24 e fazer novo deploy.
Chaves trocadas. Se usa a Railway ou a Zeabur, troque todas as chaves de API, palavras-passe de bases de dados e tokens guardados lá, e veja os registos e as faturas. Em qualquer alojamento, saiba onde estão as chaves e quem lhes tem acesso. Na Zeabur, comece já a migração.
Alojamento e WAF. Pergunte ao fornecedor se ativou regras de firewall para estas falhas e em quanto tempo aplica correções críticas. O WAF ajuda, mas não substitui a atualização. Saiba o que pedir em Alojamento web e domínios.
Certificados. Confirme que o certificado HTTPS é de uma autoridade de confiança e que renova sozinho. Se tem sistemas internos ou integrações que confiam em certificados da eMudhra, atualize-os. Veja também o novo aviso do Chrome para sites sem HTTPS.
Aplicações com acesso às suas contas. No Microsoft 365 ou no Google Workspace, reveja que aplicações externas (cópias de segurança, CRM, faturação) têm acesso e com que permissões. Retire o que já não usa e ative a autenticação em dois passos, a começar pelos administradores.
Cópias e monitorização. Tenha cópias fora do servidor e do fornecedor principal e teste a reposição. Ative alertas para ficheiros novos, contas criadas e picos de tentativas de login, que cheguem a alguém no mesmo dia.
Agentes de IA da própria empresa. Se já usa agentes ou automações (n8n, chatbots, integrações), limite as permissões e as chaves a que têm acesso. Explicamos como em Segurança em agentes de IA.

Se suspeitar de um ataque: a quem ligar

Quem gere o site e o alojamento, primeiro, para isolar o servidor e guardar os registos antes de apagar seja o que for. Os primeiros passos estão em O site foi pirateado: o que fazer nas primeiras horas.
CERT.PT, do Centro Nacional de Cibersegurança: pode reportar o incidente pelo formulário do CNCS ou para cert@cert.pt. As entidades abrangidas pela lei da cibersegurança têm a obrigação de notificar.
CNPD: se houver dados pessoais de clientes envolvidos, o RGPD obriga a notificar a Comissão Nacional de Proteção de Dados até 72 horas depois de ter conhecimento.
Polícia Judiciária, se houver crime, como extorsão ou roubo de dados: unc3t@pj.pt.

Em resumo

Em poucos dias, falhas no PHP e no Node.js, chaves expostas, certificados fracos e ataques com agentes de IA mostraram o mesmo: o intervalo entre a correção e o ataque está a encolher. Muitos alarmes foram preventivos, mas a direção é clara. Atualize o PHP e o Node.js, troque as chaves expostas, reveja as aplicações com acesso às suas contas e tenha cópias que funcionem. E escreva já os contactos de emergência, como defendemos no caso da Câmara de Ovar.

Quer saber como está o seu site?

A nossa auditoria gratuita verifica a segurança, o desempenho e o SEO do seu site e explica o que corrigir. Veja também o que significa a nota de segurança. Para atualizar o PHP ou o Node.js, rever o alojamento ou trocar chaves sem parar o site, escreva para info@marcaweb.pt ou ligue para o +351 920 260 897.

Fontes

Wiz Research: PHP2Shell (21/10/2026)
The Record: declaração da PHP Foundation (21/10/2026)
Amazon Threat Intelligence: exploração do PHP2Shell antes da divulgação (21/10/2026)
Node.js: atualizações de segurança de 21 de outubro e boletim da Vercel
Railway: divulgação de segurança (21/10/2026) e Zeabur: relatório do incidente (19/10/2026)
The Register: chaves da eMudhra (20/10/2026)
Microsoft Security: Storm-0940 e ARTEX e CrowdStrike: campanhas com agentes de IA (21/10/2026)