Uma falha crítica no Gitea permite que um invasor assuma qualquer conta, inclusive administradores, usando um único cabeçalho HTTP e sem apresentar senha. O problema está nas imagens oficiais do Gitea para Docker até a versão 1.26.2. Pesquisadores já observaram tentativas de exploração, por isso a atualização precisa entrar na fila de emergência.
Pontos-chave
- A falha é a CVE-2026-20896, classificada pela autoridade do registro com pontuação 9,8 e impacto crítico.
- O alvo é a imagem oficial do Gitea para Docker, não toda instalação do programa.
- O erro confia em qualquer origem para enviar o cabeçalho
X-WEBAUTH-USER. - A versão 1.26.3 corrige o problema; o próprio projeto recomenda atualizar diretamente para a 1.26.4.
- Quem expõe o Gitea à internet deve investigar registros antes e depois da atualização.
O que aconteceu
O alerta envolve a consultoria de segurança publicada pelo próprio Gitea em 21 de junho de 2026. A imagem oficial para Docker trazia o parâmetro REVERSE_PROXY_TRUSTED_PROXIES = *. O asterisco fazia o serviço confiar em qualquer origem quando a autenticação por proxy reverso estava habilitada.
Essa configuração existe para permitir que um proxy autenticador informe ao Gitea qual usuário já foi validado. O desenho seguro exige que somente o proxy confiável possa enviar essa identidade. Na imagem afetada, qualquer processo que alcançasse a porta HTTP do contêiner podia tentar fornecer o nome de usuário por conta própria, segundo a descrição técnica do aviso no GitHub.
O resultado é um contorno completo da autenticação. O invasor não precisa roubar uma sessão, descobrir uma senha ou enganar um funcionário. Basta conhecer, adivinhar ou descobrir o nome de uma conta existente. Se o alvo for uma conta administrativa, o acesso pode alcançar repositórios privados, configurações, chaves e integrações.
Quem está vulnerável
A base do NIST lista como afetadas as imagens do Gitea até a versão 1.26.2. A descrição também registra que a condição depende do uso de cabeçalhos de autenticação por proxy reverso. Em outras palavras, não basta encontrar um Gitea antigo: é preciso verificar a forma como a instância foi empacotada e configurada.
Instalações compiladas pelo administrador ou distribuídas como binário, seguindo o arquivo de configuração de exemplo do projeto, usam uma lista restrita que confia apenas na comunicação local. A análise do Gitea diz que esses cenários não reproduzem o defeito da imagem oficial. Isso reduz o alcance, mas não elimina a necessidade de confirmar a configuração real.
O risco cresce quando a porta do contêiner fica acessível diretamente pela rede. Um proxy reverso pode estar na frente e, ainda assim, uma regra de firewall, uma porta publicada pelo Docker ou uma rede interna mal segmentada pode abrir um caminho paralelo. A falha transforma esse caminho esquecido em uma entrada para a aplicação.
Por que o impacto é crítico
A ficha da CVE no NVD registra pontuação 9,8 no sistema CVSS 3.1, com acesso pela rede, baixa complexidade, nenhum privilégio prévio e nenhum clique do usuário. O impacto indicado é alto para confidencialidade, integridade e disponibilidade. A nota não é exagero: uma identidade falsificada pode levar o invasor ao código e às funções administrativas.
Um servidor Gitea costuma concentrar mais do que arquivos de código. Repositórios podem conter chaves de serviços, senhas de implantação, tokens, certificados, scripts de infraestrutura e dados de clientes. Mesmo quando os segredos não estão no histórico, a conta administrativa pode permitir alterações que contaminem a cadeia de desenvolvimento.
O projeto corrigiu o defeito tornando a autenticação por proxy reverso uma opção explícita e administrada, em vez de presumir que qualquer origem é confiável. A descrição da correção está no anúncio oficial das versões 1.26.3 e 1.26.4.
Exploração já começou
O problema deixou de ser uma falha teórica. O BleepingComputer informou em 10 de julho que invasores estavam explorando a falha para se passar por usuários do Gitea, inclusive administradores. A reportagem cita observações de Michael Clark, diretor de pesquisa de ameaças da Sysdig.
Segundo o SecurityWeek, os primeiros sinais de exploração apareceram 13 dias depois da divulgação pública do problema. O padrão descrito foi uma varredura originada de um endereço de saída de rede privada virtual, seguida de tentativas com o cabeçalho usado para informar a identidade do usuário.
Essa velocidade muda a prioridade operacional. Administradores não devem esperar um comunicado do provedor de nuvem nem uma confirmação de comprometimento para agir. A correção é simples; a investigação posterior é que fica mais difícil quando o atacante já apagou rastros ou alterou o código.
O que atualizar agora
- Liste contêineres, imagens e serviços Gitea em execução. Confirme a versão real dentro do contêiner, não apenas a etiqueta usada no arquivo de implantação.
- Substitua imagens até a 1.26.2 por uma versão corrigida. O projeto recomenda a versão 1.26.4, porque ela corrige uma regressão introduzida na 1.26.3 e inclui outra correção de segurança.
- Revise
ENABLE_REVERSE_PROXY_AUTHENTICATION,REVERSE_PROXY_TRUSTED_PROXIESe qualquer regra que aceiteX-WEBAUTH-USER. A lista de origens confiáveis deve conter somente o proxy que autentica usuários. - Bloqueie o acesso direto à porta do Gitea. O tráfego deve passar pelo caminho autenticador previsto, com regras de rede que impeçam atalhos entre contêineres e interfaces públicas.
- Force a troca de senhas e a rotação de tokens de contas administrativas se os registros mostrarem acesso suspeito. Reavalie chaves de implantação e credenciais armazenadas em repositórios.
Como investigar os registros
Comece pela janela entre 21 de junho e a atualização instalada. Procure requisições com X-WEBAUTH-USER, sobretudo quando vierem de endereços que não pertencem ao proxy autenticador. O aviso do Gitea explica que a exploração pode ocorrer sem cookie e sem senha, portanto registros de login tradicionais podem não contar a história completa.
Compare os endereços de origem com os usuários acessados, horários de criação ou alteração de repositórios, mudanças de membros e geração de tokens. Dê atenção a contas que normalmente não usam a interface web ou que acessaram projetos privados fora do padrão.
Depois de atualizar, monitore novas requisições ao cabeçalho e confirme que o serviço rejeita identidades enviadas por origens não autorizadas. Não publique uma prova de conceito contra uma instância exposta: a própria consultoria demonstra que a ação pode assumir uma conta real com uma chamada simples.
O erro que se repete
O caso do Gitea expõe um problema recorrente em ambientes com contêineres: a imagem pronta pode divergir do padrão documentado pelo programa. A equipe pode acreditar que está usando a configuração segura do projeto, enquanto uma camada de empacotamento altera permissões, endereços confiáveis ou portas expostas.
A correção duradoura é tratar imagens como código. Fixe versões, leia as mudanças de segurança antes de atualizar e valide o comportamento da configuração em uma rede isolada. Também vale manter uma lista de cabeçalhos aceitos por cada proxy e um teste automatizado que falhe quando uma porta interna fica acessível de fora.
Para acompanhar outros riscos em serviços de código, veja a análise anterior sobre falha no Gitea e o caso de execução remota no Gogs. Os episódios são diferentes, mas apontam para a mesma regra: ferramentas que guardam código precisam de atualização e isolamento de rede como qualquer sistema de produção.