Fallo en Gogs permite envenenar repositorios y cadenas de suministro de software

Una vulnerabilidad catastrófica sin parche oficial permite a cualquier atacante sobrescribir silenciosamente archivos críticos en servidores Git autoalojados.

La infraestructura de desarrollo de software de código abierto se enfrenta a un nuevo nivel de peligro. Este 11 de marzo de 2026, se reporta el descubrimiento de una falla de seguridad de severidad máxima (con una puntuación CVSS 3.1 perfecta de 10.0) en Gogs, un popular servicio de Git autoalojado.

La vulnerabilidad, rastreada como CVE-2026-25921, permite a los actores maliciosos sobrescribir objetos de Almacenamiento de Archivos Grandes (LFS) en secreto, creando un riesgo devastador para ataques directos a la cadena de suministro de software. Hasta el momento de la divulgación, el fallo afecta a las versiones 0.14.1 y anteriores de Gogs, y actualmente no existe un parche oficial disponible.


Los Dos Errores Fatales de Diseño

La raíz de este problema crítico se encuentra en la forma en que Gogs diseñó y maneja su arquitectura de almacenamiento LFS:

  • Falta de aislamiento de almacenamiento: Gogs guarda todos los objetos LFS subidos en una única ubicación compartida, sin aislarlos por repositorio. Dado que la ruta de almacenamiento no incluye una ID de repositorio única, todos los proyectos alojados en la instancia comparten el mismo grupo de archivos centralizado.
  • Ausencia de verificación de hashes: Cuando un usuario sube un archivo LFS, el sistema falla por completo en verificar si el contenido real del archivo coincide con su hash criptográfico SHA-256 declarado (también conocido como OID).

Un Ataque Silencioso y Devastador

Debido a la ausencia de estos controles de seguridad básicos (CWE-345), la explotación requiere una complejidad de ataque baja, cero privilegios especiales y ninguna interacción por parte del usuario.

Se detalló que un atacante solo necesita conocer el hash SHA-256 de un archivo LFS objetivo. Luego, el delincuente simplemente sube un archivo manipulado (como un instalador de software con una puerta trasera) a su propio repositorio, pero afirmando falsamente que tiene el hash del archivo de la víctima.

El servidor Gogs asume erróneamente que la carga es un reintento rutinario del cliente y sobrescribe de forma mecánica y ciega el archivo original y legítimo en la base de datos de almacenamiento compartido.

El resultado es una manipulación completamente indetectable. Las víctimas, ya sean desarrolladores legítimos o sistemas automatizados de compilación, descargarán el objeto LFS de la página web de Gogs sin ver ninguna advertencia, error o alerta de que el archivo ha sido corrompido.


Medidas de Contención de Emergencia

Dado que los desarrolladores de Gogs aún no han publicado una versión corregida (la cual requerirá que el sistema verifique matemáticamente todos los objetos antes de escribirlos en el disco), los administradores deben tomar medidas manuales de inmediato:

  • Restringir permisos: Se debe limitar estrictamente la creación de cuentas y los permisos de carga de LFS únicamente a usuarios internos de altísima confianza para evitar que actores no autorizados sobrescriban archivos.
  • Controles de integridad manuales: Es vital implementar scripts de monitoreo externos para verificar periódicamente que los hashes SHA-256 reales de los archivos LFS críticos en el disco del host coincidan exactamente con sus valores esperados en la base de datos.

Related Post