RCE no Gitea (CVE-2026-60004)

Técnicas e Métodos de Ataque14h atrás
O endpoint diffpatch no Gitea é afetado por uma vulnerabilidade que permite execução remota de código (RCE). O endpoint aceita um patch do usuário e o aplica ao repositório. Para isso, o Gitea executa o comando git apply --index --recount --cached --binary -3 dentro de um clone temporário bare do repositório alvo. A vulnerabilidade afeta o Gitea 1.17–1.27.0 e foi corrigida na versão 1.27.1; sua pontuação CVSS é 9.8. Para entender de onde vem a RCE, vamos decompor três fatos independentes.
Fato 1: a flag -3 habilita um fallback de merge de três vias. Em operação normal, git apply falha com um erro em um conflito. Com a flag -3 (no Git ≥ 2.32), o Git tenta resolver o conflito por meio de um merge de três vias. Se o merge for bem-sucedido, o Git pode gravar o arquivo em disco. Sem -3, esse caminho de código não existe.
Fato 2: uma colisão add/add força esse caminho. Se o mesmo patch criado for enviado duas vezes, na segunda vez o Git vê que o arquivo já existe no índice e está sendo adicionado novamente — isso é uma colisão add/add. No modo normal, a operação apply falharia, mas com -3, um merge de três vias ocorre e o arquivo é gravado em disco. A operação pretendia atualizar o índice, mas na prática o arquivo acaba no disco.
Fato 3: em um clone bare, a raiz do repositório é $GIT_DIR. Em um repositório vazio, não há diretório de trabalho — a raiz do repositório também é o $GIT_DIR, onde hooks/ está localizado. Portanto, um arquivo gravado em hooks/post-index-change cai diretamente no diretório ativo de hooks do Git. Em um clone não bare, hooks/ está dentro de .git/, e um arquivo gravado no mesmo caminho relativo seria colocado na árvore de trabalho, não em .git/hooks/.
Juntando os três fatos:
  1. Crie uma conta com um repositório e obtenha acesso de escrita.
  2. O primeiro patch criado grava o payload em hooks/post-index-change — mas apenas no índice, não no disco.
  3. O segundo patch dispara uma colisão add/add → o Git muda para um merge de três vias → faz checkout do arquivo de payload para o disco em hooks/post-index-change no diretório ativo de hooks.
  4. O Git grava o índice e dispara o hook post-index-change
  5. O hook é executado como a conta de serviço do Gitea — isso é RCE.
A rota diffpatch requer acesso de escrita ao repositório. No entanto, o Gitea vem com registro aberto habilitado por padrão, e em instâncias onde isso não foi desabilitado, um atacante externo pode completar toda a cadeia sem uma conta existente — registrando-se e criando um repositório.
A classe do problema é mais ampla que o Gitea. A questão subjacente não é específica do Gitea: um frontend SCM auto-hospedado pode ser vulnerável se aplicar patches controlados pelo atacante em um repositório temporário bare usando git apply -3, permitindo que um fallback de três vias grave arquivos em $GIT_DIR. O Forgejo, um fork do Gitea, é afetado pelo mesmo padrão subjacente.
A vulnerabilidade foi ativamente explorada como parte da campanha Red Heron. A Acronis relatou que o grupo weaponizou a CVE-2026-60004 contra instâncias Gitea expostas à internet e usou o acesso resultante para roubo de código-fonte, coleta de credenciais, persistência e movimento lateral. A campanha também envolveu o implante JITTERLY, que continha o rootkit SIXZUT LD_PRELOAD.
Advisory: https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m PoC: https://github.com/HORKimhab/CVE-2026-60004 Campaign and implant analysis: https://www.acronis.com/en/tru/posts/red-heron-exploits-gitea-n-day-flaw-in-multinational-campaign-exposing-new-linux-rootkit
Vulnerabilidades
10
CVE-2026-60004
Pesquisadores
Nightrang3R
Fornecedor
Gitea
Forgejo
Produto
Forgejo
Git
Gitea
Jitterly Implant
Sixzut Ld_Preload Rootkit