Vulnerabilidad crítica CVE-2026-60004 en Gitea explotada activamente

CISA confirmó el 25 de agosto de 2026 la explotación activa de la vulnerabilidad crítica CVE-2026-60004 en la plataforma de gestión de repositorios Git Gitea y la incorporó en su catálogo Known Exploited Vulnerabilities (KEV). La vulnerabilidad, con una puntuación CVSS de 9.8, permite a un atacante con permisos de escritura en un repositorio ejecutar comandos arbitrarios en el servidor con la cuenta de sistema de Gitea. El riesgo se agrava porque la configuración predeterminada de Gitea permite el registro abierto, lo que implica que el atacante no necesita credenciales obtenidas de antemano: basta con registrar una cuenta y crear su propio repositorio. Los organismos federales de EE. UU. están obligados a corregir la vulnerabilidad antes del 28 de agosto de 2026. Se recomienda a todos los administradores de Gitea actualizar de inmediato a la versión 1.27.1 o superior.

Mecanismo de explotación

La vulnerabilidad afecta al endpoint de API diffpatch, destinado a trabajar con parches. El atacante envía un parche malicioso especialmente preparado a este endpoint, lo que permite inyectar un Git hook ejecutable a partir de contenido controlado por el repositorio. Una vez instalado el hook, el atacante obtiene la capacidad de ejecutar comandos de shell arbitrarios con la cuenta de servicio de Gitea a nivel del sistema operativo.

Formalmente, la invocación del API vulnerable requiere autenticación y permisos de escritura en el repositorio. Sin embargo, la cadena de explotación se vuelve trivial en instancias con la configuración por defecto:

• El atacante registra una nueva cuenta (el registro abierto está activado por defecto)
• Crea su propio repositorio, obteniendo automáticamente permisos de escritura en él
• Envía el parche malicioso al endpoint diffpatch
• El Git hook implantado ejecuta código arbitrario en el servidor

Según los datos disponibles, son vulnerables todas las versiones de Gitea desde la 1.17. La corrección se publicó en la versión 1.27.1. El descubrimiento de la vulnerabilidad se atribuye a un investigador de seguridad conocido bajo el seudónimo NightRang3r.

Configuración predeterminada peligrosa

El factor clave que convierte esta vulnerabilidad, que en principio requiere privilegios, en algo prácticamente accesible sin autenticación es el conjunto de parámetros de configuración que en Gitea crean por defecto un entorno abierto. Según la documentación oficial de Gitea, los parámetros críticos de la sección [service] son los siguientes:

• DISABLE_REGISTRATION = false — el registro de nuevos usuarios está permitido
• REGISTER_EMAIL_CONFIRM = false — no se requiere confirmación de correo electrónico
• ENABLE_OPENID_SIGNUP = true — el registro mediante OpenID está permitido
• REQUIRE_SIGNIN_VIEW = false — la visualización de páginas y el uso del API no requieren autenticación

Esta combinación implica que cualquier usuario externo puede crear una cuenta sin ninguna restricción, obtener un repositorio con permisos de escritura y explotar la vulnerabilidad. El vector de ataque funciona a través de HTTPS, por lo que la ausencia de acceso SSH abierto a Gitea no constituye una protección.

Indicadores de explotación

CISA no ha revelado detalles sobre incidentes concretos de explotación ni ha indicado qué grupos están detrás de los ataques. No obstante, la inclusión de la vulnerabilidad en el catálogo KEV implica que la agencia dispone de pruebas fiables de explotación activa.

Independientemente de ello, en la plataforma Habr se publicó una nota de un desarrollador que describe la compromisión de su propia instancia de Gitea a través de CVE-2026-60004. Sin embargo, esta información se basa en una única fuente no verificada y no ha sido confirmada por investigadores independientes ni por el proveedor, por lo que los detalles del incidente descrito deben tomarse con cautela.

Evaluación del impacto

Gitea es una plataforma autoalojada popular para la gestión de repositorios Git, ampliamente utilizada en pequeños y medianos equipos de desarrollo, instituciones educativas y proyectos de código abierto. La magnitud del impacto potencial viene determinada por varios factores:

• Amplio rango de versiones vulnerables — se ven afectadas todas las versiones a partir de la 1.17, lo que abarca una parte significativa de las instalaciones existentes
• Baja barrera de entrada para el atacante — la explotación no requiere acceso previo con la configuración estándar
• Criticalidad de las consecuencias — la ejecución de código a nivel del sistema operativo abre la puerta a la completa compromisión del servidor, al robo de código fuente, a la inserción de puertas traseras maliciosas en los repositorios y al movimiento lateral dentro de la infraestructura
• Riesgo de ataques a la cadena de suministro — la compromisión del servidor de gestión de código puede conducir a la inyección de código malicioso en los artefactos generados

Recomendaciones de protección

La prioridad de respuesta es máxima. Acciones recomendadas:

1. Actualice Gitea a la versión 1.27.1 o posterior. Es la única forma completa de eliminar la vulnerabilidad.
2. Si una actualización inmediata no es posible, aplique las siguientes medidas temporales:
   • Establezca DISABLE_REGISTRATION = true para bloquear el registro de nuevos usuarios
   • Establezca REQUIRE_SIGNIN_VIEW = true para restringir el acceso al API
   • Desactive ENABLE_OPENID_SIGNUP
   • Active REGISTER_EMAIL_CONFIRM
3. Realice una auditoría de las cuentas registradas recientemente y de los repositorios creados en busca de actividad sospechosa.
4. Compruebe la existencia de Git hooks atípicos en los repositorios, especialmente aquellos que contengan scripts ejecutables.
5. Supervise la carga de CPU — un consumo de recursos anómalo puede indicar la presencia de código malicioso desplegado.
6. Restrinja el acceso de red a la instancia de Gitea mediante un firewall, si la plataforma no está destinada a uso público.

Teniendo en cuenta la explotación activa confirmada por CISA y la puntuación CVSS de 9.8, la actualización de Gitea a la versión 1.27.1 debe realizarse en cuestión de horas, no de días. Para las instancias en las que la actualización se retrasa, desactivar el registro abierto es la medida mínima necesaria que rompe la cadena de explotación más accesible, pero no elimina la propia vulnerabilidad para los usuarios que ya disponen de permisos de escritura.