CVE-2021-22175

Falha de SSRF (CWE-918) na API CI Lint do GitLab, que valida a sintaxe de arquivos .gitlab-ci.yml sem exigir autenticação. Um atacante não autenticado pode usar a diretiva 'include: remote:' para forçar o servidor GitLab a fazer requisições HTTP para endereços arbitrários, incluindo a rede interna, desde que a instância tenha a opção de webhooks para rede interna habilitada. O CVSS moderado (6.8) reflete justamente essa pré-condição de configuração — a maioria das instâncias com configuração padrão não está exposta ao impacto pleno.

O endpoint da API CI Lint (usado para validar sintaxe de arquivos .gitlab-ci.yml antes de rodar um pipeline) aceita a diretiva 'include: remote: ' para buscar trechos de configuração YAML hospedados externamente. Esse endpoint não exige autenticação — funciona mesmo em instâncias com registro de usuários desabilitado, porque foi projetado para permitir validação anônima de sintaxe. O problema é que o valor da URL em 'remote:' é totalmente controlado pelo requisitante e o servidor faz a busca do lado do backend, sem validar se o destino é uma faixa de rede interna ou reservada (127.0.0.1, RFC1918, link-local, etc).

Quando um administrador habilita a opção que permite que webhooks e serviços integrados façam requisições para a rede interna — uma configuração pensada para ambientes onde todos os usuários autenticados são confiáveis —, essa mesma permissão passa a valer para o mecanismo de include remoto usado pela API CI Lint, mesmo sendo ela acessível sem login algum. Isso cria uma inversão de confiança: uma flag pensada para usuários autenticados vira porta de entrada para qualquer requisição HTTP não autenticada.

O relato original no HackerOne (report #1059596) também descreve um segundo cenário, mais brando, presente mesmo sem a flag de rede interna habilitada: a API pode ser abusada como proxy para port-scanning de alvos remotos e para vazar o IP de origem e o user-agent do GitLab quando ele está atrás de um balanceador ou de proteção como CDN/anti-DDoS. O CVE-2021-22175 formalizado pelo GitLab e listado na CISA KEV trata especificamente do cenário de acesso à rede interna via webhooks.

O vetor é uma requisição HTTP simples para o endpoint '/api/v4/ci/lint', sem necessidade de conta ou sessão, enviando um corpo JSON com um conteúdo de .gitlab-ci.yml que declare 'include: remote:' apontando para o alvo desejado. Não há necessidade de acesso à rede interna por parte do atacante — a requisição sai do próprio servidor GitLab, que já está posicionado dentro do perímetro. O pré-requisito real que limita o impacto é a configuração administrativa: a instância precisa ter habilitada a opção que permite que webhooks/serviços façam chamadas para endereços internos (localhost e faixas privadas). Sem essa flag, a exploração ainda é possível como técnica de reconhecimento (varredura de portas internas via timing de resposta, vazamento de IP de origem), mas sem o alcance à rede interna que caracteriza o SSRF pleno.

A complexidade de ataque classificada como alta no vetor CVSS (AC:H) reflete essa dependência de configuração não padrão — não é uma falha de exploração trivial em qualquer instalação, mas sim em instalações que optaram por confiar em requisições internas partindo de webhooks. Uma vez satisfeita essa condição, o atacante consegue fazer o GitLab atuar como proxy cego para a rede interna: sondar serviços em portas específicas, confirmar existência de hosts, e potencialmente extrair respostas de serviços internos sem autenticação HTTP através da mensagem de erro de parsing YAML retornada pela API (que reflete parte do conteúdo buscado).

A vulnerabilidade está no catálogo KEV da CISA, confirmando exploração ativa observada, embora a entrada não especifique se está associada a campanhas de ransomware ('Known To Be Used in Ransomware Campaigns: Unknown'). A data de inclusão no catálogo é recente em relação à publicação original da CVE (2021), o que indica retomada de interesse ou nova onda de exploração contra instâncias GitLab desatualizadas expostas à internet.

A correção definitiva é atualizar para uma versão do GitLab que trate a validação de destino em 'include: remote:' da API CI Lint. Como paliativo imediato, desabilite a configuração administrativa que permite requisições da rede interna para webhooks e serviços integrados (encontrada nas configurações de rede do painel administrativo do GitLab) — isso remove o pré-requisito que habilita o alcance à rede interna, embora não elimine o abuso do endpoint como proxy de reconhecimento externo descrito no relato original.

Como controle compensatório adicional, restrinja o acesso ao endpoint '/api/v4/ci/lint' via proxy reverso ou WAF para IPs/redes confiáveis, já que ele não deveria estar livremente acessível de forma anônima na maioria dos cenários de uso real. Monitorar e filtrar egressos de rede do servidor GitLap para faixas internas (egress filtering) também reduz o impacto mesmo que a flag administrativa permaneça habilitada por necessidade operacional.

Não funciona como mitigação: apenas desabilitar o registro de novos usuários — a descrição oficial já deixa claro que o endpoint é explorável mesmo com o registro desligado, pois nunca exigiu autenticação.

Procure em logs de acesso à API por requisições POST para '/api/v4/ci/lint' (ou 'ci/lint' com 'include_merged_yaml') sem cabeçalho de autenticação/sessão válida, cujo corpo contenha a diretiva 'include: remote:' apontando para endereços internos ou reservados (127.0.0.1, faixas RFC1918, 169.254.169.254, nomes de host internos). Respostas de erro do tipo 'Included file ... does not have valid YAML syntax' são um indício de que o servidor efetivamente tentou buscar a URL informada.

Não há um sinal de rede único e confiável quando o atacante usa alvos externos apenas para reconhecimento (scan de portas via timing), porque a diferença entre uso legítimo e abusivo da API CI Lint é sutil — a chave é olhar volume de chamadas anônimas ao endpoint e a presença de URLs para faixas internas no campo de conteúdo YAML.