Cómo explotar y mitigar la vulnerabilidad RCE crítica en Gitea

Gitea ha corregido una vulnerabilidad crítica de ejecución remota de código (CVE-2026-60004, CVSS 9.8) que permite a un usuario con permisos de escritura en un repositorio inyectar un Git hook ejecutable a través del endpoint de API diffpatch y ejecutar comandos arbitrarios con la cuenta de servicio de Gitea. La vulnerabilidad afecta a todas las versiones desde la 1.17 hasta la 1.27.1. La corrección está disponible en la versión 1.27.1. El código de exploit público (PoC) ya está disponible, aunque en el momento de la publicación no se han registrado casos confirmados de explotación en ataques reales. Todos los administradores de instancias self-hosted de Gitea deben actualizar de inmediato.

Mecanismo de explotación

El endpoint vulnerable POST /api/v1/repos/{owner}/{repo}/diffpatch aplica un parche proporcionado por el usuario dentro de un clon temporal compartido del repositorio en modo bare. Según el advisory oficial de Gitea, las compilaciones vulnerables invocan git apply con las flags --index, --recount, --cached y --binary. Si en el servidor se utiliza Git versión 2.32 o superior, se activa adicionalmente la flag -3 (three-way merge fallback).

El ataque se basa en la siguiente cadena:

1. El atacante envía el mismo parche dos veces, creando una colisión de tipo add/add.
2. El mecanismo three-way fallback extrae la ruta indexada al árbol de trabajo, a pesar del uso de --cached.
3. Dado que el clon temporal es un repositorio bare, su directorio raíz coincide con $GIT_DIR. Un ejecutable ubicado en la ruta hooks/post-index-change se guarda directamente en el directorio de hooks de Git.
4. Git ejecuta automáticamente el hook post-index-change cuando se actualiza el índice, lo que otorga al atacante ejecución de código arbitrario.

El PoC demuestra el ciclo completo del ataque sin necesidad de conexión de retorno: el hook guarda la salida de los comandos en objetos de Git, crea una rama con el resultado y el atacante recupera los datos a través de Smart HTTP autenticado.

Condiciones de explotación y superficie de ataque

Formalmente, el endpoint requiere autenticación y permisos de escritura en el repositorio: la ruta invoca reqToken(), que rechaza las solicitudes no autorizadas. Sin embargo, la configuración predeterminada de Gitea deja el registro abierto, no exige confirmación de email ni aprobación manual, no marca a los usuarios nuevos como restringidos y no establece un límite para la creación de repositorios. En una instalación sin cambios, un visitante externo puede registrarse por su cuenta, crear un repositorio y obtener los permisos de escritura necesarios.

El conjunto completo de condiciones para la explotación es:

• Permisos de escritura en un repositorio (alcanzables mediante registro abierto)
• Git versión 2.32 o superior en el servidor
• Ruta diffpatch habilitada
• Sistema de archivos temporal con permisos de escritura y ejecución

Consecuencias de la compromisión

Una explotación exitosa otorga al atacante los privilegios de la cuenta de sistema operativo bajo la que se ejecuta Gitea. Según el advisory, dependiendo del grado de aislamiento de la instancia, esto puede conducir a la exposición de:

• Secretos de la aplicación y variables de entorno
• Repositorios montados
• Credenciales y contenido de la base de datos
• Tokens OAuth
• Servicios internos accesibles en la red

Teniendo en cuenta que Gitea se despliega a menudo como nodo central para el almacenamiento del código fuente de una organización, la compromisión de la instancia puede convertirse en un punto de entrada para ataques a la cadena de suministro.

Particularidades de la divulgación y la corrección

La cronología de los acontecimientos merece una atención especial. La corrección fue mergeada y backporteada el 26 de julio de 2026. La versión 1.27.1 se publicó el 27 de julio y el security advisory se hizo público el 28 de julio. No obstante, en las release notes la corrección figura en la sección MISC como «refactor: git patch apply», y no en la sección SECURITY. Este etiquetado puede provocar que los administradores que solo siguen los parches de seguridad pasen por alto una actualización crítica.

La esencia de la corrección es cambiar el tipo de clon temporal de bare a non-bare. El comentario en el código del commit advierte explícitamente de que los comandos de Git con la flag --index pueden operar sobre el árbol de trabajo. En un clon non-bare, el directorio raíz deja de coincidir con $GIT_DIR, lo que rompe la cadena de inyección del hook.

La vulnerabilidad fue descubierta por el investigador de seguridad Shai Rod (NightRang3r), que figura como autor del hallazgo en el advisory de Gitea. Además de la RCE, en la versión 1.27.1 también se ha corregido un problema de inclusión de archivos en el renderizador de Org-mode: las directivas #+INCLUDE ahora se devuelven como texto plano en lugar de leer archivos desde el sistema de archivos del servidor. Gitea no ha publicado un advisory ni un CVE independiente para este problema.

Recomendaciones

• Actualice de inmediato todas las instancias Gitea self-hosted a la versión 1.27.1. Según Gitea, las instancias en la nube de Gitea Cloud se actualizan automáticamente.
• Desactive el registro abierto como medida temporal durante el periodo de actualización. Esto elimina la vía de ataque para usuarios externos no autenticados, pero no protege frente a usuarios existentes con permisos de escritura.
• Compruebe la versión de Git en el servidor: la explotación requiere Git 2.32+. Si por algún motivo no es posible actualizar Gitea de inmediato, rebajar la versión de Git por debajo de la 2.32 puede servir como solución temporal (teniendo en cuenta los posibles efectos secundarios).
• Audite los logs en busca de llamadas sospechosas al endpoint /api/v1/repos/{owner}/{repo}/diffpatch, especialmente solicitudes repetidas con contenido de parche idéntico.
• Revise el aislamiento de la cuenta de servicio de Gitea: limite el acceso a secretos, bases de datos y servicios internos siguiendo el principio de privilegios mínimos.

La combinación de un CVSS 9.8, un PoC público, el registro abierto por defecto y una clasificación poco evidente de la corrección en el changelog convierte a CVE-2026-60004 en una de las vulnerabilidades más peligrosas en el ecosistema de plataformas Git self-hosted de los últimos tiempos. La única acción realmente fiable es actualizar a Gitea 1.27.1 y, a continuación, revisar la configuración de registro y el aislamiento de la instancia. La entrada en la NVD confirma el nivel crítico de gravedad de la vulnerabilidad.