Git corrige CVE-2026-111760 que permite ejecución de código en submódulos durante clonación

Esta semana el proyecto Git publicó una corrección para una vulnerabilidad seria (CVE-2026-111760) que permite a un repositorio malicioso provocar la ejecución de código en la máquina que lo clona de forma recursiva junto con sus submódulos. El problema fue resuelto en Git 2.56.1, y se publicaron parches coincidentes para las ramas 2.50 a 2.55. Las correcciones evitan que rutas de archivo excesivamente largas pasen por controles de seguridad y luego sean recortadas al escribir en disco con un nombre que un atacante puede forzar a ser .git, lo que abre la puerta a la sustitución del archivo .git de un submódulo por un enlace simbólico hacia una ubicación controlada por el atacante. Una vez ahí, Git puede leer hooks o archivos de configuración de esa ubicación y ejecutar código arbitrario en momentos controlados por el flujo normal de Git.

Qué ocurrió (hechos confirmados): el proyecto Git sabe de un fallo de truncamiento entero en el manejo del índice que permite que una ruta extremadamente larga que debería ser bloqueada por las comprobaciones de seguridad, pase y luego sea escrita con un nombre más corto. Esa diferencia entre la comprobación y la escritura permite que el nombre resultante sea exactamente “.git”. Dado que Git trata de manera distinta un directorio .git y un archivo .git dentro de un submódulo recién clonado, un atacante puede aprovechar ese comportamiento para dejar un archivo .git que sea en realidad un enlace simbólico hacia una carpeta atacante que contenga hooks u otros archivos ejecutables. Git ejecuta hooks en puntos específicos (por ejemplo, post-checkout, pre-commit, etc.), por lo que la activación de esos hooks desde una ubicación controlada por el atacante es la ruta para la ejecución remota de código. La corrección entregada rechaza rutas tan largas antes de que exista la posibilidad de que el nombre sea truncado y pueda convertirse en .git. Estas correcciones están disponibles en la nota de lanzamiento de Git 2.56.1: https://github.com/git/git/releases/tag/v2.56.1.

Cómo funciona técnicamente (explicación): la vulnerabilidad es una condición de truncamiento de enteros en la lógica que valida y escribe entradas en el índice de Git. Durante una operación de clonación recursiva con submódulos, Git realiza comprobaciones de seguridad sobre las rutas que recibe del repositorio remoto. Si una ruta excede cierto tamaño, debería ser invalidada. Sin embargo, en este caso la comprobación se realiza con un valor que posteriormente se reduce (por truncamiento) cuando Git decide cómo crear el archivo en disco. Un nombre largo puede, tras truncarse, coincidir con “.git”. En submódulos recién creados, .git no es un directorio estándar sino un archivo que indica la ubicación del objeto de Git; ese archivo puede ser reemplazado por un enlace simbólico porque Git no espera un enlace en un submódulo recién clonado. Si el enlace apunta a una carpeta con hooks maliciosos o archivos de configuración, operaciones normales de Git posteriores pueden ejecutar ese código o leer configuraciones que cambien el comportamiento del cliente.

A quién afecta y cuál es el riesgo real (confirmado vs estimado): están afectados los equipos y servicios que usan versiones de Git anteriores a las corregidas y que realizan operaciones de clonación recursiva de repositorios de orígenes no completamente confiables. Los usuarios de clientes Git empaquetados por terceras aplicaciones (IDE, clientes gráficos, copys de Git dentro de apps) están potencialmente en riesgo si esas aplicaciones no actualizan la copia integrada. GitHub ha aplicado las correcciones en su infraestructura pública y en GitHub Enterprise Cloud, y ha informado que versiones de GitHub Enterprise Server y algunas aplicaciones de GitHub recibirán o ya han recibido actualizaciones; sin embargo, los mantenedores de Git para Windows y otras distribuciones tardaron en publicar binarios basados en 2.56.1 al momento del anuncio inicial. Esto significa que, hasta que cada plataforma o paquete distribuido actualice su copia de Git, el riesgo persiste para quienes no puedan o no quieran actualizar.

