{"id":2476,"date":"2026-08-26T09:01:35","date_gmt":"2026-08-26T12:01:35","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/26\/cve-2026-60004-falha-critica-no-gitea-em-exploracao-ativa\/"},"modified":"2026-08-26T09:01:35","modified_gmt":"2026-08-26T12:01:35","slug":"cve-2026-60004-falha-critica-no-gitea-em-exploracao-ativa","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/26\/cve-2026-60004-falha-critica-no-gitea-em-exploracao-ativa\/","title":{"rendered":"CVE-2026-60004: Falha Cr\u00edtica no Gitea em Explora\u00e7\u00e3o Ativa"},"content":{"rendered":"
\n \u26a0\ufe0f<\/span><\/p>\n
\n

ALERTA CISA KEV \u2014 Explora\u00e7\u00e3o Ativa Confirmada<\/p>\n

Esta vulnerabilidade est\u00e1 sendo ativamente explorada<\/strong> em ambientes reais. Aplique o patch ou mitiga\u00e7\u00e3o IMEDIATAMENTE<\/strong>.<\/p>\n<\/p><\/div>\n<\/div>\n

O cen\u00e1rio de amea\u00e7a para ambientes de desenvolvimento e integra\u00e7\u00e3o cont\u00ednua acaba de escalar para um n\u00edvel de urg\u00eancia m\u00e1xima: a CVE-2026-60004<\/strong>, uma vulnerabilidade de inje\u00e7\u00e3o de c\u00f3digo no Gitea<\/strong>, entrou oficialmente para o cat\u00e1logo KEV (Known Exploited Vulnerabilities)<\/strong> da CISA, confirmando CVE-2026-60004 explora\u00e7\u00e3o ativa vulnerabilidade<\/strong> em ambientes reais. A falha permite que um atacante com acesso de escrita a um reposit\u00f3rio envie um patch malicioso \u00e0 API diffpatch<\/code> do Gitea, plantando um Git hook<\/em> execut\u00e1vel que roda comandos shell como a conta de servi\u00e7o da aplica\u00e7\u00e3o. Na pr\u00e1tica, isso significa execu\u00e7\u00e3o remota de c\u00f3digo (RCE) no servidor que hospeda o Gitea, afetando diretamente organiza\u00e7\u00f5es que mant\u00eam inst\u00e2ncias autogerenciadas \u2014 desde pequenas startups at\u00e9 grandes empresas com reposit\u00f3rios internos de c\u00f3digo, credenciais de infraestrutura e segredos de produ\u00e7\u00e3o.<\/p>\n

A inclus\u00e3o no cat\u00e1logo KEV da CISA n\u00e3o \u00e9 um evento burocr\u00e1tico: ela \u00e9 emitida apenas quando h\u00e1 evid\u00eancia concreta de explora\u00e7\u00e3o ativa em campo. A recomenda\u00e7\u00e3o federal para ag\u00eancias governamentais dos EUA \u00e9 de remedia\u00e7\u00e3o em at\u00e9 72 horas<\/strong> \u2014 o prazo mais curto estipulado pela CISA e indicativo de risco imediato. Empresas privadas, que muitas vezes n\u00e3o possuem os mesmos mecanismos de verifica\u00e7\u00e3o de conformidade, frequentemente levam semanas ou meses para aplicar patches, tornando-se alvos permanentes para varreduras automatizadas e ransomware. O vetor aqui \u00e9 especialmente perigoso porque n\u00e3o exige privil\u00e9gios administrativos pr\u00e9vios no Gitea; o simples fato de ser um usu\u00e1rio com permiss\u00e3o de escrita em um reposit\u00f3rio j\u00e1 habilita a explora\u00e7\u00e3o. Isso significa que o atacante pode ser um insider mal-intencionado, um colaborador comprometido ou at\u00e9 mesmo um bot que obteve credenciais via phishing.<\/p>\n

Neste alerta t\u00e9cnico de seguran\u00e7a da informa\u00e7\u00e3o, vamos destrinchar o funcionamento t\u00e9cnico da falha, a mec\u00e2nica do ataque pelo endpoint diffpatch<\/code>, os produtos e vers\u00f5es afetados, o impacto para ambientes corporativos sob LGPD, GDPR, PCI-DSS e HIPAA<\/strong>, e um roteiro passo a passo de mitiga\u00e7\u00e3o imediata. Acompanhe tamb\u00e9m o contexto hist\u00f3rico comparativo com outras falhas de inje\u00e7\u00e3o de c\u00f3digo em plataformas de reposit\u00f3rio e o que a JRT Technology Solutions<\/strong> recomenda para detec\u00e7\u00e3o e resposta cont\u00ednua.<\/p>\n

Para os times de AppSec, DevSecOps e infraestrutura, o recado \u00e9 um s\u00f3: se voc\u00ea opera um Gitea autogerenciado, pare o que est\u00e1 fazendo e aplique o patch ou as mitiga\u00e7\u00f5es agora. A janela de exposi\u00e7\u00e3o j\u00e1 est\u00e1 aberta e atacantes est\u00e3o efetivamente comprometendo servidores neste exato momento.<\/p>\n

O que \u00e9 a CVE-2026-60004 e sua explora\u00e7\u00e3o ativa<\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n
Campo<\/th>\nDetalhe<\/th>\n<\/tr>\n<\/thead>\n
CVE ID<\/td>\nCVE-2026-60004<\/strong><\/td>\n<\/tr>\n
CVSS Score<\/td>\n8.8 \u2014 HIGH<\/td>\n<\/tr>\n
Vetor de Ataque<\/td>\nNetwork (acesso de escrita em reposit\u00f3rio)<\/td>\n<\/tr>\n
Produtos Afetados<\/td>\nGitea<\/strong> \u2014 vers\u00f5es 1.25.0 e anteriores<\/strong><\/td>\n<\/tr>\n
Tipo de Vulnerabilidade<\/td>\nCWE-94 \u2014 Code Injection \/ Improper Control of Generation of Code<\/td>\n<\/tr>\n
Data de Publica\u00e7\u00e3o<\/td>\n26\/08\/2026<\/td>\n<\/tr>\n
Patch Dispon\u00edvel<\/td>\nSim \u2014 Gitea 1.25.1 (security release)<\/td>\n<\/tr>\n
Explora\u00e7\u00e3o Ativa<\/td>\n\u26a0\ufe0f SIM \u2014 CISA KEV confirmada<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A CVE-2026-60004<\/strong> descreve uma falha de inje\u00e7\u00e3o de c\u00f3digo no componente respons\u00e1vel pelo processamento de patches via API no Gitea<\/strong>, uma plataforma open source de hospedagem de reposit\u00f3rios Git, frequentemente usada como alternativa autogerenciada ao GitHub ou GitLab. O endpoint vulner\u00e1vel, conhecido como diffpatch<\/code>, \u00e9 projetado para aceitar dados de patch no formato diff\/patch<\/em> padr\u00e3o e aplic\u00e1-los a um reposit\u00f3rio. O problema reside na valida\u00e7\u00e3o insuficiente do conte\u00fado desse patch: um atacante com permiss\u00e3o de escrita no reposit\u00f3rio consegue forjar um patch que, durante o processamento, modifica arquivos sens\u00edveis dentro do diret\u00f3rio Git \u2014 especificamente, a pasta .git\/hooks\/<\/code>, onde ficam os scripts de hook executados automaticamente em eventos do reposit\u00f3rio (push, merge, pre-receive etc.).<\/p>\n

Quando o hook \u00e9 plantado com conte\u00fado malicioso, a pr\u00f3xima opera\u00e7\u00e3o Git leg\u00edtima que acionar esse hook far\u00e1 com que o servidor execute o script como a conta de servi\u00e7o do Gitea. Dependendo da implementa\u00e7\u00e3o, essa conta costuma ser um usu\u00e1rio dedicado como git<\/code> ou gitea<\/code>, com privil\u00e9gios limitados ao sistema operacional \u2014 por\u00e9m, em muitas instala\u00e7\u00f5es, ela tem acesso de leitura a todos os diret\u00f3rios de reposit\u00f3rios, a chaves SSH de deploy, a credentials armazenadas em vari\u00e1veis de ambiente e, em alguns casos, a sockets de comunica\u00e7\u00e3o interna.<\/p>\n

A gravidade desta falha n\u00e3o est\u00e1 apenas na execu\u00e7\u00e3o remota de c\u00f3digo, mas na facilidade de explora\u00e7\u00e3o<\/strong>. O atacante n\u00e3o precisa explorar uma falha de autentica\u00e7\u00e3o complexa, realizar for\u00e7a bruta ou obter acesso direto ao servidor. Basta ter uma conta com permiss\u00e3o de escrita em um \u00fanico reposit\u00f3rio. Em organiza\u00e7\u00f5es que permitem contribui\u00e7\u00f5es externas, pull requests de forks p\u00fablicos ou integra\u00e7\u00f5es de CI\/CD com credenciais compartilhadas, o raio de alcance cresce exponencialmente. Um colaborador comprometido, um token de API vazado ou uma conta de servi\u00e7o com permiss\u00f5es excessivas s\u00e3o vetores de entrada imediatos.<\/p>\n

An\u00e1lise T\u00e9cnica Detalhada<\/h3>\n

Para compreender o alerta CVE-2026-60004 explora\u00e7\u00e3o ativa vulnerabilidade<\/strong> em profundidade, \u00e9 preciso examinar o fluxo de processamento do patch no Gitea. Internamente, o Gitea implementa endpoints REST para opera\u00e7\u00f5es de reposit\u00f3rio, incluindo a aplica\u00e7\u00e3o de patches via POST \/repos\/{owner}\/{repo}\/diffpatch<\/code>. Quando um patch \u00e9 enviado, o servidor o repassa a um processo de aplica\u00e7\u00e3o que utiliza fun\u00e7\u00f5es nativas de Git em modo pipe<\/em>. O Gitea valida superficialmente o cabe\u00e7alho e o formato do patch, mas n\u00e3o restringe adequadamente quais caminhos dentro do reposit\u00f3rio o patch pode tocar \u2014 uma defici\u00eancia de path traversal<\/em> que permite que o conte\u00fado do diff alcance o diret\u00f3rio .git\/hooks\/<\/code>.<\/p>\n

O ataque conceitual funciona em quatro est\u00e1gios. Primeiro, o atacante obt\u00e9m uma sess\u00e3o de escrita em um reposit\u00f3rio \u2014 por credenciais leg\u00edtimas, token exposto ou conta comprometida. Segundo, ele constr\u00f3i um patch malicioso que, em vez de alterar c\u00f3digo-fonte normal, adiciona um arquivo no caminho .git\/hooks\/post-receive<\/code> ou .git\/hooks\/pre-push<\/code>. Terceiro, ele envia esse patch ao endpoint diffpatch<\/code>, que o aplica como se fosse uma contribui\u00e7\u00e3o comum. Quarto, o atacante dispara o hook realizando um push trivial ou aguardando que qualquer outro evento do reposit\u00f3rio o execute. A partir desse ponto, o script roda com os privil\u00e9gios da conta de servi\u00e7o do Gitea, permitindo comandos shell arbitr\u00e1rios.<\/p>\n

Uma caracter\u00edstica t\u00e9cnica relevante \u00e9 que o hook malicioso n\u00e3o precisa estar presente no reposit\u00f3rio Git versionado. O diret\u00f3rio .git\/hooks<\/code> faz parte do metadado local do reposit\u00f3rio no servidor, n\u00e3o do conte\u00fado versionado. Isso significa que a inspe\u00e7\u00e3o por revis\u00e3o de c\u00f3digo comum ou an\u00e1lise est\u00e1tica do c\u00f3digo-fonte n\u00e3o detecta a presen\u00e7a do hook \u2014 apenas o pr\u00f3prio servidor, na pasta de trabalho do reposit\u00f3rio, consegue v\u00ea-lo. Essa opacidade torna a detec\u00e7\u00e3o passiva extremamente dif\u00edcil, e a persist\u00eancia \u00e9 garantida enquanto o diret\u00f3rio de trabalho n\u00e3o for limpo.<\/p>\n

O CWE associado \u00e9 o CWE-94, que abrange a gera\u00e7\u00e3o impr\u00f3pria de c\u00f3digo a partir de entrada n\u00e3o confi\u00e1vel. No contexto do Gitea, a entrada n\u00e3o confi\u00e1vel \u00e9 o patch enviado pelo usu\u00e1rio. O patch, que deveria ser tratado como dado, \u00e9 parcialmente interpretado como instru\u00e7\u00f5es de manipula\u00e7\u00e3o de arquivo, permitindo a escrita fora dos limites permitidos. A severidade CVSS 8.8 \u00e9 alta porque o vetor \u00e9 de rede, exige privil\u00e9gios baixos (escrita em reposit\u00f3rio) e n\u00e3o requer intera\u00e7\u00e3o do usu\u00e1rio \u2014 apenas eventos autom\u00e1ticos de Git.<\/p>\n

Do ponto de vista de superf\u00edcie de ataque, o endpoint diffpatch<\/code> \u00e9 frequentemente habilitado por padr\u00e3o em inst\u00e2ncias Gitea. Administradores que n\u00e3o revisam as configura\u00e7\u00f5es de API de reposit\u00f3rio podem n\u00e3o estar cientes de que usu\u00e1rios comuns de reposit\u00f3rio t\u00eam acesso a essa funcionalidade. Al\u00e9m disso, integra\u00e7\u00f5es de CI\/CD, bots de dependabot, webhooks de terceiros e mirrors autom\u00e1ticos frequentemente possuem tokens de escrita, alargando ainda mais a superf\u00edcie explor\u00e1vel.<\/p>\n

Produtos e Vers\u00f5es Afetados<\/h3>\n

O impacto da falha se concentra primordialmente no Gitea<\/strong> autogerenciado. A vers\u00e3o corrigida \u00e9 a 1.25.1<\/strong>, lan\u00e7ada como security release em resposta \u00e0 explora\u00e7\u00e3o ativa. Vers\u00f5es anteriores, incluindo toda a linha 1.24, 1.23, 1.22 e anteriores, est\u00e3o comprovadamente vulner\u00e1veis. Administradores que executam o Gitea em cont\u00eainer Docker, Kubernetes, binary standalone ou compila\u00e7\u00e3o manual precisam verificar imediatamente a vers\u00e3o em execu\u00e7\u00e3o.<\/p>\n