MagnoSec
Servidor de repositorios Git con código representando la vulnerabilidad RCE en Gitea bajo explotación activa

MagnoSec Blog

RCE Crítico en Gitea Bajo Explotación Activa: El Servidor Git de tu Empresa Puede Estar Ejecutando Minería Ahora Mismo

Por Equipo MagnoSec8 min de lectura

Gitea bajo explotación activa: el servidor Git que aloja tu código ejecutando payloads ajenos

Gitea es el servidor Git open-source más popular entre las empresas que prefieren alojar su código fuente en su propia infraestructura en lugar de confiarlo a plataformas cloud como GitHub o GitLab. Es ligero, fácil de desplegar y funciona con recursos mínimos —por eso miles de organizaciones lo ejecutan en servidores propios, desde startups hasta grandes corporaciones—. Una vulnerabilidad de ejecución remota de código (RCE) en Gitea está siendo explotada activamente: los atacantes escanean internet en busca de instancias vulnerables, explotan el fallo para inyectar código malicioso a través de los hooks de Git, y despliegan payloads de minería de criptomonedas en los servidores comprometidos. El código fuente es el activo más valioso de una empresa de software: contiene la lógica de negocio, los secretos de despliegue, las claves de API y la propiedad intelectual completa. Un servidor Git comprometido no es solo un servidor más: es el repositorio de la ventaja competitiva de la organización. Y cuando un atacante consigue ejecutar código en el servidor Git, tiene acceso a todo el historial de commits, todas las ramas, todos los secretos que los desarrolladores han cometido —aunque sea por error— y todas las integraciones de CI/CD conectadas. Si tu empresa ejecuta Gitea, Gogs u otro servidor Git self-hosted, este aviso te afecta directamente. Cada hora sin parchear es una hora en la que tu código puede estar siendo robado o tu servidor minando para un atacante.

Por qué el self-hosting de Git es un objetivo de alto valor para los atacantes

El self-hosting de Git es una decisión estratégica: control total de los datos, independencia de proveedores cloud, cumplimiento normativo (datos que no pueden salir del país o de la organización). Pero el control total implica responsabilidad total. Un servidor Git self-hosted requiere el mismo nivel de protección que cualquier sistema crítico: parcheo puntual, monitorización, segmentación, hardening. Y la realidad es que muchos servidores Git self-hosted se despliegan y se olvidan: el desarrollador lo instaló en un servidor interno (o en un VPS) para el equipo, funciona correctamente, y nadie vuelve a pensar en su seguridad. Las actualizaciones se posponen —'si funciona, no lo toques'—, la exposición se olvida —el servidor quedó accesible desde internet para que los desarrolladores remotos pudieran acceder—, y la monitorización brilla por su ausencia. Los atacantes conocen este patrón y lo explotan sistemáticamente: escanean internet en busca de servidores Gitea con versiones vulnerables (identificables por sus respuestas características), lanzan el exploit, y obtienen acceso. El servidor que aloja el código fuente de la empresa se convierte en el servidor que ejecuta el código de los atacantes. La ironía es completa: el sistema diseñado para gestionar tu código ahora gestiona el suyo. Y el coste se paga en código robado, secretos filtrados y recursos de computación desviados a minería.

Así funciona el exploit: de la inyección de código en los hooks de Git al control del servidor

La explotación del RCE de Gitea es técnicamente directa. Fase 1: el atacante identifica instancias de Gitea vulnerables mediante escaneo —la versión del servidor es visible en las respuestas HTTP y en la página de login—. Fase 2: el exploit aprovecha una validación insuficiente en la gestión de hooks de Git: los hooks son scripts que se ejecutan automáticamente cuando ocurren eventos en el repositorio (push, merge, pull request). La vulnerabilidad permite a un atacante no autenticado —o con permisos mínimos— inyectar un hook malicioso en un repositorio. Fase 3: el hook malicioso se ejecuta en el servidor con los privilegios del proceso de Gitea. Fase 4: el atacante utiliza el hook para descargar y ejecutar un payload —en la campaña actual, un minero de criptomonedas—. Fase 5: el servidor comprometido comienza a minar, consumiendo CPU y energía, degradando el rendimiento para los desarrolladores legítimos. Fase 6: el atacante puede escalar: con acceso al servidor Git, busca secretos en los repositorios (claves de API, credenciales de despliegue), accede a las integraciones de CI/CD conectadas, y potencialmente pivota hacia la infraestructura de producción. El minero es el payload inicial —visible y ruidoso—, pero el acceso al código fuente y a los secretos es el botín real. Un atacante con el código fuente de tu aplicación puede encontrar vulnerabilidades que ningún escáner externo detectaría, copiar tu propiedad intelectual o vender el acceso a otros actores.

El impacto: robo de código fuente, credenciales de CI/CD y minería silenciosa en tu infraestructura

