CISA alerta para exploração ativa de um RCE no GitLab e de um DoS nas firewalls Cisco

Duas vulnerabilidades muito diferentes entraram a 29 de outubro de 2026 no catálogo Known Exploited Vulnerabilities (KEV) da CISA: uma falha de execução remota de código de severidade máxima no GitLab e um erro que deixa fora de serviço os equipamentos da linha Cisco Secure Firewall. Ambas estão a ser exploradas em ataques reais, e as agências civis federais dos EUA têm até 1 de novembro de 2026 para aplicar as correções. É um prazo invulgarmente curto e mostra a gravidade que a agência atribui ao risco.

O que foi adicionado

CVE-2026-97229 — GitLab CE/EE (CVSS 10.0). Um integer overflow na forma como o GitLab valida expressões regulares dentro da configuração de CI/CD. Como a verificação é insuficiente, um atacante não autenticado pode inserir uma regex especialmente construída na definição de um pipeline e executar código arbitrário no próprio servidor GitLab. Sem conta, sem token e sem acesso prévio.

CVE-2026-76418 — Cisco Secure Firewall ASA e FTD (CVSS 8.6). Um valor de retorno não verificado conduz a uma desreferência de ponteiro NULL. Um atacante remoto e não autenticado pode desencadeá-la para forçar o equipamento a reiniciar inesperadamente, deixando a firewall offline. A Cisco afirma ter tomado conhecimento da exploração no início de outubro, mas não revelou quem está por trás dos ataques, quantas organizações foram atingidas nem o que os atacantes fizeram depois de obterem acesso.

O incidente do GitLab no Alpine Linux

A entrada do GitLab está ligada a um incidente no Alpine Linux, a distribuição focada em segurança que serve de base a uma enorme fatia das imagens de contentores. A 20 e 21 de outubro, um ator desconhecido visou a instância GitLab do projeto com configurações de CI manipuladas. Os payloads fizeram cair os processos worker do GitLab oito vezes; em quatro dessas tentativas a cadeia de exploração ultrapassou a falha e só falhou no passo seguinte. O atacante descarregou também a imagem de contentor GitLab do Alpine, presumivelmente para a estudar. As novas tentativas de 25 e 26 de outubro foram bloqueadas.

Os responsáveis pelo projeto foram francos: o ataque esteve perto de resultar. Não encontraram provas de sucesso, mas também não o puderam excluir, pelo que trataram o servidor como comprometido e reconstruíram-no de raiz. As verificações indicam que o repositório de fontes aports, os pacotes publicados e as versões de 21 de outubro não foram adulterados.

Porque é que isto importa

Um servidor GitLab alojado internamente é uma joia da coroa. Guarda código-fonte, segredos de CI, credenciais de deployment e, muitas vezes, as chaves da produção. Um RCE sem autenticação com CVSS 10 nesse sistema é o pior cenário possível para uma equipa de software, e o incidente do Alpine mostra que os atacantes já estão a apontar-lhe código de exploração funcional. O próximo alvo poderá não ter a mesma combinação de registos, vigilância e sorte.

A falha da Cisco é «apenas» uma negação de serviço, mas o equipamento em causa é uma firewall de perímetro. Deixá-la offline interrompe o acesso VPN e a inspeção de tráfego, e reinícios repetidos podem servir de cobertura ou de instrumento de pressão. Os equipamentos de borda são há vários anos a porta de entrada preferida de grupos alinhados com Estados, pelo que qualquer falha em ASA ou FTD sob exploração ativa merece atenção imediata.

As entradas do KEV só são vinculativas para as agências federais norte-americanas, mas o catálogo é um dos sinais públicos mais fiáveis do que os atacantes estão realmente a usar neste momento. As organizações privadas devem tratar uma adição ao KEV como uma ordem de «corrigir esta semana», não como um item de backlog.

O que fazer

• Administradores de GitLab: atualizem já todas as instâncias self-managed CE e EE para a versão corrigida. Se não puderem aplicar a correção de imediato, restrinjam o acesso de rede à instância e revejam as definições de pipeline recentes à procura de padrões regex inesperados ou malformados.
• Assumam comprometimento se estiveram expostos. Procurem nos registos dos workers do GitLab quedas repetidas em outubro, auditem configurações de CI/CD novas ou alteradas e rodem os tokens de runner, as chaves de deploy e quaisquer segredos guardados em variáveis de CI se algo parecer suspeito.
• Operadores de Cisco ASA e FTD: apliquem a versão de software corrigida, vigiem reinícios inexplicados nos registos do equipamento e garantam que as interfaces de gestão não ficam acessíveis a partir da internet.
• Todos: mantenham um inventário do software exposto à internet e das respetivas versões, e acompanhem as atualizações do KEV para que cada nova entrada seja associada aos vossos ativos em horas, não em semanas.

Falhas como estas são exatamente o que o scanning de vulnerabilidades contínuo foi concebido para apanhar: uma versão desatualizada do GitLab ou um ASA sem correção surge como uma constatação priorizada e associada à versão antes de um atacante a encontrar por vós. A nossa equipa executa estas verificações de forma permanente sobre o perímetro externo dos clientes, de modo que uma adição ao KEV se transforma num ticket com responsável, não numa surpresa.