Vulnerabilidad RCE en Gogs expone repositorios y servidores Git

En Gogs, una solución popular para el autoalojamiento de repositorios Git, se ha descubierto una vulnerabilidad crítica de ejecución remota de código (RCE) con una puntuación de CVSS 9.4, según los investigadores de Rapid7. La vulnerabilidad permite a cualquier usuario autenticado ejecutar comandos arbitrarios en el servidor mediante la creación de un pull request con un nombre de rama malicioso. En el momento de la publicación no existe parche, y ya hay un módulo público de Metasploit que automatiza toda la cadena de explotación. Los administradores de instancias de Gogs deben aplicar de inmediato medidas de mitigación: desactivar el registro, restringir la creación de repositorios y auditar la configuración de fusiones con rebase.

Mecanismo de explotación: inyección de argumentos en git rebase

La esencia de la vulnerabilidad radica en la saneación insuficiente de los nombres de rama al ejecutar la operación «Rebase before merging». Tal como informa el investigador Jonah Burgess de Rapid7, el atacante crea un pull request con un nombre de rama que contiene la bandera --exec, la cual se inyecta en el comando git rebase. Según la documentación oficial de Git, el parámetro --exec acepta un comando de shell arbitrario que se ejecuta tras aplicar cada commit en el proceso de rebase.

La característica clave de la vulnerabilidad es el umbral de entrada extremadamente bajo para el atacante. Según los investigadores, su explotación no requiere privilegios de administrador ni interacción con otros usuarios. En una instancia de Gogs con la configuración predeterminada, la cadena de ataque se ve de la siguiente forma:

• El atacante registra una cuenta en la instancia objetivo
• Crea su propio repositorio (el creador se convierte automáticamente en propietario)
• Activa la opción de fusión con rebase; este es el único interruptor en la configuración
• Crea un pull request con un nombre de rama malicioso que contiene la inyección --exec
• Al ejecutarse la fusión con rebase, el comando arbitrario se ejecuta en el servidor

En un escenario alternativo, si la creación de repositorios está restringida, al atacante le basta con tener acceso de escritura a cualquier repositorio en el que ya esté habilitada la fusión con rebase. Según se indica, la vulnerabilidad afecta a todas las plataformas compatibles: Windows, Linux y macOS.

Ausencia de parche y disponibilidad del exploit

Según Rapid7, la vulnerabilidad fue comunicada al mantenedor del proyecto el 17 de marzo de 2026, pero en el momento de la divulgación no existe corrección. A la vulnerabilidad no se le ha asignado un identificador CVE, lo que dificulta su seguimiento en las bases de datos estándar. La puntuación CVSS 9.4 procede de Rapid7 y no ha sido confirmada por el proveedor ni por NVD.

La situación se agrava por la existencia de un módulo Metasploit público que automatiza toda la cadena de explotación para Linux y Windows. El módulo admite dos modos de operación:

• Modo predeterminado: se crea un repositorio temporal bajo la cuenta del atacante, se ejecuta el exploit y se elimina el repositorio. El único rastro es un registro HTTP 500 en los logs del servidor.
• Modo dirigido: explotación de un repositorio existente al que el atacante tiene acceso de escritura y de fusión. En este caso quedan más artefactos.

El rastro mínimo en los logs cuando se utiliza el primer modo dificulta significativamente la detección del ataque por parte de los equipos de respuesta a incidentes.

Evaluación del impacto

Según los investigadores, una explotación satisfactoria de la vulnerabilidad puede tener las siguientes consecuencias:

• Compromiso completo del servidor con acceso a todos los repositorios de la instancia
• Extracción de credenciales y secretos de los almacenes
• Movimiento lateral hacia otros sistemas accesibles por la red
• Modificación de código en cualquier repositorio alojado, un posible vector de ataque a la cadena de suministro
• Fuga de datos entre usuarios: lectura de repositorios privados de otros usuarios en el mismo servidor

Este último punto es especialmente crítico para organizaciones que utilizan una instancia compartida de Gogs para varios equipos o proyectos. La brecha de una sola cuenta con privilegios mínimos potencialmente expone todo el conjunto de código alojado.

Recomendaciones de protección

Ante la ausencia de un parche oficial, es necesario aplicar de inmediato las siguientes medidas:

• Desactivar el registro abierto: establecer DISABLE_REGISTRATION = true en el archivo app.ini para impedir la creación de cuentas por parte de usuarios no confiables
• Restringir la creación de repositorios: establecer MAX_CREATION_LIMIT = 0 en app.ini para que los usuarios no puedan crear repositorios por sí mismos
• Auditar la configuración de fusiones con rebase: comprobar todos los repositorios para detectar la opción «Rebase before merging» habilitada y desactivarla allí donde no sea estrictamente necesaria
• Revisar los logs del servidor: prestar atención a las entradas HTTP 500, que pueden indicar intentos de explotación
• Valorar la migración: para organizaciones con altos requisitos de seguridad, evaluar la transición a alternativas con mantenimiento activo, como Gitea (fork de Gogs con un ciclo de actualizaciones de seguridad más activo)

La combinación de la ausencia de parche, la disponibilidad pública de un módulo Metasploit y el bajo umbral de explotación crea una ventana de riesgo elevado para todas las instancias de Gogs. La acción prioritaria es desactivar el registro y las fusiones con rebase en todas las instancias accesibles desde Internet o desde segmentos de red no confiables, hasta la publicación de una corrección oficial por parte del mantenedor del proyecto.