Git 2.56.1 corrige seis vulnerabilidades y una se activa al clonar un repositorio

Git 2.56.1 ya está disponible y corrige seis vulnerabilidades, y la más seria permite que un repositorio malicioso ejecute código en la computadora de quien lo clona con sus submódulos. El proyecto Git publicó las correcciones el 10 de noviembre, y GitHub, que distribuye Git en varias de sus herramientas, recomienda instalar Git 2.56.1 o la versión parcheada de la serie que cada quien use.

El fallo principal es CVE-2026-111760 y nace de un truncamiento de enteros en el manejo del índice de Git. Una ruta extremadamente larga puede pasar la validación con un nombre y escribirse en el disco con otro más corto, justo el tipo de comprobación con la que Git impide que un repositorio sobrescriba sus propios metadatos.

Con esa diferencia, un atacante puede reemplazar el archivo .git de un submódulo por un enlace simbólico hacia una carpeta con configuración o hooks maliciosos, esos programas que Git ejecuta en momentos concretos. Cuando Git usa esa carpeta durante la clonación recursiva, el código del atacante se ejecuta. La corrección rechaza las rutas de índice extremadamente largas antes de que su longitud pueda truncarse.

El aviso de seguridad de GitHub precisa dos condiciones: el repositorio trampa lo aloja el propio atacante, fuera de las plataformas habituales de código, y todo apunta a que solo se activa con la opción –recurse-submodules. Aun así, el aviso lo califica de gravedad alta, con 8,0 puntos sobre 10, porque clonar con submódulos es rutina diaria en equipos y servidores de compilación.

Los otros cinco fallos también tocan archivos y memoria

CVE-2026-113408 aprovecha la clonación de un repositorio vacío con el protocolo v2 de Git: el servidor anuncia el destino de HEAD sin que Git lo validara antes de guardarlo, y un nombre con componentes de escape puede hacer que una actualización posterior escriba fuera de la carpeta de referencias. La corrección valida ese destino y otros nombres de referencias del mismo protocolo.

CVE-2026-114467 corrompe la pila al quitar firmas GPG de un mensaje: Git daba por hecho que habría dos firmas como máximo, y una etiqueta con más de dos puede escribir más allá de un arreglo fijo. El resultado: corrupción de memoria y una posible denegación de servicio al fusionarla, un riesgo que alcanza también a los servicios de alojamiento que fusionan etiquetas por sus usuarios.

CVE-2026-114469 provoca una lectura de memoria fuera de los límites al aplicar parches binarios. Git rechaza los parches que superan cerca de 1 GiB, pero esa revisión miraba solo el tamaño entregado, y un parche binario comprimido y codificado puede expandirse por encima del tope y tumbar el programa. La corrección revisa también el tamaño declarado sin comprimir antes de procesarlo.

CVE-2026-105437 corrompe la memoria dinámica en fusiones muy grandes: el cálculo del tamaño del resultado puede desbordarse cuando se combinan muchos conflictos con un atributo conflict-marker-size elevado, Git reserva un búfer demasiado pequeño y escribe fuera de él.

No es un escenario teórico: los repositorios ya sirvieron de autopista a un gusano que se propagó entre proyectos de GitHub a través de npm, y cada copia de Git sin parche que procesa contenido ajeno queda expuesta a estos fallos.

CVE-2026-114466 abre acceso a archivos del sistema por los flujos de git fast-import. Las funciones rewrite-submodules-from y rewrite-submodules-to pueden leer archivos arbitrarios y dejar ver su contenido en mensajes de error, y la opción export-pack-edges puede crear archivos o añadir datos a los que ya existen. Desde esta versión, las tres quedan rechazadas dentro de un flujo de entrada, salvo que el operador active –allow-unsafe-features a sabiendas.

Actualizar Git y también las copias que traen las aplicaciones

La comprobación toma segundos con el comando git –version: si la versión instalada es anterior a la corregida de su serie, toca actualizar desde el sistema operativo o el distribuidor habitual de Git. Las series con mantenimiento vigente reciben su propio parche: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 y 2.50.2, sin que nadie tenga que saltar de serie.

Actualizar el Git del sistema no basta cuando una aplicación lleva el suyo. GitHub coordina las versiones corregidas de GitHub Desktop y de su aplicación de Copilot con el Git parcheado, y Codespaces y Actions también recibirán la versión corregida; los editores, clientes gráficos y entornos que integran Git quedan en la misma situación. Cada herramienta se actualiza por su propio canal, y conviene revisarlas una a una.

Los administradores tienen tarea extra: también deben actualizar las instalaciones que usa la automatización y los servicios que clonan o fusionan repositorios por los usuarios, porque varios fallos se activan justo al procesar contenido ajeno. GitHub ya aplicó las correcciones en github.com y en GitHub Enterprise Cloud.

Para GitHub Enterprise Server, las versiones corregidas son la 3.19.15, la 3.20.11, la 3.21.9 y la 3.22.4, y la recomendación para sus administradores es subir cuanto antes. Mientras el parche llega, el anuncio pide clonar solo de servidores de confianza, evitar las clonaciones recursivas de repositorios no confiables y no fusionar contenido ni etiquetas ajenos, ni procesar parches binarios o flujos de fast-import de origen dudoso.

Esas precauciones son medidas de contención, no un sustituto: el propio blog de GitHub aclara que no reemplazan la instalación de las correcciones. Git sostiene millones de proyectos y su momento más delicado es el primero, cuando el código de otro entra a la máquina. Dejarla para después mantiene abierto un riesgo que ya tiene parche publicado.

Fuente: GitHub