GitHub verifica commits con hashes manipulables

La confianza en los commits firmados de Git constituye uno de los pilares fundamentales de la seguridad del desarrollo moderno. Miles de proyectos de código abierto y organizaciones utilizan firmas criptográficas para verificar la autenticidad del código y garantizar que las modificaciones provienen de desarrolladores legítimos. Sin embargo, una reciente investigación ha demostrado que una de las suposiciones más extendidas dentro del ecosistema Git podría ser incorrecta: un hash de commit firmado no representa necesariamente un identificador único e inmutable de ese contenido.

El hallazgo, presentado por Jacob Ginesin, estudiante de doctorado de la Universidad Carnegie Mellon y auditor criptográfico en Cure53, expone una debilidad que afecta directamente la forma en que plataformas como GitHub interpretan y validan las firmas digitales de los commits.

Aunque el problema no permite modificar el código sin ser detectado, sí abre la puerta a escenarios donde un mismo commit puede existir bajo múltiples hashes diferentes, todos ellos considerados como "Verified" por GitHub.

¿Qué descubrió la investigación?

El estudio demuestra que cualquier persona puede tomar un commit firmado válidamente y generar otro commit con exactamente el mismo contenido:

• Los mismos archivos.
• El mismo autor.
• La misma fecha.
• La misma firma válida.

La única diferencia será el hash del commit, que cambiará completamente pese a que el contenido permanezca intacto.

Desde la perspectiva de un revisor humano, ambos commits son prácticamente indistinguibles. GitHub mostrará la insignia Verified en ambos casos, lo que puede inducir a pensar que representan exactamente el mismo objeto criptográfico cuando en realidad poseen identificadores diferentes.

¿Por qué representa un problema de seguridad?

El verdadero riesgo no reside en alterar el contenido del código.

De hecho, la investigación deja claro que no es posible utilizar esta técnica para introducir código malicioso bajo una firma válida.

El problema aparece porque numerosos sistemas de seguridad consideran el hash del commit como un identificador permanente.

Entre ellos destacan:

• listas de bloqueo (blocklists);
• sistemas de deduplicación;
• registros de procedencia (provenance);
• compilaciones reproducibles;
• auditorías de cadena de suministro;
• herramientas DevSecOps;
• plataformas de análisis automatizado.

Si una organización bloquea un commit utilizando exclusivamente su hash, un atacante podría reconstruir exactamente el mismo commit con un hash completamente distinto pero igualmente firmado y verificado.

Como consecuencia, la nueva versión evitaría automáticamente la lista de bloqueo.

Un impacto potencial sobre la cadena de suministro de software

El descubrimiento adquiere especial relevancia en un momento donde la seguridad de la Software Supply Chain se ha convertido en una prioridad para empresas y gobiernos.

Cada vez más herramientas utilizan hashes de commits como referencia permanente para:

• validar dependencias;
• generar Software Bill of Materials (SBOM);
• registrar evidencia criptográfica;
• garantizar la reproducibilidad de compilaciones;
• certificar versiones de software.

Si dichos hashes dejan de ser únicos para un mismo contenido firmado, parte de esas garantías pueden debilitarse.

La causa: la maleabilidad de las firmas digitales

El origen del problema se encuentra en una propiedad conocida como malleabilidad criptográfica.

Git calcula el hash del commit incluyendo absolutamente todos los datos almacenados en el objeto, incluidos los bytes exactos de la firma criptográfica.

Sin embargo, diversas tecnologías de firma permiten múltiples representaciones binarias perfectamente válidas de una misma firma.

Aunque todas verifican correctamente la autenticidad del commit, producen distintos bytes internos.

Al cambiar esos bytes:

• cambia el hash del commit;
• el contenido permanece idéntico;
• la firma sigue siendo válida.

En otras palabras, el identificador cambia sin que cambie el código.

Tres técnicas distintas para modificar el hash

La investigación demuestra tres métodos diferentes capaces de generar nuevos hashes válidos.

1. Claves ECDSA

En las firmas ECDSA existe una conocida propiedad matemática que permite sustituir el valor s por n − s.

Ambas firmas son completamente válidas desde el punto de vista criptográfico.

Git acepta ambas variantes y GitHub continúa mostrando la insignia Verified.

2. Claves RSA y EdDSA

En OpenPGP es posible añadir campos adicionales dentro de la sección denominada "no hashada".

Estos campos no están protegidos por la firma.

Su incorporación modifica los bytes del commit y genera un hash distinto, aunque la firma siga siendo perfectamente válida tanto para Git como para GitHub.

3. Firmas S/MIME (X.509)

El tercer método afecta a S/MIME.

Consiste en modificar determinados campos de longitud dentro de la estructura DER de la firma utilizando una codificación alternativa.

Lo llamativo es que una comprobación estricta mediante gpgsm rechaza estas firmas, mientras que GitHub continúa aceptándolas como verificadas.

