Ing. Calogero Bono
El proyecto Git ha lanzado la versión 2.56.1 para corregir seis vulnerabilidades de seguridad. Una de ellas permite ejecutar código ajeno al clonar de forma recursiva un repositorio malicioso. Las demás tienen que ver con escrituras en archivos no previstos y daños en la memoria durante merges y parches binarios. Importa porque Git está dentro de editores, herramientas de automatización y servidores de muchas empresas, y hay que actualizarlo en todas partes.
Algunos términos, antes de entrar en los hechos. Clon recursivo es la copia de un repositorio junto con sus submódulos. Un submódulo es un repositorio dentro de otro repositorio. Los hooks son programas que Git ejecuta en momentos concretos. El path traversal usa rutas con componentes especiales para salir de la carpeta permitida. El CVE es el código que identifica una vulnerabilidad pública.
¿Qué ha lanzado el proyecto Git?
Según el blog de GitHub, las correcciones están en la versión 2.56.1. También existen backports para las series 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 y 2.50.2.
GitHub recomienda pasar a la 2.56.1 o a la versión corregida de tu serie, y actualizar también las aplicaciones que incluyen una copia de Git. Si leíste nuestro recorrido sobre Git para desarrolladores, sabrás lo extendida que está la herramienta en los flujos de trabajo diarios.
¿Cómo se llega a ejecutar código con un clon recursivo?
El fallo está catalogado como CVE-2026-111760. Es un truncamiento de entero en la gestión del índice. Una ruta muy larga supera la comprobación de Git, pero después se escribe en disco con un nombre más corto, que un atacante puede hacer que sea .git.
Así se sustituye el archivo .git de un submódulo por un enlace simbólico hacia una carpeta con hooks o configuraciones hostiles. Como explica The Hacker News, Git se niega a reemplazar una carpeta .git por un enlace simbólico, pero en un submódulo recién clonado .git es un archivo. Cuando Git usa esa carpeta, el código del atacante puede arrancar.
La corrección descarta las rutas demasiado largas antes de que la longitud se trunque.
¿Cuáles son las otras cinco vulnerabilidades?
- CVE-2026-113408. Al clonar un repositorio vacío con el protocolo v2, un servidor malicioso puede indicar un nombre con path traversal. Con el backend de referencias en archivos, una actualización posterior puede escribir fuera de la carpeta prevista.
- CVE-2026-114467. Una etiqueta con más de dos firmas GPG, si se fusiona con merge, corrompe la pila y puede provocar un bloqueo del servicio.
- CVE-2026-114469. Un parche binario pequeño pero que se expande mucho evita el límite de aproximadamente 1 GiB y hace que Git se bloquee.
- CVE-2026-105437. Un merge muy grande, con muchos conflictos y un atributo conflict-marker-size elevado, corrompe la memoria heap.
- CVE-2026-114466. Tres funciones de fast-import pueden leer archivos arbitrarios o crear y añadir datos en ellos.
En el último caso, Git ahora rechaza esas funciones en los flujos de entrada, salvo con la opción --allow-unsafe-features, que solo debe usarse si confías en el programa que genera el flujo.
¿Quién corre más riesgo y qué ha actualizado GitHub?
Están más expuestos los servidores que hacen merges en nombre de los usuarios. GitLab, que ha asignado el CVE-2026-105437, señala git merge-tree como objetivo probable, porque un servidor puede usarlo para comprobar si una merge request es fusionable. El atributo se define en un archivo .gitattributes del repositorio, así que quien puede abrir una solicitud podría activar el fallo.
GitHub afirma haber corregido github.com y GitHub Enterprise Cloud. Para Enterprise Server se necesitan las versiones 3.19.15, 3.20.11, 3.21.9 o 3.22.4. GitHub Desktop, la app de Copilot, Codespaces y Actions recibirán Git corregido.
Límites que conviene conocer
Las fuentes no informan de exploits activos ni de un nivel de gravedad para cada CVE. No sabemos si alguien ya ha aprovechado los fallos. Según The Hacker News, el martes a las 19.09 UTC Git for Windows todavía no tenía una versión basada en la 2.56.1, así que los plazos para esa plataforma pueden cambiar. También faltan los plazos para GitHub Desktop, Copilot, Codespaces y Actions.
Qué cambia para quien trabaja con lo digital
El primer paso es inventariar dónde se ejecuta Git. No solo en tu ordenador, sino en los programas que incluyen una copia propia, en los sistemas de integración continua y en los servicios que procesan repositorios ajenos. Quien gestiona servidores con repositorios de terceros debe actualizar también las automatizaciones. Si no puedes hacerlo de inmediato, el workaround de GitLab consiste en añadir conflict-marker-size=7 al archivo info/attributes de cada repositorio, o desactivar esas comprobaciones en repositorios no confiables. Quien confía en un alojamiento con actualizaciones de seguridad gestionadas delega parte de este trabajo.
Nuestra opinión
Son seis vulnerabilidades, pero el mensaje es uno. Hay que tratar Git como un software que procesa entradas no confiables, no como una simple herramienta local. Clonamos, fusionamos y aplicamos parches de fuentes externas sin pensarlo, y las automatizaciones lo hacen por nosotros. El riesgo más concreto está en las copias de Git ocultas dentro de otros programas, que nadie actualiza hasta que se acuerda. Las precauciones que enumera GitHub sirven como parche provisional, pero siguen siendo parches. Y si hablamos de herramientas que usan Git de forma intensiva, escribimos sobre GitHub Rubicon, donde el tema de la entrada no confiable pesa todavía más.
Preguntas frecuentes
¿Qué versión de Git debo instalar?
Instala la 2.56.1 o la versión corregida de tu serie, es decir, la 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 o 2.50.2. Actualiza también las aplicaciones que incluyen una copia propia de Git.
¿Basta con no clonar repositorios desconocidos?
Ayuda, pero no es suficiente. GitHub indica que solo se clone desde servidores de confianza y que se eviten clones recursivos, merges y parches binarios de fuentes no confiables, aclarando que estas precauciones no sustituyen las actualizaciones.
¿Cuál es la vulnerabilidad más grave?
Las fuentes no ofrecen una clasificación. La que permite ejecutar código durante un clon recursivo es el CVE-2026-111760, y es en la que se concentra la cobertura.
¿Git for Windows ya está actualizado?
Todavía no, según la última comprobación de The Hacker News. El martes a las 19.09 UTC no había una versión basada en la 2.56.1 entre las etiquetas de lanzamiento.
¿Los usuarios de GitHub tienen que hacer algo?
Depende. GitHub ya ha corregido github.com y las versiones Enterprise Cloud. Quien usa Enterprise Server debe pasar a una de las versiones indicadas, y quien usa herramientas locales debe actualizar Git.
Las actualizaciones de Git que conviene seguir en los próximos días
La corrección existe, pero su distribución va por partes. Conviene seguir a quienes todavía tienen que publicar su versión.
- Revisa cuándo Git for Windows publica una build basada en la 2.56.1 y actualiza enseguida.
- Comprueba cuándo llegan las versiones corregidas de GitHub Desktop, de la app de Copilot, de Codespaces y de Actions.
- Si gestionas un servidor de alojamiento de código, valora el workaround de GitLab hasta que puedas actualizar.
