Git 2.56.1 corrige seis vulnerabilidades, y sus runners de CI lo necesitan más que su portátil

El 10 de noviembre, el proyecto Git publicó Git 2.56.1, además de versiones parcheadas para las líneas de mantenimiento anteriores: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 y 2.50.2. Entre todas cierran seis CVE: CVE-2026-111760, CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 y CVE-2026-114466. El proyecto lo describe como un conjunto de versiones coordinadas de corrección de seguridad y pide actualizar lo antes posible. Los fallos fueron descubiertos por Luke Martin y pwn2addr.

El que importa es CVE-2026-111760, clasificado como alto (CVSS 8,0) en el aviso de seguridad del proyecto. En resumen: el código del índice de Git tiene un error de truncamiento de enteros. Una ruta muy larga se comprueba con su nombre completo, pero acaba en disco con uno más corto. Un atacante puede aprovechar esa discrepancia para sustituir el archivo .git de un submódulo por un enlace simbólico a un directorio que él controla, lleno de su propia configuración o de hooks. Los hooks son código. Por tanto, un clonado recursivo del repositorio equivocado puede terminar con código ajeno ejecutándose en su máquina. El aviso indica que se cree que solo es explotable cuando se usa --recurse-submodules.

GitHub ya ha parcheado github.com, GitHub Enterprise Cloud y Enterprise Cloud con residencia de datos. Si usted aloja GitHub Enterprise Server, las versiones corregidas son 3.19.15, 3.20.11, 3.21.9 y 3.22.4.

La puntuación subestima el riesgo para la mayoría de los equipos

Si lee el vector CVSS, quizá se tranquilice un poco: complejidad de ataque alta, privilegios bajos, interacción del usuario requerida. En un portátil de desarrollo es razonable: alguien tiene que clonar de forma recursiva un repositorio hostil.

Pero piense en quién ejecuta realmente git clone en su organización. Sobre todo no son personas. Son los runners de CI, cientos de veces al día, sin nadie mirando y con claves de despliegue y credenciales cloud en variables de entorno. «Interacción del usuario requerida» significa poco cuando el usuario es un archivo YAML.

Cuando desarrollamos aplicaciones cloud-native para clientes empresariales, el Git que importa rara vez es el del portátil de alguien. Es el que viene en una imagen base de Docker elegida hace año y medio, el de un runner autoalojado, el de un contenedor de despliegue. Actualizar paquetes en su Mac no toca nada de eso. Por nuestro trabajo con PHP y Docker, mi apuesta sincera es que la mayoría de los equipos tiene tres o cuatro versiones distintas de Git en sus rutas de compilación y despliegue, y no sabría enumerarlas sin ir a comprobarlo.

Los equipos móviles tienen su propia versión del problema. En nuestros proyectos nativos de iOS y Android, los submódulos siguen siendo una forma habitual de incorporar SDK compartidos, bibliotecas nativas o un kit de UI interno. Las máquinas de compilación suelen ser Macs de larga vida que nadie reinstala desde hace siglos. Además, el proyecto Git indica expresamente que se actualice cualquier aplicación que incluya su propia copia de Git, lo que abarca bastantes IDE y clientes de escritorio. Actualizar el Git del sistema no los arregla.

En el plano de la seguridad, esto encaja con un patrón que vemos una y otra vez. En nuestros pentests, el pipeline de compilación suele ser la vía de entrada más fácil, porque confía en cosas que nadie dejaría acercarse a producción: el fork de un contratista, un proyecto de ejemplo de un proveedor, una dependencia de código abierto incorporada como submódulo. La gente olvida que los hooks son ejecutables. Los atacantes no.

Tengo sentimientos encontrados. Seis CVE de golpe, en una herramienta tan veterana y de tanta confianza, resultan algo inquietantes. A la vez, unas correcciones coordinadas en siete líneas de versiones son exactamente el mantenimiento aburrido y competente que uno quiere de un proyecto del que depende todo el mundo. El parche ya está disponible. Lo difícil queda de nuestro lado: encontrar todas las copias.

Qué haría esta semana

1. Haga un inventario de todos los binarios de Git, no solo los de los portátiles. Ejecute git --version dentro de sus imágenes de CI, Dockerfiles, runners autoalojados y Macs de compilación. Debe tener la 2.56.1 o la versión parcheada de su serie (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 o 2.50.2).
2. Reconstruya las imágenes base a propósito. No dé por hecho que la próxima reconstrucción programada incluirá un Git corregido. Compruebe la versión en la imagen ya construida.
3. Si aloja GitHub Enterprise Server, actualice a 3.19.15, 3.20.11, 3.21.9 o 3.22.4.
4. Busque en la configuración de sus pipelines los checkouts recursivos de submódulos. Donde el repositorio padre o algún submódulo no esté totalmente bajo su control, desactive la recursividad hasta que el runner esté parcheado.
5. Mientras no esté todo actualizado, siga las recomendaciones provisionales del proyecto: clone solo desde servidores de confianza, evite clonados recursivos de cualquier cosa no confiable, y tenga cuidado al fusionar contenido o etiquetas externos, aplicar parches binarios o alimentar flujos fast-import de fuentes que no controle.

Para nuestros clientes suizos con requisitos de cumplimiento normativo, añadiría un sexto paso: documente qué parcheó y cuándo. A los auditores les gustan las pruebas, y para un parche tan extendido le conviene tenerlas listas en lugar de reconstruirlas después. Tratamos este tipo de higiene de pipelines cuando montamos infraestructura de compilación y despliegue, y surge constantemente en nuestras revisiones de seguridad.

Si no está seguro de cuántas copias de Git se esconden en su pipeline de compilación, hablemos.