Miles de instancias de Gitea accesibles desde Internet permanecían sin aplicar parches a finales de agosto respecto a CVE-2026-60004, una vulnerabilidad crítica que permite la ejecución remota de comandos. La corrección fue lanzada con Gitea 1.27.1 y el problema ya consta como explotación activa en el catálogo KEV de CISA.
La plataforma Gitea, uno de los sistemas más utilizados para alojar repositorios Git en infraestructuras propias, enfrenta un problema de consideración: al 27 de agosto de 2026 existían 8.393 instancias expuestas a Internet que seguían siendo vulnerables a CVE-2026-60004, una brecha crítica con capacidad de ejecución remota de comandos. La situación genera preocupación porque no se trata de un fallo teórico; ya se ha detectado explotación activa en el terreno y el margen para implementar la corrección se ha reducido.
La vulnerabilidad combina dos componentes que en conjunto permiten al atacante ejecutar comandos en el servidor. Por una parte, es posible abusar del endpoint diffpatch para inyectar contenido. Por otra, ese contenido puede provocar la instalación y ejecución de un Git hook controlado desde el repositorio. El resultado es que el servidor ejecuta órdenes sin que el atacante requiera acceso previo al sistema operativo.
La ejecución no se realiza con permisos de administrador, pero sí con los privilegios de la cuenta que ejecuta el servicio, es decir, el usuario del sistema en el cual corre Gitea. En numerosos despliegues eso es suficiente para crear una vía de exfiltración: secretos de configuración, credenciales de base de datos, tokens de integraciones, credenciales OAuth y variables sensibles del entorno. El alcance real depende del aislamiento del despliegue y del modelo de permisos, especialmente si la instancia se ejecuta en un host compartido o con permisos amplios.
El ataque requiere acceso de escritura a un repositorio, aunque aquí emerge el problema habitual: el registro de usuarios abierto se encuentra habilitado de forma predeterminada en muchas instalaciones. Esto permite que un atacante se registre, cree un repositorio y complete la cadena de ataque sin contar con credenciales previas, principalmente si el registro no solicita confirmación por correo electrónico ni implementa controles anti automatización.
El proyecto corrigió CVE-2026-60004 en Gitea 1.27.1, publicada el 27 de julio de 2026. No obstante, la cantidad de instancias sin actualizar evidencia una superficie de ataque considerable, con exposición especialmente alta en servicios que publican su forja directamente en la red. Además, CISA incluyó el fallo el 25 de agosto en el catálogo Known Exploited Vulnerabilities (KEV), una señal evidente de que la amenaza ya se propaga en campañas activas, y estableció el 28 de agosto como fecha límite de remediación para agencias federales estadounidenses.
En ciertos incidentes reportados, los atacantes utilizaron el acceso para desplegar software de minería de criptomonedas en instalaciones con Docker. Ese patrón coincide con lo habitual en servicios expuestos: una intrusión rápida, monetización inmediata y persistencia mínima. Sin embargo, no existe confirmación pública de un actor concreto o una campaña atribuida oficialmente.
La respuesta aconsejada consiste en actualizar Gitea mínimamente a 1.27.1 y, si el entorno lo permite, priorizar 1.27.2 para disminuir riesgo operativo. Conviene deshabilitar el registro abierto si no resulta esencial o reforzarlo con confirmación por correo electrónico y CAPTCHA. Asimismo, corresponde examinar posibles indicadores de compromiso: creación o ejecución anómala de Git hooks, patrones inusuales en el endpoint diffpatch, procesos con consumo sostenido de CPU y descargas de binarios desde la propia instancia.
Si existe sospecha de intrusión, la higiene básica deviene urgente: rotación de credenciales y secretos, desde claves de configuración y credenciales de base de datos hasta tokens de integraciones y secretos OAuth. Y, para reducir exposición futura, resulta prudente limitar el acceso por red, permitir solo rangos necesarios y reforzar el control de permisos de escritura.
En despliegues con Docker, es recomendable verificar el aislamiento del contenedor, reducir conectividad saliente y ajustar redes y permisos, debido a que una ejecución de comandos dentro del contenedor puede transformarse en un problema mayor si el entorno deja puertas abiertas. Además, quienes utilicen cabeceras de autenticación de proxy inverso deben verificar su configuración: la imagen oficial de Docker de Gitea también se vincula a un bypass de autenticación diferente, CVE-2026-20896, cuando se habilitan cabeceras como X-WEBAUTH-USER. En una forja de código, una única brecha puede ser suficiente para convertir un repositorio en un punto de entrada a toda la infraestructura.
Con Información de unaaldia.hispasec.com
