Vulnerabilidad Crítica de RCE en Gogs Expone Repositorios a Toma de Control Completa
Se ha descubierto una vulnerabilidad crítica de ejecución remota de código (RCE) en **Gogs**, un servicio Git autohospedado, que podría permitir a usuarios autenticados ejecutar código arbitrario. La vulnerabilidad, que actualmente carece de un identificador **CVE**, representa un riesgo significativo para las instancias de Gogs con configuraciones predeterminadas.

### Vulnerabilidad RCE en Gogs: Un Análisis Profundo
El investigador de seguridad Jonah Burgess de **Rapid7** ha revelado una vulnerabilidad crítica en **Gogs**, un servicio Git autohospedado de código abierto. La falla permite que cualquier usuario autenticado logre la ejecución remota de código (RCE) en el servidor. La vulnerabilidad surge de la capacidad de inyectar el flag `--exec` en `git rebase` durante la operación de 'Rebase antes de fusionar' al crear una solicitud de extracción con un nombre de rama malicioso. **Rapid7** califica la vulnerabilidad con un 9.4 en el sistema de puntuación CVSS.
### Comprendiendo el Vector de Ataque
El ataque aprovecha la funcionalidad `git rebase`, que integra cambios de una rama en otra. El flag `--exec` permite la ejecución de comandos de shell después de que cada commit es reproducido durante la operación de rebase. Es importante destacar que explotar esta vulnerabilidad no requiere privilegios administrativos ni ninguna interacción de otros usuarios. Un atacante puede simplemente crear una cuenta y un repositorio en una instancia de **Gogs** configurada por defecto para iniciar el ataque.
Burgess explica: "Cualquier usuario registrado que crea un repositorio es automáticamente su propietario. A partir de ahí, habilitar la fusión por rebase es un simple interruptor en la configuración, y toda la cadena de explotación puede operarse sin interacción de ningún otro usuario."
### Escenario de Ataque Alternativo
En escenarios donde la fusión por rebase ya está habilitada en un repositorio, un usuario con acceso de escritura puede explotar directamente la falla para obtener ejecución de código. Sin embargo, en instancias de **Gogs** donde la creación de repositorios está restringida, un atacante debe poseer acceso de escritura a un repositorio con la fusión por rebase habilitada.
### Vulnerabilidad sin Parche y Posible Impacto
Al momento de escribir esto, la vulnerabilidad permanece sin parche a pesar de haber sido reportada al mantenedor el 17 de marzo de 2026. La explotación exitosa podría permitir a un atacante:
* Comprometer el servidor
* Acceder a todos los repositorios en la instancia
* Extraer credenciales
* Moverse lateralmente a otros sistemas accesibles por la red
* Manipular el código de cualquier repositorio alojado
Además, la vulnerabilidad podría conducir a una brecha de datos entre inquilinos, exponiendo los repositorios privados de otros usuarios alojados en el mismo servidor. La falla afecta a todas las plataformas compatibles, incluidas Windows, Linux y macOS.
### Estrategias de Mitigación
Con un estimado de 1,141 instancias de **Gogs** expuestas a Internet, y muchas más detrás de VPN o redes internas, el impacto potencial es significativo. En ausencia de un parche oficial, se recomiendan las siguientes mitigaciones:
* Restringir el registro de usuarios (`DISABLE_REGISTRATION = true` en `app.ini`)
* Restringir la creación de repositorios (`MAX_CREATION_LIMIT = 0` en `app.ini`)
* Auditar la configuración de fusión por rebase
### Módulo Metasploit Disponible
**Rapid7** ha lanzado un módulo **Metasploit** que automatiza la cadena de explotación contra objetivos tanto en Linux como en Windows. El módulo admite dos modos:
1. Crear un repositorio temporal bajo la cuenta del atacante, ejecutar el exploit y eliminar el repositorio.
2. Atacar un repositorio existente al que el atacante tiene acceso de escritura y fusión.
Burgess señala: "Cuando el atacante crea y elimina su propio repositorio, el único rastro es un HTTP 500 en los logs del servidor. Al explotar un repositorio existente, quedan artefactos adicionales."