A vulnerabilidade CVE-2026-60004 no Gitea permite que qualquer usuário com acesso de escrita a um repositório execute comandos arbitrários no servidor como a conta de serviço do Gitea. Classificada com CVSS 9.8 (crítica) e registrada como CWE-94 (injeção de código), a falha afeta todas as versões de 1.17 até antes da 1.27.1 e foi corrigida no patch lançado em 27 de julho de 2026. A exploração usa o endpoint diffpatch da API para instalar um Git hook malicioso que executa código no próximo acesso ao índice do repositório, sem exigir conexão reversa para o atacante.
Esta não é a primeira vez que o Gitea aparece em alertas de segurança: o projeto já havia sido citado por expor containers privados sem autenticação. A nova falha é mais grave porque depende apenas de um usuário com permissão de escrita — algo que, com o registro aberto por padrão, qualquer visitante pode obter em segundos.
Como a falha funciona
O mecanismo de exploração é sofisticado, mas não exige ferramentas exóticas. O endpoint diffpatch aplica o patch controlado pelo atacante dentro de um clone temporário bare compartilhado, invocando git apply com as opções --index, --recount, --cached e --binary. Quando o servidor executa Git 2.32 ou superior, o Gitea adiciona automaticamente o argumento -3, que ativa o fallback de merge de três vias em caso de conflito.
O truque está em enviar o mesmo patch duas vezes. A segunda submissão cria uma colisão do tipo add/add, que faz o Git entrar no caminho de merge de três vias. Esse caminho ignora a flag --cached e escreve o arquivo no diretório de trabalho em vez de apenas no índice. Como o clone é bare, a raiz do working tree é o próprio $GIT_DIR. Um patch que cria um arquivo executável chamado hooks/post-index-change passa a ser um Git hook ativo no repositório.
Na próxima operação que envolve o índice, o Git executa o hook automaticamente, rodando comandos arbitrários como a conta de serviço do Gitea. O proof-of-concept publicado pelo pesquisador Shai Rod demonstra que a saída do comando pode ser armazenada em objetos Git, resgatada por um branch criado pelo próprio hook e recuperada via smart HTTP autenticado — tudo sem necessidade de conexão de saída do servidor comprometido.
Versões afetadas e impacto
A falha afeta o Gitea nas versões 1.17 até anteriores a 1.27.1 e foi corrigida na versão 1.27.1, lançada em 27 de julho de 2026. Qualquer instância auto-hospedada que não tenha sido atualizada está potencialmente vulnerável, incluindo ambientes corporativos de desenvolvimento, pipelines de CI/CD e mirrors internos de código.
Com o registro de contas aberto por padrão, um visitante sem autenticação pode se cadastrar, criar um repositório e obter o acesso de escrita necessário para acionar o endpoint vulnerável. Mesmo sem registro aberto, qualquer colaborador, contratado ou conta comprometida com permissão de push consegue explorar a falha sem privilégios administrativos adicionais.
| Aspecto | Detalhe |
|---|---|
| CVE | CVE-2026-60004 |
| CVSS v3.1 | 9.8 (Crítica) |
| CWE | CWE-94 — Injeção de código |
| Vetor CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Versões afetadas | >= 1.17, < 1.27.1 |
| Correção | 1.27.1 (27/07/2026) |
| Endpoint vulnerável | diffpatch |
| Pré-requisito | Acesso de escrita ao repositório |
O impacto de uma exploração bem-sucedida pode expor segredos do arquivo app.ini, credenciais de banco de dados, tokens de OAuth e integrações, variáveis de ambiente do processo, repositórios montados e qualquer outro serviço acessível a partir do host comprometido. Assim como em outra falha crítica recente de RCE sem autenticação, a facilidade de exploração amplia significativamente o risco para organizações que administram suas próprias instâncias.
Passos para se proteger
A correção definitiva é atualizar o Gitea para a versão 1.27.1 ou superior o mais rápido possível. Até que a atualização seja concluída, medidas de mitigação reduzem a superfície de ataque e dificultam a exploração por contas não autorizadas.
- Atualize o Gitea para a versão 1.27.1 imediatamente. Instâncias no Gitea Cloud recebem a atualização automaticamente na janela de manutenção.
- Desative o registro aberto de novas contas nas configurações administrativas, impedindo que visitantes criem contas e repositórios sem aprovação.
- Revise permissões de escrita existentes e restrinja o acesso de push apenas a usuários confiáveis e autenticados com MFA ativo.
- Monitore a atividade do endpoint
diffpatche a execução de Git hooks em busca de padrões anômalos, como criação de branches inesperados. - Verifique logs do serviço em busca de indícios de exploração prévia, incluindo arquivos em
hooks/não autorizados e branches com conteúdo suspeito.
Se houver indícios de comprometimento, trate a instância como comprometida: faça rotação de todas as credenciais armazenadas, segredos de integração, chaves SSH e tokens de acesso, e realize uma investigação forense completa antes de restabelecer o serviço em produção.