Gitea sob ataque: falha em imagem Docker permite virar admin com um único header HTTP

A empresa de segurança em cloud Sysdig anunciou nesta terça-feira que detectou a primeira tentativa de exploração real do CVE-2026-20896, falha de bypass de autenticação com CVSS 9.8 nas imagens Docker do Gitea. A tentativa saiu de um endereço da ProtonVPN (159.26.98.241) e ocorreu 13 dias depois de o projeto publicar a versão 1.26.3, que corrigiu o problema em 20 de junho. Existem cerca de 6.200 instâncias do Gitea voltadas para a internet, número que combina servidores autohospedados de times de engenharia e implementações internas de empresas que preferem código-fonte fora do GitHub por razões de compliance.

A causa raiz cabe em duas linhas do arquivo app.ini que a imagem Docker do Gitea distribuía por padrão. A configuração REVERSE_PROXY_TRUSTED_PROXIES vinha marcada com o caractere curinga asterisco, o que faz o serviço confiar no header HTTP X-WEBAUTH-USER vindo de qualquer endereço IP. Um cliente sem credenciais, capaz de alcançar a porta pública do container, envia esse header com um nome de usuário administrativo e recebe sessão de admin. Ali Mustafa, pesquisador que assina como rz1027, descobriu e reportou a falha; a correção removeu o curinga da configuração padrão e transformou a autenticação por proxy reverso em opt-in explícito.

O que Sysdig viu

Michael Clark, diretor sênior de pesquisa de ameaças da Sysdig, disse em nota que a atividade observada até agora está no estágio de investigação inicial pelo atacante e não avançou para movimento lateral ou instalação de payload. "Achamos que pegamos essa cedo, antes que ela tivesse a chance de evoluir além dessa fase", declarou Clark. O ponto é relevante porque o Gitea, ao contrário de gestores de código gerenciados, costuma sentar dentro de segmentos de rede com secrets, chaves SSH e pipelines de CI que sabem falar com produção.

A janela de silêncio entre o patch de 20 de junho e a primeira exploração em 3 de julho é típica do padrão que a Sysdig e outros pesquisadores começaram a mapear em 2026: atacantes esperam a poeira baixar, extraem detalhes do commit que corrigiu o bug e lançam varredura em escala assim que a maioria dos operadores presume que a onda passou. Cyberdaily estimou que menos de metade dos containers do Gitea expostos foi atualizada para 1.26.3 até o começo desta semana.

Onde o problema bate: Estados Unidos, Alemanha e China

A base instalada do Gitea concentra-se em três geografias distintas. Nos Estados Unidos, times DevOps de startups e áreas de plataforma que fugiram do GitHub por questões de custo ou de latência costumam rodar Gitea em nuvem privada. Na Alemanha e no restante da União Europeia, o Gitea virou opção preferida para empresas que precisam manter código-fonte dentro de fronteiras geográficas sob GDPR, incluindo divisões de engenharia de fabricantes automotivos e integradores públicos. Na China, onde restrições de acesso ao GitHub e políticas de dados locais empurraram a comunidade para forks abertos, o Gitea ganhou tração em bancos regionais, universidades e órgãos estatais; o Gitee, fork chinês do projeto, herda a mesma base de código e pode compartilhar o problema em versões desatualizadas.

Nos EUA, o risco imediato é roubo de secrets e sequestro de pipelines de CI, o que costuma virar acesso a produção em poucas horas. Na Europa, a materialização do risco tende a ser detecção por autoridade de proteção de dados: um invasor entrando como admin em um Git corporativo é evento que dispara notificação obrigatória sob GDPR em 72 horas. Na Ásia, onde muitas instalações ainda rodam versões anteriores a 1.24 sem processos regulares de patch, o vetor pode ficar aberto por semanas antes de qualquer investigação.

O que fazer agora

Administradores devem, primeiro, confirmar a versão em execução. A partir de 1.26.3, o comportamento default mudou: REVERSE_PROXY_TRUSTED_PROXIES deixou de vir com asterisco e virou uma lista explícita. Quem operou o Gitea atrás de um reverse proxy legítimo precisa colocar de volta os IPs de confiança de forma manual. Quem descobrir que o serviço nunca precisou de autenticação por proxy reverso pode simplesmente desligar a feature.

A Sysdig recomenda também revisar logs em busca de requisições com header X-WEBAUTH-USER vindas de fora da rede interna e conferir quais chaves de deploy e tokens de CI foram acessados nos últimos 20 dias. Em ambientes onde o Gitea armazena secrets de pipeline, a rotação preventiva de credenciais custa menos do que a triagem de um incidente confirmado. O 1.26.3 já está disponível há mais de duas semanas. A conta que sobra é decidir se o próximo relatório será sobre patch aplicado ou sobre resposta a incidente.