CISA confirma explotación activa de CVE 9.8 en Gitea, con mineros ingresando por el endpoint diffpatch
Vulnerabilidad CVSS 9.8 en Gitea permite que un atacante con permiso de escritura ejecute comandos como el usuario del servicio. CISA puso la falla en el KEV y dio plazo hasta el 28 de agosto para que las agencias federales apliquen parches.
Lo que CISA incluyó en el KEV
CISA agregó CVE-2026-60004 al Catálogo de Vulnerabilidades Conocidas Explotadas el martes 25 de agosto, y la semana siguiente trajo las primeras confirmaciones públicas de explotación en un entorno de producción de la plataforma de alojamiento de código Git autohospedada Gitea. La falla, con un CVSS de 9.8, permite que un atacante con permiso de escritura en cualquier repositorio envíe un parche maliciosamente formateado al endpoint diffpatch y plante un Git hook ejecutable, que ejecuta comandos de shell arbitrarios con el privilegio del proceso Gitea.
La brecha fue corregida por los mantenedores el 27 de julio, con la versión 1.27.1, y la alerta de seguridad salió al día siguiente. Entre la divulgación y la inclusión en el KEV, investigadores independientes monitoreaban escaneos automatizados en honeypots, sin informes públicos de compromisos efectivos. La situación cambió cuando un administrador ruso publicó en Habr el registro de una instancia propia comprometida. El relato describió un payload en dos fases: un shell-loader universal seguido por un dropper con comportamiento de minero de criptomonedas, ejecutado dentro del contenedor Gitea como el usuario git.
Las agencias federales estadounidenses deben aplicar parches hasta el viernes 28 de agosto, un plazo vinculante para toda la infraestructura bajo el Federal Civilian Executive Branch. Fuera del gobierno de EE.UU., la orientación de CISA es recomendable sin un plazo formal.
Por qué la falla afecta a quienes operaban Gitea "seguro"
La práctica habitual en DevSecOps es reducir la superficie de exposición de Gitea al colocar la instancia detrás de una VPN o de un bastión, y tratar el repositorio autohospedado como confiable. La CVE-2026-60004 rompe esta hipótesis en dos frentes.
Primero, el vector requiere solo escritura en algún repositorio. En instancias con registro abierto por defecto, comportamiento que la documentación oficial recomienda para equipos pequeños, cualquier cuenta puede crear su propio repositorio y convertirse en atacante autenticado en segundos. El relato de Habr describió exactamente esta cadena: un escáner registró una cuenta, creó un repositorio propio, disparó el exploit, escribió una prueba de concepto de vuelta en la rama principal e inició el dropper.
Segundo, el Git hook plantado se ejecuta dentro del proceso Gitea, que en la mayoría de las instalaciones se ejecuta como un servicio systemd con acceso a bases de datos internas, claves SSH y tokens de CI. La escalada al pipeline de construcción es inmediata, y quienes operan Gitea en Kubernetes con credenciales de AWS o GCP montadas a través de IRSA o Workload Identity están exponiendo potencialmente toda la cuenta de la nube al mismo atacante que ingresó por el registro público.
Dónde el impacto pesa más
Gitea aparece como una alternativa a GitHub Enterprise en tres perfiles de cliente. El primero es el equipo de infraestructura que necesita mantener el código dentro del perímetro por razones regulatorias, común en bancos alemanes bajo la supervisión de BaFin y en consultorías con contratos relacionados con el gobierno en el Reino Unido. El segundo es la operación india en proveedoras de outsourcing, que alojan repositorios de múltiples clientes bajo la misma instancia. El tercero es la startup latinoamericana que opera todo en un VPS único para contener costos.
En Alemania, Gitea es la plataforma preferida de equipos que evitan la salida de código a servidores fuera de la Unión Europea, y la exposición por la CVE-2026-60004 obliga a una revisión de riesgo en contratos que prevén un SLA de contención de 72 horas. En los hubs de entrega de TCS, Infosys y Wipro en Pune, Bengaluru y Manila, Gitea es una de las plataformas aprobadas para código de clientes con política de air-gap, y un compromiso en esta base tiene un efecto que va de leve a severo según la segmentación de inquilinos.
En Brasil, el panorama es diferente. Nubank, Stone y las áreas de tecnología de los grandes bancos operan predominantemente en GitHub Enterprise o GitLab, pero integradores de tamaño mediano y secretarías estatales de tecnología aún mantienen instancias de Gitea. La orientación práctica es la misma: actualizar a 1.27.2 y auditar logs desde el 27 de julio.
Qué auditar antes de considerar contenido
El equipo de seguridad que ya aplicó el parche necesita hacer tres verificaciones mínimas para descartar compromisos anteriores. Primero, listar todos los Git hooks creados después del 27 de julio en todos los repositorios de la instancia, prestando atención a scripts que abren sockets de red o descargan artefactos externos. Segundo, revisar el historial de cuentas creadas a través del registro abierto en el período y correlacionar con la creación inmediata de repositorios que contengan parches anómalos. Tercero, chequear procesos activos en el contenedor Gitea contra firmas de cryptominer comunes, comenzando por XMRig.
La documentación de Gitea incluye una cuarta acción que suele ser olvidada: deshabilitar el registro abierto si no hay razón explícita para mantenerlo. Las instancias con registro público siguen siendo el vector más barato para la escalada a atacantes externos, y la CVE-2026-60004 no es la primera ni será la última en explotar esta configuración por defecto. Cuando aparezca el próximo bug crítico de Gitea, el costo de respuesta será proporcional a cuántas cuentas anónimas quedaron en la base esta semana.