CISA confirma exploração ativa de CVE 9,8 no Gitea, com mineradores entrando pelo endpoint diffpatch

O que a CISA colocou no KEV

A CISA adicionou a CVE-2026-60004 ao Known Exploited Vulnerabilities Catalog na terça-feira, 25 de agosto, e a semana subsequente trouxe as primeiras confirmações públicas de exploração em ambiente de produção da plataforma de hospedagem de código Git self-hosted Gitea. A falha, com CVSS 9,8, permite que um atacante com permissão de escrita em qualquer repositório envie um patch maliciosamente formatado ao endpoint diffpatch e plante um Git hook executável, que roda comandos de shell arbitrários com o privilégio do processo Gitea.

A brecha foi corrigida pelos mantenedores em 27 de julho, com a release 1.27.1, e o aviso de segurança saiu no dia seguinte. Entre a divulgação e a inclusão no KEV, pesquisadores independentes acompanhavam varreduras automatizadas em honeypots, sem relato público de comprometimento efetivo. O quadro mudou quando um administrador russo publicou no Habr o log de uma instância própria invadida. O relato descreveu payload em duas etapas: um shell-loader universal seguido por dropper com comportamento de minerador de criptomoedas, executado dentro do contêiner Gitea como o usuário git.

Agências federais americanas precisam patchar até sexta-feira, 28 de agosto, prazo vinculante em toda infraestrutura sob o Federal Civilian Executive Branch. Fora do governo dos EUA, a orientação da CISA vale como recomendação sem prazo formal.

Por que a falha atinge quem operava Gitea "seguro"

A prática habitual em DevSecOps é reduzir a superfície de exposição do Gitea colocando a instância atrás de VPN ou de bastion, e tratar o repo self-hosted como confiável. A CVE-2026-60004 quebra essa hipótese em duas frentes.

Primeiro, o vetor exige apenas escrita em algum repositório. Em instâncias com registro aberto por padrão, comportamento que a documentação oficial recomenda para times pequenos, qualquer conta pode criar o próprio repositório e virar atacante autenticado em segundos. O relato do Habr descreveu exatamente essa cadeia: um scanner registrou conta, criou um repo próprio, disparou o exploit, escreveu prova de conceito de volta na branch principal e iniciou o dropper.

Segundo, o Git hook plantado executa dentro do processo Gitea, que na maioria das instalações roda como serviço systemd com acesso a bancos de dados internos, chaves SSH e tokens de CI. A escalada para pipeline de build é imediata, e quem opera Gitea em Kubernetes com credenciais AWS ou GCP montadas via IRSA ou Workload Identity está potencialmente expondo a conta cloud inteira ao mesmo atacante que entrou pelo registro público.

Onde o impacto pesa mais

O Gitea aparece como alternativa ao GitHub Enterprise em três perfis de cliente. O primeiro é o time de infraestrutura que precisa manter código dentro de perímetro por razão regulatória, comum em bancos alemães sob supervisão da BaFin e em consultorias com contratos government-adjacent no Reino Unido. O segundo é a operação indiana em provedoras de outsourcing, que hospedam repos de múltiplos clientes sob a mesma instância. O terceiro é o startup latino-americano que roda tudo em VPS único para conter custo.

Na Alemanha, o Gitea é a plataforma preferida de times que evitam saída de código para servidores fora da União Europeia, e a exposição pela CVE-2026-60004 força uma revisão de risco em contratos que preveem SLA de contenção em 72 horas. Nos hubs de entrega de TCS, Infosys e Wipro em Pune, Bengaluru e Manila, o Gitea é uma das plataformas homologadas para código de clientes com política de air-gap, e um comprometimento nessa base tem efeito de leve para severo conforme a segmentação de tenant.

No Brasil, o mapa é diferente. Nubank, Stone e as áreas de tecnologia dos grandes bancos operam predominantemente em GitHub Enterprise ou GitLab, mas integradores de médio porte e secretarias estaduais de tecnologia ainda mantêm instâncias Gitea. A orientação prática é a mesma: atualizar para 1.27.2 e auditar logs desde 27 de julho.

O que auditar antes de considerar contido

O time de segurança que já aplicou o patch precisa fazer três verificações mínimas para descartar comprometimento pretérito. Primeiro, listar todos os Git hooks criados após 27 de julho em todos os repositórios da instância, com atenção a scripts que abrem soquete de rede ou baixam artefato externo. Segundo, revisar histórico de contas criadas via registro aberto no período e correlacionar com criação imediata de repositórios contendo patch anômalo. Terceiro, checar processos ativos no contêiner Gitea contra assinaturas de cryptominer comuns, começando pelo XMRig.

A documentação da Gitea inclui uma quarta ação que costuma ser esquecida: desabilitar registro aberto se não houver razão explícita para manter. Instâncias com signup público continuam sendo o vetor mais barato de escalada para atacante externo, e a CVE-2026-60004 não é a primeira nem será a última a explorar essa configuração default. Quando o próximo bug crítico do Gitea aparecer, o custo de resposta será proporcional a quantas contas anônimas ficaram no banco esta semana.