Falha sem correção no tratamento de links simbólicos permite sobrescrever arquivos fora do repositório e pode levar à execução local de código em servidores Gogs acessíveis pela internet.
| Componente | API de atualização de arquivos PutContents do Gogs, serviço Git auto-hospedado escrito em Go, com falha no tratamento de links simbólicos dentro de repositórios. |
| Vetor | Abuso de repositórios Git com links simbólicos e modificação de conteúdo via API fora do fluxo normal do protocolo Git, em instâncias Gogs expostas à internet. |
| Impacto | Sobrescrita de arquivos em caminhos arbitrários do servidor, contorno da correção de CVE-2024-55947, possível execução local de código e obtenção de acesso SSH ao servidor. |
| Prioridade | Restringir exposição pública do Gogs, desabilitar registro aberto, procurar repositórios com nomes aleatórios de 8 caracteres e monitorar sinais de payload baseado em Supershell. |
| Versões | O contexto informa que CVE-2025-8110 ainda não tinha correção disponível; a correção anterior de dezembro de 2024 para CVE-2024-55947 pode ser contornada. |
| IoCs | Campanha associada a repositórios com proprietário e nome aleatórios de 8 caracteres, criados por volta de 10 de julho de 2025, e conexão reversa para 119.45.176[.]196. |
Uma vulnerabilidade de alta severidade no Gogs, rastreada como CVE-2025-8110 e avaliada com CVSS 8.7, está sendo explorada antes da disponibilidade de correção. A falha ocorre na API de atualização de arquivos do serviço Git auto-hospedado e envolve tratamento inadequado de links simbólicos. Na prática, o problema permite que uma operação de escrita em um repositório siga um link simbólico e atinja um caminho fora do próprio repositório, quebrando a fronteira esperada entre conteúdo versionado e arquivos locais do servidor.
A falha é descrita como um contorno para CVE-2024-55947, vulnerabilidade de execução remota de código corrigida pelos mantenedores em dezembro de 2024. A proteção anterior não considerou suficientemente que repositórios Git podem conter links simbólicos apontando para arquivos ou diretórios externos. Como a API do Gogs também permite modificação de arquivos por fora do protocolo Git tradicional, a combinação desses comportamentos cria uma rota para sobrescrita arbitrária em disco, incluindo arquivos sensíveis de configuração do próprio repositório.
A exploração foi identificada em atividade real após a investigação de uma infecção por malware em uma carga de trabalho de cliente. O levantamento citado no contexto aponta cerca de 1.400 instâncias Gogs expostas à internet, das quais mais de 700 apresentavam sinais compatíveis com comprometimento. O principal indicador operacional observado foi a presença de repositórios com proprietário e nome aleatórios de 8 caracteres, todos criados aproximadamente em 10 de julho de 2025. Esse padrão sugere uso de automação comum ou infraestrutura compartilhada entre operadores da campanha.
O ponto central do problema está na diferença entre a semântica do Git e a expectativa de segurança da API de arquivos. Repositórios Git podem armazenar links simbólicos como objetos versionados. Quando uma aplicação permite escrita posterior sobre um caminho que é, na realidade, um link simbólico, o sistema de arquivos pode resolver esse link e aplicar a alteração no destino externo. Em um serviço Git exposto, isso transforma uma operação que deveria ficar confinada ao repositório em uma escrita fora do diretório esperado.
No caso descrito, o abuso da API PutContents permite escrever dados por meio de um link simbólico e fazer o servidor seguir esse ponteiro. O contexto informa que a cadeia de exploração pode chegar à sobrescrita de .git/config, especificamente de parâmetros relacionados a sshCommand, com efeito de execução de comandos arbitrários. A descrição defensiva relevante é que o invasor não depende apenas de uma falha de autenticação isolada; ele explora uma combinação de repositório manipulável, link simbólico e comportamento permissivo da API para alcançar arquivos internos que influenciam a execução local.
A campanha observada também implantou um payload avaliado como baseado em Supershell, estrutura de comando e controle de código aberto frequentemente associada a uso por grupos chineses. O payload foi usado para estabelecer uma sessão reversa SSH para infraestrutura controlada pelo operador, com o endereço 119.45.176[.]196 aparecendo no contexto como destino defangado. O texto recebido não sustenta afirmar exfiltração de dados do Gogs, movimentação lateral ou roubo de código-fonte como efeito confirmado da campanha; o impacto comprovado deve ser mantido em sobrescrita de arquivos, execução local de código, acesso SSH e presença de malware no servidor afetado.
A operação aparenta ter sido conduzida de forma rápida e pouco cuidadosa. Os repositórios criados durante a exploração permaneceram visíveis na carga de trabalho analisada, quando poderiam ter sido apagados ou marcados como privados. Esse comportamento reduz a sofisticação operacional percebida, mas não reduz o risco técnico: uma instância Gogs comprometida fica em uma posição sensível porque normalmente hospeda código, integrações, chaves de implantação, automações e histórico de alterações que podem ter valor para ataques posteriores.
A superfície imediata são instâncias Gogs acessíveis pela internet, especialmente aquelas com registro aberto habilitado ou controles fracos sobre criação e modificação de repositórios. O contexto não informa uma lista de versões vulneráveis nem um ramo específico afetado; portanto, a avaliação defensiva deve partir da presença do Gogs exposto e da ausência de correção para CVE-2025-8110. Ambientes que aplicaram apenas a correção de dezembro de 2024 para CVE-2024-55947 não devem assumir proteção completa, já que a nova falha é descrita como um contorno da mitigação anterior.
Servidores Gogs costumam estar ligados a fluxos de desenvolvimento, automação de entrega e chaves de acesso a outros ambientes. Mesmo quando o comprometimento inicial se limita ao host do serviço, a criticidade aumenta se o servidor também armazena credenciais de implantação, webhooks, chaves SSH, tokens de integração ou repositórios usados por pipelines. O contexto também menciona risco relacionado a Personal Access Tokens do GitHub em outro eixo da análise: tokens com permissão de leitura podem revelar nomes de segredos em arquivos YAML de workflows, e tokens com escrita podem permitir criação de workflows maliciosos. Essa parte não é o mesmo vetor do Gogs, mas reforça que serviços de código e automação devem ser tratados como ativos de alta prioridade.
- Instâncias Gogs publicadas diretamente na internet, dentro do conjunto estimado de aproximadamente 1.400 serviços expostos.
- Servidores com repositórios de proprietário e nome aleatórios de 8 caracteres, padrão observado em mais de 700 instâncias com sinais de comprometimento.
- Ambientes que dependem somente da correção de
CVE-2024-55947e ainda não possuem mitigação específica paraCVE-2025-8110. - Repositórios e automações que mantêm chaves SSH, tokens, webhooks ou segredos de implantação próximos ao servidor Gogs.
A primeira linha de caça deve verificar artefatos criados dentro do próprio Gogs. O indicador mais forte descrito é a existência de repositórios com proprietário e nome aleatórios de 8 caracteres, criados por volta de 10 de julho de 2025. Esse padrão deve ser comparado com histórico administrativo, registros de criação de conta e trilhas de auditoria disponíveis no serviço. Como os operadores deixaram repositórios criados durante a exploração, a ausência de remoção pode facilitar a identificação de instâncias já atingidas.
No host, a investigação deve procurar alterações inesperadas em arquivos de configuração Git, especialmente referências a .git/config e mudanças no campo sshCommand. Também é importante revisar processos filhos disparados pelo serviço Gogs, conexões SSH reversas, binários ou scripts recém-criados no período da exploração e qualquer comunicação de saída para infraestrutura incomum. O endereço 119.45.176[.]196 pode ser usado como exemplo defangado de destino citado no contexto, mas a defesa não deve depender de um único indicador, pois operadores podem trocar infraestrutura com facilidade.
Em ambientes com GitHub Actions e tokens pessoais, o hunting deve incluir revisão de workflows recém-criados, nomes de segredos referenciados em YAML e eventos de API associados a tokens comprometidos. O contexto descreve que atores com tokens GitHub podem procurar nomes de segredos no código de workflows e, quando há permissão de escrita, criar fluxos maliciosos para obter segredos de provedores de nuvem. Esse ponto deve ser tratado como superfície correlata de identidade e CI/CD, não como prova automática de que toda instância Gogs comprometida teve movimentação para nuvem.
- Repositórios com proprietário e nome em formato aleatório de 8 caracteres, especialmente com criação em torno de 10 de julho de 2025.
- Alterações inesperadas em
.git/config, com atenção a mudanças no parâmetrosshCommand. - Conexões de saída compatíveis com sessão reversa SSH, incluindo tráfego para
119.45.176[.]196quando presente nos registros. - Processos filhos incomuns executados pelo serviço Gogs ou por usuários de sistema associados ao serviço.
- Workflows GitHub criados recentemente, referências novas a nomes de segredos e uso anômalo de Personal Access Tokens.
Como CVE-2025-8110 é descrita como uma falha sem correção disponível no momento da divulgação, a resposta deve priorizar redução de exposição e contenção. Instâncias Gogs não devem permanecer acessíveis diretamente pela internet sem controle de origem, autenticação forte e restrição de criação de contas. O registro aberto deve ser desabilitado, e o acesso administrativo deve ser limitado a redes, VPNs ou proxies autenticados compatíveis com a arquitetura do ambiente.
A triagem de comprometimento deve ocorrer antes de qualquer normalização operacional. Equipes devem inventariar instâncias expostas, identificar repositórios com nomes aleatórios, revisar arquivos de configuração Git alterados, procurar payloads baseados em Supershell e verificar conexões reversas ou processos suspeitos. Se houver evidência de execução local de código, o servidor deve ser tratado como comprometido: preservar evidências, isolar a instância, revisar contas criadas, rotacionar chaves e tokens associados e validar integridade de repositórios e automações conectadas.
A mitigação também precisa considerar o contorno da correção anterior. Aplicar somente atualizações referentes a CVE-2024-55947 não basta se a instância continua exposta ao novo comportamento explorável. Até que uma correção específica esteja disponível, controles compensatórios devem impedir criação abusiva de repositórios, reduzir permissões da API, limitar tráfego de saída e monitorar alterações em arquivos sensíveis. Para ambientes de desenvolvimento integrados a nuvem, a rotação de Personal Access Tokens e a revisão de permissões de workflows devem entrar no mesmo ciclo de resposta, principalmente quando houver sinais de abuso de identidade ou execução anômala em CI/CD.
- Desabilitar registro aberto em instâncias Gogs e restringir acesso público por rede, VPN, proxy autenticado ou lista de origens confiáveis.
- Procurar e preservar evidências de repositórios com nomes aleatórios de 8 caracteres antes de remover artefatos suspeitos.
- Revisar
.git/config,sshCommand, processos do serviço e tráfego de saída para identificar execução local de código ou sessão reversa. - Isolar servidores com sinais de comprometimento e rotacionar chaves SSH, tokens, webhooks e credenciais de implantação associadas.
- Revisar GitHub Personal Access Tokens, permissões de escrita, workflows recentes e referências a segredos em YAML quando o ambiente integrar Gogs, GitHub e provedores de nuvem.
0 Comentários