Falha 9.8 no Gitea Docker vira alvo ativo: um único cabeçalho dá acesso admin a repositórios
Sysdig detectou os primeiros scans em produção da CVE-2026-20896 nas imagens Docker do Gitea. São cerca de 6.200 instâncias expostas à internet, muitas com segredos de CI/CD dentro dos repos.
A Sysdig confirmou, em relatório republicado nesta semana pelo The Hacker News, que a CVE-2026-20896 no Gitea Docker deixou de ser hipótese e passou a ser alvo ativo na internet. O primeiro tentativa de exploração em produção veio 13 dias após a publicação da falha, saindo de um nó de saída da ProtonVPN em 159.26.98.241, com padrão de scan típico de campanha ampla: varredura por serviços expostos, tentativa de bypass, coleta de resposta.
O defeito é grosseiro pelo que permite. A pontuação CVSS chega a 9.8 porque a imagem Docker oficial subia com um template app.ini que fixava REVERSE_PROXY_TRUSTED_PROXIES = *. Combinado com a configuração de autenticação por cabeçalho, o servidor passava a aceitar o header X-WEBAUTH-USER vindo de qualquer IP e a tratá-lo como identidade confirmada. Em outras palavras, um cliente não autenticado da internet aberta pode se apresentar como qualquer usuário do Gitea, inclusive administrador, sem tocar em senha, chave SSH ou token.
O que está exposto
A Sysdig contabiliza cerca de 6.200 instâncias Gitea expostas à internet no momento em que a exploração começou a aparecer. Nem toda essa base roda a imagem Docker vulnerável, mas o subconjunto atingido inclui exatamente o perfil que mais interessa a operadores criminosos: equipes de desenvolvimento internas de médio porte, servidores de código de startups, laboratórios corporativos que preferiram autohospedar em vez de usar GitHub ou GitLab, e provedores gerenciados que empacotaram o Gitea em containers para revenda.
O conteúdo desses repositórios costuma valer mais que o próprio código. Chaves privadas de CI/CD, tokens de nuvem, credenciais de banco em arquivos de configuração, definições de infra como código com endpoints internos, notebooks de dados e histórico de commits com segredos revertidos e nunca purgados aparecem na maioria dos ambientes autohospedados que não passaram por auditoria formal. Um acesso admin ao Gitea dá visão de todos os repos privados da organização sem gerar log de autenticação normal, porque o servidor genuinamente acredita que o pedido é legítimo.
Como chegou ao estado atual
A vulnerabilidade foi divulgada pelos mantenedores do Gitea junto com o release 1.26.3, orientando administradores a atualizar imediatamente ou remover a linha REVERSE_PROXY_TRUSTED_PROXIES = * do arquivo app.ini. Segundo a Sysdig, essa janela de 13 dias entre publicação e primeira tentativa observada segue a média que a empresa vem medindo em campanhas de N-day: bots públicos consomem o feed de CVEs, geram assinaturas de scan e disparam varreduras em massa, muitas vezes antes que times internos tenham concluído o inventário de instâncias afetadas.
O fato de a exploração ter partido de um nó ProtonVPN não indica autoria específica. É prática comum em campanhas de reconhecimento oportunista, e a Sysdig registrou que, até o momento do relatório, não havia relatos confirmados de pós-exploração bem-sucedida ou vazamento diretamente atribuído à falha. Isso não é reconforto: o intervalo entre scan e uso costuma ser medido em horas quando o exploit funciona como o deste caso, sem necessidade de payload sofisticado.
O que fazer agora
Para operadores de Gitea Docker, o playbook é curto e urgente. Atualizar para 1.26.3, remover ou restringir REVERSE_PROXY_TRUSTED_PROXIES para as faixas realmente confiáveis, revisar logs de acesso das duas últimas semanas em busca de requests com X-WEBAUTH-USER inesperado e forçar rotação de qualquer credencial que apareça em texto claro dentro de repos privados. Times que expõem o Gitea via ingress público sem WAF na frente devem tratar a instância como comprometida até prova em contrário, principalmente se a versão está atrás da 1.26.3 há mais que alguns dias.
O caso mostra um padrão que se repete em produtos DevOps: uma configuração padrão pensada para facilitar deploy interno vira porta aberta quando a mesma imagem sobe em produção com exposição pública. O REVERSE_PROXY_TRUSTED_PROXIES = * faz sentido em um ambiente onde só um reverse proxy conhecido fala com o container. Deixar esse valor como default de uma imagem oficial, distribuída para cenários que ninguém consegue prever, é o tipo de escolha de engenharia que costuma acabar em CVE crítica. A resposta rápida do time do Gitea corrige o defeito, mas a lição, para quem gerencia frotas de containers, é que o security review precisa entrar antes do pull, não depois do primeiro alerta.