Alerta de CISA: GitLab expõe dezenas de milhares de instâncias e exige adesivo imediato por CVE-2021-39935 SSRF

A Agência de Segurança de Infra-estruturas e Cibersegurança dos EUA (CISA) deu um ultimato: os organismos federais devem corrigir as suas instâncias de GitLab por uma vulnerabilidade que foi corrigida há anos, mas que agora está a ser explorada ativamente em ambientes reais. Trata-se de uma falha do tipo SSRF (Server-Side Request Forgery) conhecida como CVE-2021-39935, que GitLab resolveu originalmente em dezembro de 2021.

Nessa correção, GitLab explicou que o problema afetava a API da CI Lint, a ferramenta que permite validar e simular pipelines de CI/CD, e que em certas configurações—quando o registro de usuários estava limitado—usuários externos sem privilégios podiam executar pedidos desde o servidor. O aviso técnico original está disponível na nota de segurança do GitLab de dezembro de 2021: GitLab Security Release (06‐12‐2021), e os detalhes do CVE podem ser consultados na base de dados da NVD: CVE-2021-39935 (NVD).

O que voltou a ligar os alarmes é que a CISA incluiu esta vulnerabilidade no seu catálogo de vulnerabilidades conhecidas e exploradas no mundo real, e impôs um prazo às agências civis federais para aplicarem adesivos: três semanas desde a notificação, com prazo de 24 de Fevereiro de 2026, em conformidade com a Directiva Operacional vinculativa BOD 22-01. A mensagem de CISA é clara: estas falhas continuam sendo uma porta de entrada frequente para atores maliciosos e requerem atenção imediata. A inclusão no catálogo de CISA pode ser consultada aqui: CISA — Alerta sobre CVE‐2021‐39935, e a lista pública de vulnerabilidades exploradas está em: Known Exploited Vulnerabilities Catalog. A directiva que obriga a tomar medidas também pode ser revista na página da CISA relativa ao BOD 22-01: Binding Operational Directive 22-01.

Para além do quadro federal, a CISA encorajou empresas e organizações privadas a priorizar a remediação, porque a exposição é real e quantificáveis. O motor de busca de dispositivos conectados Shodan mostra dezenas de milhares de instâncias com a impressão de GitLab acessível publicamente: mais de 49 mil resultados e quase 27 mil respondendo por defeito no porto 443, segundo buscas públicas de Shodan. Pesquisa GitLab em Shodan e Resultados em Porto 443.

É fácil ver por que a prioridade é alta: GitLab é uma plataforma muito estendida no mundo do desenvolvimento. A empresa declara dezenas de milhões de usuários e uma presença importante entre grandes empresas, pelo que uma vulnerabilidade na sua superfície de gestão e CI/CD tem potencial de impacto em massa. Mais informações sobre a presença de GitLab no setor estão em seu site corporativo: About GitLab.

O que os responsáveis técnicos e de segurança devem fazer? O primeiro passo é óbvio e urgente: atualizar as versões corrigidas do GitLab, seguindo as indicações do próprio fabricante. Se a actualização não for imediata, Aplicar mitigações oficiais, restringir o acesso às APIs expostas e minimizar a exposição de instâncias públicas São medidas temporárias necessárias. Também é conveniente auditar os registos, rotar credenciais que podem ser comprometidas e rever regras de firewall e controles de acesso para impedir que serviços internos recebam pedidos forçados a partir de componentes expostos.

Na prática, isso pode implicar desativar o acesso público à API da CI Lint se não for estritamente necessário, implantar listas brancas de IP, forçar autenticação reforçada em painéis administrativos e monitorar padrões incomuns em tráfego e execuções de pipelines. Se uma equipe detectar atividade suspeita e não puder mitigar a falha, a opção responsável é deixar de usar temporariamente a instância afetada até aplicar a correção ou mover-se para uma alternativa segura.

O aparecimento de exploits eficazes contra um defeito corrigido anos atrás lembra uma lição clássica em cibersegurança: as correções só são efetivas se forem aplicadas. Uma vulnerabilidade adesivo permanece perigosa enquanto houver instalações sem atualização. A pressão da CISA sobre entidades federais busca reduzir esse gap, mas a responsabilidade recai também em administradores de sistemas e fornecedores externos para manter atualizados seus ambientes de desenvolvimento e entrega contínua.

Finalmente, convém colocar este episódio num contexto mais amplo: esta mesma semana CISA tem estado a emitir várias advertências e ordenando adesivos por outras falhas críticas exploradas no terreno. Para equipamentos de segurança isso significa priorizar a gestão de patches, identificar ativos expostos e estabelecer processos que acortem o tempo entre a publicação de um adesivo e a sua implantação eficaz.

Se você quer ler as fontes oficiais citadas neste artigo, aqui estão os links principais: a nota de GitLab sobre a correção ( GitLab — Security Release), o registo do CVE no NVD ( NVD — CVE‐2021‐39935), o alerta de CISA que incorpora a vulnerabilidade ao catálogo ( CISA — alerta (03-02-2026)), a lista pública de vulnerabilidades exploradas ( KEV Catalog) e uma vista da exposição em Shodan ( Shodan — GitLab).

A recomendação final é simples: não confiar em que um adesivo antigo já não seja relevante. Se sua organização corre GitLab, verifique versões e aplica as correções quanto antes. A indústria e as agências governamentais estão fazendo isso; agora toca ao resto.