Red Heron explota una vulnerabilidad crítica de ejecución remota de código en Gitea y compromete 13 organizaciones

Un actor de amenazas presuntamente vinculado con China, rastreado como Red Heron, ha explotado una vulnerabilidad crítica de Gitea para comprometer plataformas de desarrollo, robar repositorios, recopilar credenciales e infiltrarse en infraestructuras conectadas.

La Acronis Threat Research Unit identificó 13 compromisos organizativos confirmados en Canadá, Argentina, Taiwán, Estados Unidos, Qatar y Sri Lanka. Los objetivos operaban en sectores como defensa, elecciones, energía, aeronáutica, telecomunicaciones, Administración pública, seguridad ciudadana e investigación.

La campaña fue mucho más allá del robo de código fuente. En un entorno de Taiwán, Red Heron obtuvo control administrativo con privilegios de root sobre un clúster de Proxmox de tres nodos tras acceder a través de un servidor Gitea vulnerable.

Red Heron combinó el escaneo masivo con la selección estratégica de objetivos

Red Heron escaneó 1.386 instancias de Gitea expuestas a Internet en siete países. El actor también mantenía un conjunto de datos independiente con 477 sistemas en Taiwán, aunque no se sabe si esos sistemas coincidían con los resultados del escaneo más amplio.

Los 13 compromisos confirmados se distribuyeron de la siguiente manera:

• Cuatro organizaciones en Taiwán
• Cuatro en Estados Unidos
• Dos en Canadá
• Una en Argentina
• Una en Qatar
• Una en Sri Lanka

No se ha identificado el séptimo país incluido en la operación de escaneo.

Aunque parte de la actividad se asemejaba a una explotación oportunista a escala global, la selección y clasificación de los objetivos mostraban una labor de recopilación de inteligencia más deliberada. Entre los sectores afectados había organizaciones que probablemente custodiaban tecnología sensible, datos de infraestructuras, información gubernamental o accesos privilegiados a otras redes.

La TRU evaluó con un nivel de confianza moderado que el actor operaba en un contexto vinculado con China. Esta evaluación no constituye una atribución definitiva al Gobierno chino. Se basa en el uso de etiquetas en chino simplificado por parte de Red Heron, en su clasificación sistemática de Taiwán como parte de China y en una selección de objetivos alineada con las prioridades percibidas de los servicios de inteligencia chinos.

La actividad relacionada también afectó a una consultora de educación internacional con sede en India y a un proveedor de servicios de TI gestionados de Estados Unidos. Estas organizaciones fueron atacadas mediante infraestructura asociada, pero no se describen como compromisos confirmados adicionales al total de 13 países.

CVE-2026-60004 permite ejecutar código de forma remota sin autenticación

El vector de acceso inicial fue CVE-2026-60004, una vulnerabilidad de ejecución remota de código que afecta a las versiones de Gitea anteriores a la 1.27.1.

El fallo se encuentra en la API diffpatch de Gitea y permite a un atacante instalar un Git hook. Dado que los Git hooks pueden ejecutar comandos en respuesta a operaciones sobre repositorios, el abuso de este mecanismo proporciona al atacante una vía para ejecutar código en el servidor subyacente.

CVE-2026-60004 tiene una puntuación CVSS v3 de 9,8 y está clasificada como CWE-94, control inadecuado de la generación de código. Su vector es:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

La vulnerabilidad puede explotarse de forma remota, requiere una complejidad de ataque baja y no exige una cuenta existente ni la interacción del usuario. Una explotación exitosa puede tener un impacto alto en la confidencialidad, la integridad y la disponibilidad.

La vulnerabilidad se divulgó en julio de 2026. Según la información publicada sobre la campaña, Red Heron comenzó a convertir el material de explotación disponible públicamente en un framework automatizado de Python llamado exp_enhanced.py el 29 de julio de 2026.

Ese framework automatizaba varias fases que, de otro modo, requerirían acciones independientes del operador: registrar cuentas, explotar servidores vulnerables, robar repositorios y eliminar determinadas pruebas. Esto reducía el tiempo entre la identificación de una instancia expuesta y la recopilación de sus datos.

El acceso a los repositorios se convirtió en una vía hacia las redes internas

Una plataforma de desarrollo autohospedada puede contener mucho más que el código fuente de una aplicación. Los repositorios suelen incluir archivos de despliegue, direcciones de servidores, tokens de API, material SSH, credenciales de integración y secretos de configuración. Incluso cuando los secretos individuales están desactualizados, pueden revelar convenciones de nomenclatura y la estructura de la red.

Red Heron utilizó los sistemas Gitea comprometidos como puntos de recopilación y, cuando fue posible, como puentes hacia los entornos de las víctimas. La actividad observada avanzó mediante el robo de repositorios, la recopilación de credenciales, la persistencia, el reconocimiento interno y el movimiento lateral.

En una empresa taiwanesa de automatización industrial, el actor exfiltró cientos de repositorios. El material robado incluía un producto SCADA/HMI, integraciones con plataformas de IoT, un analizador de tráfico de red, configuraciones de servidores, software de vigilancia y monitorización, y aplicaciones empresariales internas.

Posteriormente, la intrusión se amplió hasta conseguir acceso con privilegios de root en tres nodos de Proxmox. El control root de los hosts de virtualización podía proporcionar al atacante una amplia visibilidad y capacidad administrativa sobre las cargas de trabajo ejecutadas en el clúster, aunque no se han revelado todas las consecuencias en este caso.

