Seguir Uma vulnerabilidade crítica de execução remota de código no Gitea passou da divulgação para a exploração ativa em menos de um mês após a disponibilização de um patch. Registrada como CVE-2026-60004 e classificada com 9,8 na escala CVSS, a falha permite que um atacante com acesso normal de escrita ao repositório instale um gancho Git executável e execute comandos de shell arbitrários com os privilégios da conta de serviço do Gitea.
Em 25 de agosto de 2026, a Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) adicionou a vulnerabilidade explorada do Gitea ao seu catálogo de Vulnerabilidades Conhecidas Exploradas (KEV), confirmando que os ataques estão ocorrendo na natureza. As agências civis federais foram instruídas a remediar as instalações afetadas até 28 de agosto de 2026.
O problema torna-se particularmente perigoso porque o Gitea permite o registro aberto por padrão. Embora a exploração tecnicamente requeira uma conta autenticada com permissões de escrita no repositório, um atacante externo pode ser capaz de criar uma conta, criar um repositório e obter esses privilégios sem possuir quaisquer credenciais previamente roubadas.
Um ataque relatado publicamente contra um servidor vulnerável resultou na implantação de um dropper exibindo comportamento de mineração de criptomoeda. O incidente reforça por que a RCE crítica do Gitea explorada ativamente na natureza deve ser tratada como uma prioridade urgente de remediação para infraestrutura de desenvolvimento auto-hospedada voltada para a internet.
Análise do CVE-2026-60004
A vulnerabilidade é classificada como CWE-94, Controle Impróprio de Geração de Código, e reside na funcionalidade diffpatch do Gitea. O endpoint da API afetado aplica patches fornecidos pelo usuário dentro de um repositório Git temporário. Sob condições vulneráveis, um atacante pode manipular esse processo para que o conteúdo controlado pelo repositório se torne um gancho Git executável em vez de um arquivo do repositório comum.
Os detalhes importantes para o CVE-2026-60004 se concentram em como o Gitea cria o repositório temporário usado para processar patches. Versões vulneráveis usavam um clone Git bare, onde o diretório do repositório em si atuava como diretório de dados internos do Git. Combinado com o comportamento de processamento de patches do Git, o conteúdo do repositório especialmente construído poderia, portanto, alcançar o diretório hooks e se tornar executável.
Um atacante com acesso de gravação pode enviar conteúdo de patch malicioso para a API diffpatch. Ao desencadear uma condição de patch conflitante, o processamento de três vias do Git pode fazer com que um arquivo executável controlado pelo atacante seja materializado como um gancho de pós-mudança do índice. Subsequentemente, o Git executa esse gancho durante as operações do repositório, resultando na execução de comando como a conta do sistema operacional que executa o Gitea.
O CVE-2026-60004 afeta as versões do Gitea 1.17 e posteriores, antes da versão 1.27.1. O Gitea 1.27.1, lançado em 27 de julho de 2026, corrige o problema alterando o clone temporário afetado de um repositório bare para um repositório não-bare, impedindo que caminhos controlados pelo atacante sejam interpretados como ganchos Git executáveis da mesma maneira.
A exploração bem-sucedida requer acesso de gravação ao repositório. No entanto, as configurações de instalação padrão do Gitea enfraquecem significativamente esse pré-requisito: o registro geralmente está habilitado, os usuários não precisam necessariamente de aprovação de administrador ou verificação de e-mail, e novos usuários registrados podem criar repositórios. Um atacante que mire uma instalação voltada para a internet sem alterações pode, portanto, satisfazer as permissões exigidas simplesmente criando uma nova conta.
Condições adicionais de exploração identificadas na pesquisa técnica incluem uma versão do Git no lado do servidor que suporta o comportamento relevante de fallback de três vias, acesso ao endpoint diffpatch, e um sistema de arquivos temporário onde o serviço do Gitea pode gravar e executar arquivos. Esses requisitos significam que nem toda instalação vulnerável será necessariamente explorável através da mesma cadeia, mas configurações padrão podem fornecer um caminho prático.
Uma vez que comandos arbitrários são executados sob a conta de serviço do Gitea, o impacto se estende bem além de um único repositório. Dependendo de como o ambiente está configurado, um atacante pode ganhar acesso a repositórios privados, credenciais de banco de dados, segredos OAuth, configuração de aplicativos, variáveis de ambiente, credenciais de CI/CD, registros de pacotes ou serviços internos acessíveis a partir do host do Gitea.
Para organizações que usam Gitea como parte do fluxo de trabalho de desenvolvimento e implantação de software, isso também cria um potencial risco de cadeia de suprimentos. A violação de uma plataforma de gerenciamento de código-fonte pode expor código proprietário e segredos de implantação e pode fornecer oportunidades para alterar repositórios ou usar credenciais roubadas para realizar movimentação lateral em infraestrutura de CI/CD e produção.
O pesquisador de segurança Shai Rod, também conhecido como NightRang3r, descobriu e reportou a vulnerabilidade. O Gitea lançou a versão 1.27.1 em 27 de julho, seguida pelo aviso de segurança formal em 28 de julho. O problema inicialmente não tinha relatos confirmados de exploração, mas isso mudou quando a CISA o adicionou ao catálogo KEV em 25 de agosto.
Uma PoC pública do CVE-2026-60004 está disponível desde a divulgação da vulnerabilidade, reduzindo significativamente o esforço necessário para entender e reproduzir a técnica de ataque subjacente. Ferramentas de segurança pública também adicionaram modelos de detecção para instâncias vulneráveis, aumentando a probabilidade de que atacantes possam identificar servidores expostos em larga escala.
O Hacker News também documentou um incidente no mundo real envolvendo um servidor Gitea voltado para a internet com registro aberto habilitado. Segundo o administrador, o atacante alcançou o serviço vulnerável por meio de HTTPS, criou as condições necessárias para exploração e executou um dropper que consumiu recursos substanciais de CPU.
O dropper limpou certas variáveis de ambiente relacionadas a bibliotecas, procurou por processos consumindo recursos significativos de CPU, tentou encerrar processos concorrentes, baixou uma carga útil compatível com a arquitetura do host, executou-a, e então removeu o arquivo baixado. O administrador não recuperou evidências suficientes para identificar um minerador de criptomoedas específico, carteira, pool de mineração, ou ator de ameaça, então a carga útil deve ser atualmente descrita como semelhante a mineradora, em vez de definitivamente atribuída a uma família de cryptojacking conhecida.
Ainda não está claro se este ataque específico levou a CISA a adicionar a vulnerabilidade ao KEV ou se a agência observou campanhas de exploração separadas. Nem a CISA nem os dois relatórios citados atribuíram publicamente a atividade mais ampla a um ator de ameaça conhecido.
Nenhum conjunto autoritativo de IOCs de campanha ampla da CVE-2026-60004 foi publicado. Portanto, os defensores devem se basear em evidências comportamentais como criação de contas suspeitas, chamadas incomuns à API diffpatch, ganchos Git inesperados, processos lançados pelo serviço Gitea, e atividade anômala de CPU ou rede de saída.
Mitigação do CVE-2026-60004
Organizações executando Gitea auto-hospedado devem imediatamente atualizar para a versão 1.27.1 ou posterior. Ambientes Gitea Cloud foram programados para receber a atualização automaticamente, enquanto os administradores de instalações autogerenciadas são responsáveis por aplicar a versão corrigida por conta própria.
Como a exploração já foi confirmada na natureza, o patch não deve ser adiado até a próxima janela de manutenção de rotina. A inclusão da CISA no KEV fornece fortes evidências de que a vulnerabilidade apresenta um risco operacional imediato, com agências civis federais dos EUA obrigadas a remediá-la até 28 de agosto de 2026.
Organizações incapazes de aplicar o patch de imediato devem desativar o registro público onde não for necessário. Configurar o registro para o modo controlado por administrador impede que um usuário não autenticado da internet simplesmente crie uma conta e repositório para obter o acesso de gravação necessário para a exploração. Essa medida reduz a exposição, mas não corrige a vulnerabilidade, pois usuários existentes com permissões de gravação no repositório ainda podem acessar a funcionalidade vulnerável.
Os administradores devem adicionalmente restringir a criação de repositórios e permissões de gravação, reduzir o acesso externo ao Gitea quando possível e evitar expor infraestrutura de desenvolvimento diretamente à internet, a menos que haja uma clara necessidade de negócios.
A detecção do CVE-2026-60004 deve começar identificando todas as instalações do Gitea, verificando suas versões exatas e determinando se o registro público estava habilitado enquanto o servidor estava executando uma versão afetada. Instâncias voltadas para a internet que permitiram que visitantes anônimos registrassem contas merecem a mais alta prioridade de investigação.
Para Detectar tentativas de exploração do CVE-2026-60004 e atividades pós-comprometimento, defensores devem revisar a telemetria do Gitea, API, sistema operacional e rede em busca de:
- – Solicitações repetidas ou inesperadas para /api/v1/repos/{owner}/{repo}/diffpatch
- – Contas recém-criadas seguidas rapidamente pela criação de repositórios e operações de patch
- – Shells ou processos desconhecidos iniciados pela conta de serviço do Gitea
- – Utilização sustentada de CPU incomum em hosts do Gitea
- – Downloads ou execuções inesperadas de diretórios temporários
- – Novas conexões de saída originadas do Gitea ou seus processos filhos
- – Modificações não autorizadas nos repositórios
- – Acesso inesperado à configuração do aplicativo, credenciais ou segredos
A presença desses comportamentos não prova independentemente a exploração, mas combinações como registro de nova conta seguido pela criação de repositório, solicitações diffpatch, e novos processos filhos devem ser investigadas urgentemente.
Os administradores também devem revisar contas criadas enquanto a versão vulnerável estava exposta. Usuários desconhecidos, repositórios criados logo após o registro e contas que realizaram operações de API imediatamente podem ajudar a identificar tentativas de exploração que ocorreram antes de o servidor ser corrigido.
O processo de mitigação do CVE-2026-60004 deve ir além da instalação da versão 1.27.1 se uma possível comprometimento for suspeitada. Como a exploração bem-sucedida fornece execução de código com os privilégios do usuário do sistema operacional do Gitea, as equipes de segurança devem tratar o host afetado como potencialmente comprometido e investigar segredos acessíveis e sistemas conectados.
Os respondedores de incidentes devem rodar credenciais de banco de dados, tokens OAuth e API, segredos de CI/CD, chaves SSH, credenciais de implantação e outros materiais sensíveis acessíveis ao Gitea onde há evidências que sugerem que ocorreu execução arbitrária de código. Repositórios privados também devem ser revisados em busca de alterações não autorizadas, e sistemas conectados de build ou implantação devem ser examinados para movimentação lateral.
O CVE-2026-60004 demonstra como uma vulnerabilidade na infraestrutura de desenvolvimento pode rapidamente evoluir de um bug de software para um caminho de comprometimento ativo. Com as informações de exploração pública disponíveis e a confirmação de exploração em andamento, as organizações que executam instâncias Gitea auto-hospedadas vulneráveis devem priorizar tanto o patch quanto a busca retrospectiva de ameaças.
FAQ
O que é o CVE-2026-60004 e como ele funciona?
O CVE-2026-60004 é uma vulnerabilidade crítica de injeção de código na API diffpatch do Gitea. Um atacante com acesso de escrita ao repositório pode enviar conteúdo de patch malicioso que resulta na instalação e execução de um gancho Git executável, permitindo a execução de comandos de shell arbitrários como o usuário de sistema operacional do Gitea. O registro aberto por padrão pode permitir que um atacante externo obtenha as permissões necessárias simplesmente criando uma conta.
Quando o CVE-2026-60004 foi descoberto pela primeira vez?
A data exata da descoberta privada não foi divulgada publicamente. O Gitea credita ao pesquisador de segurança Shai Rod, também conhecido como NightRang3r, o relato do problema. A versão 1.27.1 contendo a correção foi lançada em 27 de julho de 2026 e o aviso de segurança foi publicado em 28 de julho. A CISA confirmou exploração ativa ao adicionar a falha ao seu catálogo KEV em 25 de agosto.
Qual é o impacto do CVE-2026-60004 nos sistemas?
A exploração bem-sucedida permite que comandos arbitrários sejam executados com os privilégios da conta de serviço do Gitea. Isso pode expor repositórios de código-fonte, segredos de aplicativos, credenciais de banco de dados, material OAuth, credenciais de CI/CD e outros recursos acessíveis a partir do servidor comprometido. Os atacantes também podem implantar malware ou usar o host Gitea como um ponto de partida para intrusão adicional.
O CVE-2026-60004 ainda pode me afetar em 2026?
Sim. Qualquer instalação Gitea auto-hospedada executando versões 1.17 até 1.27.0 permanece vulnerável. O risco agora é particularmente urgente porque a CISA confirmou a exploração ativa, e pelo menos uma intrusão descrita publicamente parece ter usado a falha para implantar uma carga útil semelhante a um minerador.
Como posso me proteger contra o CVE-2026-60004?
Atualize o Gitea para a versão 1.27.1 ou mais recente imediatamente. Desative o registro aberto se não for necessário, restrinja a criação de repositórios e o acesso de gravação, e revise a atividade histórica da API para solicitações diffpatch suspeitas. Se a exploração for suspeitada, investigue o host em busca de ganchos Git maliciosos e processos inesperados e rode segredos acessíveis à conta de serviço do Gitea.
