Michael JohnsonSi has actualizado Git en el terminal, el trabajo aún no ha terminado: algunas aplicaciones y entornos de compilación pueden ejecutar su propia copia. El 10 de noviembre de 2026, el proyecto Git publicó correcciones para seis vulnerabilidades, desde la ejecución de código durante la clonación recursiva hasta la corrupción de memoria al fusionar. Por eso hay que comprobar cada entorno que procese repositorios o su contenido, no solo el resultado de git --version en tu terminal.
Qué ha cambiado en la actualización
Las correcciones se incluyeron en Git 2.56.1 y se incorporaron a las ramas mantenidas: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 y 2.50.2. La actualización soluciona seis problemas en distintas áreas de Git: el manejo de rutas, enlaces, firmas, parches binarios, fusiones y flujos de importación. GitHub publicó el 10 de noviembre un análisis de las vulnerabilidades y la recomendación de actualizar; las notas de la versión Git 2.56.1 enumeran los CVE corregidos en esta serie.
En la práctica, hay que actualizar Git en tres lugares: los ordenadores de trabajo, los sistemas de automatización y las aplicaciones que incluyen su propia compilación de Git. Este último punto es fácil de pasar por alto: actualizar el paquete del sistema no cambia automáticamente la versión incluida en cada cliente o imagen de compilación.
Por qué merece atención la clonación recursiva
El caso más ilustrativo empieza al clonar recursivamente un repositorio no confiable. Debido al truncamiento de la longitud de la ruta, una ruta muy larga podía superar la validación con un nombre y luego guardarse en disco con uno más corto. En el escenario descrito por Git, esto permitía sustituir el archivo .git de un submódulo por un enlace simbólico a un directorio con una configuración o unos hooks maliciosos. En una interacción posterior, Git podía ejecutar el código indicado por el atacante.
Una consideración práctica importante: se requiere un repositorio preparado específicamente y la operación correspondiente. Los equipos que clonan habitualmente proyectos de fuentes externas con el parámetro --recurse-submodules deberían priorizar la actualización de los entornos de los clientes y de automatización. La corrección rechaza las rutas excesivamente largas antes de que se trunque su longitud.
Otros puntos en los que Git procesa datos no confiables
Otro problema se produce al clonar un repositorio vacío mediante Git protocol v2. El servidor podía enviar una referencia HEAD con un nombre de rama que contuviera componentes de recorrido de directorios; posteriormente, una operación de actualización de rama podía escribir un archivo fuera del directorio de referencias previsto. En las versiones corregidas, Git valida ese destino y otros nombres de referencias recibidos por el protocolo.
Otras vulnerabilidades afectaban a las operaciones de fusión y de parches. Al procesar firmas, una matriz de tamaño fijo suponía un máximo de dos; un mensaje preparado con más firmas podía provocar una escritura fuera de los límites de la matriz y corromper la memoria. Al aplicar un parche binario, la comprobación del tamaño tenía en cuenta la representación original, aunque los datos comprimidos pueden expandirse hasta ocupar mucho más espacio. Ahora Git comprueba el tamaño descomprimido declarado antes de procesarlos.
Las fusiones de gran tamaño también podían provocar un desbordamiento al calcular el búfer necesario y, después, una escritura fuera de sus límites. Esto afecta también a los servicios de alojamiento y a las aplicaciones que fusionan contenido no confiable. Por último, se han impuesto límites a los comandos de entrada en tres funciones de git fast-import: rewrite-submodules-from y rewrite-submodules-to podían leer archivos arbitrarios, y export-pack-edges podía crear archivos o añadir datos a archivos existentes. Ahora estas funciones se bloquean salvo que se especifique explícitamente la opción --allow-unsafe-features; debe usarse únicamente con un generador de flujos de confianza.
Dónde buscar copias independientes de Git
Los desarrolladores pueden empezar por inventariar desde dónde se ejecuta Git. Comprueba la versión en el terminal y utiliza la función de actualización habitual de los IDE y clientes Git de escritorio. Después revisa las imágenes de CI, los contenedores, los ejecutores y las tareas de servidor que clonan, fusionan, aplican parches binarios o ejecutan fast-import. Tener una versión reciente de Git en el equipo anfitrión no garantiza que la aplicación utilice esa misma instalación.
En las organizaciones conviene revisar no solo las imágenes de origen, sino también los entornos de trabajo ya desplegados: un ejecutor persistente o un servicio interno podría conservar un binario antiguo después de actualizar la imagen base. Para GitHub Enterprise Server, GitHub indica que las versiones corregidas son 3.19.15, 3.20.11, 3.21.9 y 3.22.4. La empresa informó que ya había desplegado las correcciones en github.com y GitHub Enterprise Cloud, incluidas las opciones con alojamiento de datos. Las versiones de GitHub Desktop y GitHub Copilot app con el Git corregido se están coordinando; también están pendientes las versiones corregidas para Codespaces y GitHub Actions.
Cómo reducir el riesgo antes de actualizar
Si no puedes instalar la corrección de inmediato, limita temporalmente las operaciones con datos no confiables: clona repositorios solo desde servidores de confianza, evita la clonación recursiva de proyectos no verificados, no fusiones su contenido y no apliques parches binarios ni flujos de fast-import procedentes de ellos. Estas medidas reducen la exposición a los escenarios vulnerables específicos, pero no sustituyen la actualización.
La conclusión práctica es sencilla: hay que buscar la corrección de Git allí donde el programa realmente lo ejecuta. El comando del terminal es solo uno de esos lugares; los clientes de desarrollo, CI y los servicios que procesan repositorios requieren una comprobación aparte.
