A exploração ativa de uma vulnerabilidade zero-day no Gogs colocou administradores e desenvolvedores em estado de alerta, já que hackers estão comprometendo servidores por meio de uma falha que permite execução remota de código (RCE). A brecha, identificada como CVE-2025-8110, envolve um abuso de path traversal por meio de links simbólicos, criando um vetor de ataque extremamente perigoso para qualquer instância exposta na internet.
Este artigo explica como a falha funciona, por que ela é tão crítica e quais são as ações imediatas que administradores precisam aplicar para proteger seus ambientes. Como o Gogs é amplamente usado como alternativa leve ao GitLab e ao GitHub, essa descoberta afeta diretamente equipes que dependem de auto-hospedagem para repositórios Git.
Com a exploração já confirmada em mais de 700 servidores, entender o impacto e agir rapidamente tornou-se indispensável para impedir danos mais profundos.
O que é o Gogs e a gravidade da falha zero-day
O Gogs é um serviço Git auto-hospedado cujo foco é ser simples, leve e rápido. Ele permite que equipes gerenciem repositórios sem depender de plataformas externas, oferecendo controle total sobre o ambiente. Essa autonomia traz vantagens, mas também exige atenção redobrada à segurança, especialmente quando surgem falhas críticas antes da liberação de qualquer correção.
Uma vulnerabilidade classificada como zero-day significa que a falha está sendo explorada antes da existência de um patch oficial, deixando os administradores sem uma correção imediata provida pelo fornecedor. Quando combinamos isso com o fato de que o Gogs é amplamente utilizado em ambientes expostos, o risco se amplia.
No caso desta falha específica, o problema envolve uma validação insuficiente de caminhos que deveria impedir acessos indevidos ao sistema de arquivos, mas que está sendo contornada por meio de links simbólicos.
CVE-2025-8110: a falha de path traversal via links simbólicos
A vulnerabilidade CVE-2025-8110 decorre de uma implementação incorreta na forma como o Gogs processa links simbólicos dentro de repositórios. A validação atual não impede que esses links apontem para diretórios fora do caminho esperado, permitindo que invasores realizem path traversal e forcem o servidor a escrever arquivos em locais arbitrários.
O mais grave é que esse mecanismo contorna uma correção anterior relacionada ao CVE-2024-55947, indicando que as proteções adicionadas anteriormente não cobriram todos os cenários de exploração. Combinando o link simbólico com operações legítimas de escrita de arquivos, o invasor consegue mover a escrita para diretórios sensíveis, incluindo áreas de configuração do sistema.
Esse comportamento abre espaço para a modificação de componentes internos do servidor e prepara o terreno para a execução remota de comandos. Como o ataque ocorre dentro do fluxo lógico de manipulação de arquivos, ele é difícil de detectar sem monitoramento cuidadoso.
O vetor de ataque: como a RCE foi alcançada em mais de 700 servidores
A exploração da vulnerabilidade se baseia principalmente na API do Gogs, em especial no recurso conhecido como PutContents. Essa funcionalidade, usada para inserir arquivos em repositórios, torna-se perigosa quando combinada com o path traversal, pois permite escrever arquivos fora do local esperado.
O alvo preferencial dos atacantes é o arquivo de configuração sshCommand, responsável por definir comandos executados pelo servidor durante operações Git via SSH. Substituindo o conteúdo legítimo desse arquivo, o invasor injeta comandos maliciosos que são executados automaticamente pelo servidor.
Esse mecanismo leva diretamente à execução arbitrária de código, permitindo ações como: instalação de backdoors, execução de payloads remotos, alteração de repositórios, roubo de dados, persistência no sistema.
Pesquisadores observaram que a campanha de exploração já atingiu mais de 700 servidores ao redor do mundo, sugerindo o uso de automação e varreduras constantes em busca de instâncias vulneráveis.
Análise do malware e os indicadores de comprometimento
Após alcançar RCE, os atacantes implantam componentes baseados no framework Supershell, conhecido por suas capacidades de controle remoto e persistência. Uma vez instalado, o Supershell permite que o invasor mantenha acesso contínuo ao servidor, execute comandos adicionais e modifique arquivos sensíveis.
Entre os indicadores de comprometimento mais observados estão: modificações suspeitas no sshCommand, repositórios desconhecidos com nomes aleatórios de oito caracteres, processos associados ao Supershell, conexões de saída para hosts suspeitos.
Esses elementos aparecem com frequência em servidores já comprometidos, segundo as investigações. Caso um administrador encontre qualquer um desses sinais, é provável que a instância já esteja sob controle do atacante.
Ações imediatas: como administradores do Gogs devem se proteger
A ausência de patch oficial torna indispensável aplicar medidas de mitigação imediata para reduzir o impacto e impedir novos ataques. Administradores devem seguir quatro ações principais.
1. Restringir permissões de escrita via API: O ataque depende da escrita remota de arquivos. Limitar o acesso ao recurso de escrita da API, principalmente para contas externas, reduz drasticamente o potencial de exploração. Somente usuários internos e confiáveis devem manter permissões de escrita.
2. Bloquear repositórios contendo links simbólicos suspeitos: Repositórios que incluem links simbólicos para locais fora da estrutura esperada devem ser rejeitados. Scripts de validação ou políticas internas podem ajudar a identificar e bloquear esses padrões.
3. Endurecer permissões de arquivos críticos como sshCommand: Configurar permissões mais rígidas, como chmod 600, evita que processos externos modifiquem arquivos essenciais. Além disso, o monitoramento contínuo de hashes e horários de modificação ajuda a detectar alterações maliciosas.
4. Verificar comprometimento e limpar artefatos: Administradores devem revisar logs recentes, especialmente de criação e modificação de repositórios. Estruturas com nomes aleatórios são fortes indícios de ataque.
Se houver sinais de que o sshCommand foi modificado ou de que há processos relacionados ao Supershell em execução, a recomendação imediata é: isolar o servidor, revogar chaves e credenciais, restaurar a instância a partir de backups confiáveis.
Como a exploração é ativa e contínua, qualquer instância exposta deve ser tratada como potencialmente vulnerável. A mitigação rápida é essencial até que o projeto Gogs disponibilize correções oficiais.
