seguranca · auto-hospedagem · Docker
Bypass de autenticacao do Gitea Docker (CVE-2026-20896): voce esta exposto e como corrigir
Se voce auto-hospeda o Gitea a partir de sua imagem Docker oficial, um bug critico exige sua atencao agora. CVE-2026-20896 e um bypass de autenticacao classificado como CVSS 9.8 e, de acordo com relatos da BleepingComputer, The Hacker News e SecurityWeek, ja esta sob exploracao ativa na natureza. A boa noticia e que saber se voce esta afetado e facil de verificar, e a correcao e uma atualizacao rapida mais uma configuracao.
O que e realmente a falha
O problema e um valor padrao inseguro no container, nao na logica central do Gitea. A imagem Docker oficial do Gitea e entregue com REVERSE_PROXY_TRUSTED_PROXIES=*, o que significa que o Gitea confia no cabecalho de autenticacao do proxy reverso X-WEBAUTH-USER de qualquer endereco IP de origem. Quando a autenticacao por proxy reverso esta ativada, esse cabecalho deveria vir apenas de um proxy confiavel que ja autenticou o usuario. Com um curinga, um cliente nao autenticado na internet pode simplesmente enviar o cabecalho ele mesmo e se tornar quem ele afirma ser. Esse e todo o bypass.
Quem e realmente afetado
Nem toda instalacao do Gitea esta em risco. Com base nos avisos publicados, voce esta exposto se tudo isto for verdadeiro: voce executa a imagem Docker oficial do Gitea na versao 1.26.2 ou anterior, voce tem os cabecalhos de autenticacao por proxy reverso ativados, e a instancia esta acessivel pela internet publica. Instalacoes que nao usam autenticacao por cabecalho de proxy reverso, ou que so sao acessiveis em uma rede privada, nao sao explaraveis por esse caminho especifico, embora atualizar continue sendo a atitude certa.
Por que isso importa
Um servidor Git e um alvo de alto valor. Os pesquisadores descrevem atacantes que, uma vez passada a autenticacao, conseguem ler repositorios privados, exfiltrar segredos e codigo-fonte, criar ou modificar contas de usuario e potencialmente injetar alteracoes maliciosas em pipelines CI/CD que sao executados a partir desses repositorios. A Sysdig relatou ter detectado o primeiro impacto na natureza poucos dias apos a tecnica se tornar conhecida, vindo de scanners automatizados que usam nos de saida VPN. Em outras palavras, as instancias expostas estao sendo encontradas e atingidas automaticamente.
Como verificar e corrigir
- Atualize primeiro. O Gitea lancou 1.26.3 e 1.26.4, que corrigem o problema. Baixe a imagem corrigida e reimplante.
- Corrija a configuracao de proxies confiaveis. Nao deixe
REVERSE_PROXY_TRUSTED_PROXIEScomo*. Defina-o para o IP ou sub-rede real do seu proxy reverso, para que o Gitea so confie no cabecalho de autenticacao dessa fonte. - Reduza a exposicao. Se um servidor Git nao precisa estar na internet publica, coloque-o atras de uma VPN ou firewall. Menos coisas expostas significa menos coisas escaneadas.
- Verifique se houve abuso. Apos corrigir, revise sua lista de usuarios do Gitea e seus registros em busca de contas ou acessos inesperados, ja que a exploracao pode ser anterior a sua correcao.
A licao mais ampla
Esta e uma falha classica de "valor padrao inseguro": o software estava bem, mas o container foi entregue com uma configuracao permissiva que se torna perigosa no momento em que o servico fica exposto a internet. A auto-hospedagem vale a pena, mas vem com a responsabilidade de revisar os valores padrao das imagens que voce executa, especialmente qualquer coisa que aceite cabecalhos de autenticacao de um proxy. Uma configuracao de confianca com curinga e exatamente o tipo de valor padrao que vale a pena auditar antes de expor um servico.
FAQ
O que e a CVE-2026-20896? Um bypass de autenticacao critico (CVSS 9.8) na imagem Docker oficial do Gitea na versao 1.26.2 e anterior, causado por confiar no cabecalho X-WEBAUTH-USER de qualquer IP. Esta sob exploracao ativa.
Estou afetado se nao uso autenticacao por proxy reverso? Por esse caminho especifico, nao. O bypass depende de os cabecalhos de autenticacao por proxy reverso estarem ativados. Atualizar ainda e recomendado.
Como corrijo? Atualize para o Gitea 1.26.3 ou 1.26.4 e defina REVERSE_PROXY_TRUSTED_PROXIES para o IP real do seu proxy em vez de um curinga.
Eu ja poderia ter sido comprometido? Possivelmente, se voce estava exposto antes de corrigir. Revise as contas de usuario e os registros de acesso em busca de qualquer coisa inesperada.