Es importante subrayar lo que no está confirmado públicamente: no hay en las notas oficiales una referencia inequívoca a explotación activa en la naturaleza (no se han presentado muestras públicas ni reportes forenses ampliamente verificados en el momento del parche). Dado el vector —repositorios que se clonan recursivamente— y la facilidad para incrustar submódulos, el riesgo de abuso es alto en teoría, especialmente contra desarrolladores y servidores que automatizan clonados y merges de proyectos de terceros. Servicios que ejecutan merges o comprobaciones en nombre de usuarios (por ejemplo, comprobaciones en servidores de integración continua o alojadores que ejecutan operaciones sobre código aportado por usuarios) son grupos que, según GitLab, pueden ser objetivos preferentes para exploits centrados en el comando git merge-tree.

Otras correcciones incluidas: además del CVE-2026-111760, la última ronda de parches corrige varios fallos con potencial de corrupción de memoria, lectura fuera de límites y abuso de funciones de importación rápida. Entre ellos están vulnerabilidades que permiten escritura fuera del árbol de referencias tras un clone vacío por protocolo v2, corrupciones por etiquetas con múltiples firmas GPG, parches binarios que exceden el límite y provocan lecturas fuera de límites, sobreescrituras de buffer en merges muy grandes con atributos conflict-marker-size modificados y la posibilidad de leer o crear archivos arbitrarios mediante ciertas características de git fast-import; estas últimas ahora están bloqueadas salvo que se invoque explícitamente --allow-unsafe-features. Los detalles técnicos y las mitigaciones adicionales fueron documentados por el proyecto Git y por equipos de alojamiento como GitHub y GitLab.

Qué debe hacer el lector ahora (acciones concretas): primero, compruebe la versión de Git en las máquinas que administre ejecutando Git localmente (por ejemplo, con git --version). Si usa una versión anterior a 2.56.1 o a las versiones parcheadas de las ramas 2.50–2.55, actualice cuanto antes desde la fuente oficial o el gestor de paquetes de su sistema. Si su organización utiliza instancias de GitHub Enterprise Server, compruebe las notas de versión para las versiones parcheadas (las versiones empresariales que ya han recibido las correcciones están listadas por GitHub) y aplique las actualizaciones de plataforma según el calendario de mantenimiento. Asimismo, si utiliza aplicaciones que incluyen su propia copia de Git (clientes de escritorio, IDEs, contenedores o apps de terceros), solicite o verifique con el proveedor cuándo incorporarán la versión corregida y aplique sus actualizaciones. GitHub también publica recomendaciones provisionales: clone solo desde orígenes que usted confíe y evite el uso de clonación recursiva en repositorios no verificados; no mezcle contenido o etiquetas de fuentes no fiables; y no procese parches binarios o flujos fast-import de fuentes que no sean de confianza. Para más detalles sobre la actualización de Git consulte la documentación oficial: https://docs.github.com/en/get-started/using-git/updating-git. Para entender cómo operan los hooks que pueden ser abusados, la documentación oficial de Git sobre hooks es útil: https://git-scm.com/docs/githooks.

Como medida adicional para administradores de servidores que aún no puedan actualizar, GitLab y otros han sugerido mitigaciones temporales para fallos concretos (por ejemplo, fijar conflict-marker-size en info/attributes de los repositorios o desactivar comprobaciones de merge-tree para repos no fiables). Estas medidas específicas corresponden a ciertas vulnerabilidades entre las corregidas y son aplicables en contextos donde la actualización inmediata no sea posible.

Resumen: la vulnerabilidad expone un vector práctico para ejecutar código contenido en submódulos maliciosos durante una clonación recursiva. La solución oficial ya está publicada; la responsabilidad inmediata recae en actualizar las copias de Git distribuidas en sistemas y servicios propios, y en evitar operaciones automatizadas sobre repositorios de procedencia dudosa hasta que todas las piezas del ecosistema (sistemas operativos, clientes y servicios) incorporen la corrección.