El impacto de un servidor Git comprometido se manifiesta en cuatro dimensiones. Primera: robo de propiedad intelectual —el código fuente completo, el historial de commits, la documentación interna—. Para una empresa de software, esto es perder la ventaja competitiva. El código puede venderse a competidores, copiarse para crear productos clónicos o analizarse para encontrar vulnerabilidades en los productos desplegados. Segunda: exposición de secretos —claves de API, tokens de despliegue, credenciales de bases de datos que los desarrolladores cometieron al repositorio por error o por comodidad—. Con estos secretos, el atacante accede a la infraestructura de producción, las bases de datos de clientes y los servicios cloud conectados. Tercera: compromiso del pipeline de CI/CD —si el servidor Git está conectado a un pipeline de integración continua, el atacante puede inyectar código malicioso en el pipeline, que se desplegará en producción con el siguiente build—. Es el ataque a la cadena de suministro desde dentro: el malware se distribuye a los clientes a través del propio proceso de build de la organización. Cuarta: consumo de recursos —la minería de criptomonedas degrada el rendimiento del servidor, aumenta la factura de electricidad y cloud, y puede provocar caídas de servicio—. El minero es el síntoma visible. El robo de código y secretos es la enfermedad que no se ve hasta semanas después, cuando el daño ya está hecho. La detección temprana es la única mitigación efectiva. Y la detección temprana requiere monitorización. Y la monitorización requiere que alguien haya configurado los logs antes del incidente. La mayoría de los servidores Git self-hosted no tienen ni lo uno ni lo otro.

Cómo MagnoSec audita servidores Git y plataformas de desarrollo

En MagnoSec, las auditorías de plataformas de desarrollo incluyen específicamente los servidores Git self-hosted. Verificamos la versión de Gitea, Gogs, GitLab CE u otros servidores Git y su estado de parcheo. Revisamos la exposición: ¿el servidor Git es accesible desde internet? ¿Debería serlo? ¿Los accesos remotos están protegidos con autenticación robusta y MFA? Analizamos los hooks de Git: ¿hay hooks inesperados en los repositorios? ¿Los hooks se auditan y revisan? Evaluamos la higiene de secretos en los repositorios: ¿los desarrolladores han cometido claves de API, contraseñas o tokens al repositorio? Herramientas de escaneo de secretos (gitleaks, truffleHog) pueden identificar secretos históricos en todo el historial de commits. Revisamos las integraciones de CI/CD: ¿el pipeline tiene acceso mínimo a los sistemas de producción? ¿Los secretos del pipeline están protegidos en un gestor de secretos o hardcodeados en los archivos de configuración? Y evaluamos la segmentación: el servidor Git debería estar en una red segregada, con acceso restringido a los desarrolladores y sin acceso directo a producción. El servidor Git es el punto de entrada perfecto para un ataque a la cadena de suministro: desde él, el atacante accede al código, a los secretos y al pipeline de despliegue. Protegerlo no es una tarea técnica más: es la protección de la propiedad intelectual y del proceso de distribución de software de la organización.

Mitigación urgente: parche de Gitea, revisión de hooks y segmentación de la plataforma de desarrollo

La mitigación es urgente y estructurada. Paso 1: actualizar Gitea a la última versión —el parche que corrige el RCE está disponible en los canales oficiales—. Si tu organización ejecuta una versión antigua, la actualización es prioridad máxima. Paso 2: revisar los hooks de todos los repositorios en busca de scripts inesperados. Un hook malicioso es la persistencia del atacante: puede sobrevivir a la actualización del servidor. Paso 3: revisar la exposición del servidor: si es accesible desde internet, restringir el acceso a VPN o a IPs específicas. Los desarrolladores remotos pueden acceder a través de VPN —no necesitan el servidor Git expuesto directamente—. Paso 4: escanear los repositorios en busca de secretos comprometidos y rotar todos los encontrados: claves de API, tokens, contraseñas. Un secreto cometido al repositorio es un secreto comprometido, aunque se elimine en un commit posterior —el historial lo conserva—. Paso 5: implementar monitorización del servidor: consumo de CPU (la minería es visible en las gráficas de uso), conexiones de red salientes inusuales, procesos desconocidos. Un servidor Git que de repente consume el 100% de CPU está minando para alguien. Paso 6: revisar el pipeline de CI/CD en busca de modificaciones no autorizadas. Si el atacante estuvo en el servidor Git, asume que el pipeline pudo ser comprometido. El código fuente es el activo más valioso de tu empresa de software. Protégelo con la misma seriedad con la que proteges a tus clientes. Porque en última instancia, proteger tu código es proteger a tus clientes: cada vulnerabilidad en tu código es una vulnerabilidad en sus sistemas.

Temas tratados

Gitea · RCE · Git · explotación activa · code injection · self-hosted · repositorios · CI/CD

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?