GitHub no normaliza las firmas

Según el estudio, el comportamiento de GitHub constituye el verdadero origen del problema.

Antes de verificar una firma, la plataforma no realiza un proceso de normalización (canonicalización).

Esto implica que acepta múltiples representaciones distintas de una misma firma sin convertirlas previamente a una forma canónica.

Como resultado:

• acepta firmas ECDSA no canónicas;
• mantiene campos OpenPGP innecesarios;
• valida determinadas codificaciones S/MIME que otras herramientas rechazan.

Además, GitHub almacena el estado Verified asociado al hash concreto del commit y no vuelve a verificarlo posteriormente.

Incluso si la clave criptográfica utilizada termina siendo revocada, el commit continúa mostrando la insignia de verificación.

El efecto dominó sobre el historial Git

El problema no afecta únicamente a un commit aislado.

Cada commit almacena el hash de su commit padre.

Cuando un commit cambia de hash debido a esta técnica, todos los commits descendientes deben recalcular sus propios hashes para mantener la coherencia del historial.

Ginesin denomina este fenómeno como "hash chain malleability" o maleabilidad de la cadena de hashes.

La herramienta publicada junto al artículo automatiza precisamente este proceso, reconstruyendo todo el historial sin modificar el contenido del código.

No se trata de una colisión criptográfica

Uno de los aspectos más importantes del estudio es aclarar qué no está ocurriendo.

Esta investigación:

• no rompe SHA-1;
• no rompe SHA-256;
• no encuentra colisiones;
• no compromete la criptografía utilizada por Git.

En realidad sucede exactamente lo contrario.

No existen dos contenidos diferentes con el mismo hash.

Lo que existe es un mismo contenido que puede representarse mediante varios commits criptográficamente válidos, cada uno con un hash distinto.

Un problema conocido en otras tecnologías

La investigación recuerda inmediatamente un problema que sufrió Bitcoin durante sus primeros años.

Las transacciones firmadas mediante ECDSA permitían modificar el valor s sin alterar la validez de la firma.

El resultado era un nuevo identificador de transacción (Transaction ID) pese a que la operación fuera exactamente la misma.

Bitcoin solucionó este problema imponiendo la codificación Low-S y posteriormente mediante SegWit, que separó las firmas del identificador principal de la transacción.

La recomendación del estudio sigue exactamente esa misma filosofía: normalizar las firmas antes de confiar en el hash generado.

Relación con los recientes ataques a GitHub Actions

El trabajo también hace referencia a varios incidentes recientes relacionados con GitHub Actions, incluyendo los ataques contra tj-actions/changed-files en 2025 y Trivy Action en 2026.

Tras aquellos incidentes, la recomendación general consistía en fijar las dependencias utilizando el hash completo del commit en lugar de etiquetas móviles.

Esa recomendación continúa siendo válida.

Sin embargo, la nueva investigación introduce un matiz importante.

Una firma válida demuestra quién firmó el commit, pero no garantiza que el hash del commit sea un identificador único del contenido.

¿Quién debe solucionar este problema?

La investigación deja claro que los desarrolladores no necesitan modificar sus repositorios.

Tampoco deben abandonar la práctica de fijar dependencias mediante hashes completos.

La responsabilidad recae principalmente sobre las plataformas que verifican firmas, especialmente GitHub y otras forjas de código.

La solución propuesta consiste en aplicar un proceso de canonicalización antes de verificar cualquier firma criptográfica.

Asimismo, las herramientas de seguridad que realizan:

• bloqueos por hash;
• deduplicación;
• registros de procedencia;
• validaciones de integridad;

deberían verificar primero la firma y convertirla a una representación canónica antes de confiar en el hash del commit.

Los sistemas que además verifican un hash independiente del contenido descargado —como ocurre con determinadas derivaciones de salida fija de Nix— mantienen una protección adicional frente a este tipo de ataques.

Estado actual del problema

Según explica Jacob Ginesin en su artículo, el problema fue comunicado inicialmente a GNU y al proyecto Git durante enero, mientras que GitHub recibió el informe en marzo.

Hasta la publicación del trabajo académico en arXiv, ninguna de las plataformas implicadas había implementado una solución.

El caso más evidente continúa siendo el soporte de S/MIME, donde GitHub sigue aceptando firmas que herramientas locales más estrictas consideran inválidas.

Aunque el descubrimiento no representa una vulnerabilidad crítica capaz de introducir código malicioso sin autorización, sí obliga a replantear una suposición ampliamente aceptada dentro del ecosistema del desarrollo seguro: un commit firmado no siempre posee un identificador único e inmutable. En un contexto donde la seguridad de la cadena de suministro depende cada vez más de la confianza depositada en los hashes de Git, este hallazgo supone un importante recordatorio de que la validación criptográfica debe ir acompañada de procesos de normalización adecuados para evitar interpretaciones erróneas de la integridad del software.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login