Una empresa canadiense de energías renovables sufrió un mapeo exhaustivo de su infraestructura y el robo de repositorios. El material expuesto incluía secretos de configuración, tokens internos, claves de host SSH y aplicaciones propietarias.

En una empresa argentina de trading cuantitativo, Red Heron realizó una enumeración exhaustiva de la infraestructura de la organización. Una víctima con sede en Qatar perdió repositorios asociados a una plataforma de gestión del aprendizaje, un chatbot de IA, herramientas de automatización de flujos de trabajo y plugins de WordPress.

Estos incidentes demuestran por qué aplicar parches únicamente al servidor Gitea puede no poner fin a una intrusión. Las credenciales y claves obtenidas antes de la corrección pueden seguir siendo útiles después.

JITTERLY y SIXZUT facilitaron el acceso persistente a sistemas Linux

La infraestructura atribuida a Red Heron contenía un implante para Linux escrito en C++ y denominado JITTERLY. El malware admite más de 30 comandos posteriores a la explotación, entre ellos la ejecución de shell, la transferencia de archivos, la terminación de procesos, la creación de túneles de red, el acceso a terminales interactivas y el pivotado interno.

Un investigador que utiliza el alias «dmpdump» documentó JITTERLY en julio de 2026 e identificó coincidencias con el agente AdaptixC2. La información disponible no permite determinar si Red Heron desarrolló el implante o adoptó código existente.

El mismo entorno de staging alojaba SIXZUT, un rootkit para Linux no documentado anteriormente y basado en LD_PRELOAD. Esta técnica hace que una biblioteca compartida maliciosa se cargue antes que las bibliotecas legítimas, lo que le permite interceptar las llamadas realizadas por los programas del sistema.

SIXZUT modifica 15 funciones de Linux para ocultar archivos, procesos y conexiones de red. También está diseñado para resistir su eliminación mediante su relanzamiento después de ser terminado. Estas capacidades pueden ocultar el tráfico de comando y control y los procesos maliciosos de las comprobaciones administrativas rutinarias.

La infraestructura compartida vinculó la campaña contra Gitea con ataques contra 18 sitios web Joomla en 10 países. Para la actividad contra Joomla se utilizó un script de Python llamado exp.py, antes de que el operador incorporara el código público de explotación de CVE-2026-60004 a sus herramientas para Gitea. Esto apunta a una operación de explotación web más amplia, en lugar de una actividad limitada a un único producto de software.

CISA incorporó el fallo al catálogo KEV con un plazo de tres días

CISA añadió CVE-2026-60004 a su catálogo Known Exploited Vulnerabilities el 25 de agosto de 2026. El plazo de corrección para las agencias federales estadounidenses vencía el 28 de agosto de 2026.

El breve plazo reflejaba una explotación confirmada, no un riesgo teórico. Conforme a la medida registrada, las agencias deben aplicar las mitigaciones del proveedor y cumplir al mismo tiempo con la BOD 26-04, «Priorización de las actualizaciones de seguridad en función del riesgo», y con los requisitos de triaje forense de CISA.

Las directrices aplicables de la BOD 26-04 también abarcan los servicios en la nube. Si no existen mitigaciones eficaces, CISA ordena a las agencias dejar de utilizar el producto afectado. Las organizaciones siguen siendo responsables de evaluar la exposición de cada activo a Internet y de cumplir los requisitos de aplicación de parches correspondientes.

Todas las versiones de Gitea anteriores a la 1.27.1 están afectadas. Los operadores deben actualizar a la versión 1.27.1 o posterior, siguiendo las instrucciones de Gitea y sus propios procedimientos de control de cambios.

La aplicación de parches debe ir acompañada de una evaluación del compromiso

Las organizaciones deben elaborar primero un inventario de todas las implementaciones de Gitea, incluidos los servidores de pruebas olvidados y las instancias expuestas a través de proxies inversos. Cualquier sistema afectado accesible desde Internet debe recibir atención inmediata.

A continuación, los equipos de defensa deben investigar si la explotación tuvo lugar antes de la actualización. Entre los aspectos que conviene revisar se incluyen:

• Registros inesperados de cuentas de Gitea
• Creación o modificación de Git hooks
• Actividad inusual en la API diffpatch
• Acceso masivo a repositorios o transferencias salientes
• Claves SSH creadas recientemente o archivos de claves autorizadas modificados
• Exposición o uso de secretos de configuración y tokens internos
• Acciones administrativas inesperadas en Proxmox
• Procesos, túneles o conexiones salientes sospechosos en Linux
• Configuraciones LD_PRELOAD y bibliotecas compartidas no reconocidas
• Archivos o comandos asociados con exp_enhanced.py, exp.py, JITTERLY o SIXZUT

Los secretos almacenados en los repositorios afectados deben considerarse potencialmente expuestos. Los tokens de API, contraseñas, claves SSH, material de firma y credenciales de servicio pertinentes deben rotarse, y los registros de autenticación deben revisarse para detectar usos posteriores.

Los sistemas que muestren indicios de SIXZUT pueden no proporcionar información fiable sobre procesos o redes, ya que el rootkit puede manipular la visibilidad en el espacio de usuario. En esos casos, los equipos de respuesta deben utilizar herramientas forenses conocidas como limpias y recopilar las pruebas antes de reconstruir los hosts afectados.

El riesgo principal no se limita a la aplicación Gitea. Cuando un servidor de desarrollo expone código fuente, credenciales y configuraciones de infraestructura, el compromiso puede propagarse a los sistemas que compilan, despliegan, alojan o gestionan el software de una organización.