Una nueva investigación muestra que el hash de un compromiso Git firmado no es el nombre único que gran parte del mundo del software supone que es. Dada cualquier confirmación firmada, alguien sin la clave de firma puede crear una segunda confirmación con los mismos archivos, autor y fecha, y una firma válida, GitHub aún marca “Verificado”.
Todo lo que un crítico comprobaría coincide. El hash del compromiso no. Esto es importante porque muchos sistemas tratan un hash de confirmación verificado como un nombre único y permanente para su contenido.
Aquí está el fallo concreto: bloquear una confirmación incorrecta mediante su hash, y un atacante puede volver a enviar el mismo contenido bajo un hash nuevo y aún “verificado” que su lista de bloqueo nunca ha visto. La deduplicación, los registros de procedencia y los registros de compilación reproducible que codifican el hash heredan el mismo punto débil.
Un espejo comprometido u hostil puede entregar a los clonadores confirmaciones firmadas válidamente cuyos hashes difieren de los de la forja canónica.
Lo que esto no es es una forma de pasar un código diferente por una verificación de firma. Los archivos son idénticos en cada copia, por lo que un hash que fijó aún obtiene exactamente el contenido que esperaba o falla.
No hay CVE ni avisos de proveedores, y no hay nada que cambiar en su propio repositorio: la falla está en cómo una falsificación decide qué significa “Verificado”, y la solución pertenece al lado de la falsificación.
El trabajo proviene de Jacob Ginesin, estudiante de doctorado en la Universidad Carnegie Mellon y auditor criptográfico en Cure53. Su artículo de cinco páginas, publicado en arXiv el 2 de julio, viene con una herramienta pública que ejecuta los tres ataques, además de dos repositorios de demostración donde los commits maltratados aún aparecen como “Verificados” en GitHub.
Debido a que cada confirmación nombra a su padre mediante hash, maltratar una confirmación fuerza nuevos hashes en las confirmaciones que se encuentran encima de ella. La herramienta reescribe esa cadena para mantenerla consistente. Sin embargo, un descendiente firmado pierde su propia insignia en el momento en que cambia su puntero principal. Ginesin llama al efecto “maleabilidad de la cadena hash“.
La causa es la maleabilidad característica. El hash de una confirmación se calcula sobre todo lo que contiene, incluidos los bytes sin procesar de la firma en su encabezado. Muchas firmas se pueden reescribir en una forma diferente pero aún válida, y cambiar esos bytes cambia el hash sin tocar una línea de código.
Las tres rutas cubren todos los esquemas GPG que GitHub verifica, además de S/MIME:
- Las claves de la ECDSA son: voltea la firma con una pieza clásica de álgebra de curva elíptica (convierte el valor s en n – s). Ambas formas son válidas. Esto pasa un compromiso de verificación de git local y obtiene una insignia de GitHub.
- Claves RSA y EdDSA: agregue un campo adicional ignorado a la sección “sin hash” de la firma, la parte que la firma deliberadamente no cubre. La firma aún se verifica, pero los bytes de la confirmación y su hash cambian. Tanto Local como GitHub lo aceptan.
- Teclas S/MIME (X.509): reescriba un campo de longitud en la estructura DER de la firma en una forma más larga y no estándar. Una verificación local estricta (a través de gpgsm) lo rechaza, pero GitHub aún lo marca como “Verificado”, y la herramienta reproduce ambas cosas.
Las tres rutas comparten un habilitador: GitHub no normaliza una firma antes de verificarla. Sin codificación estricta en S/MIME, sin eliminación de esos campos OpenPGP y los valores ECDSA no canónicos se aceptan tal cual.
Luego, GitHub archiva un registro “Verificado” contra cada hash de confirmación y no lo vuelve a verificar, por lo que una confirmación permanece “Verificada” incluso después de que se revoca su clave de firma. Empuje un original y su gemelo a dos ramas, y la vista de comparación de GitHub los tratará como historias divergentes, una confirmación por delante y otra por detrás, a pesar de archivos idénticos.
Para ser claros: esto no es una colisión de hash. No rompe SHA-1 o SHA-256, y no tiene nada que ver con el cambio de Git a SHA-256. Nadie obliga a dos confirmaciones diferentes a compartir un hash; es al revés, una confirmación que se puede escribir de muchas maneras válidas, cada una con su propio hash.
El movimiento central es antiguo. Bitcoin luchó exactamente contra la misma simetría ECDSA hace años, cuando cualquiera podía invertir el valor s en la firma de una transacción y cambiar el ID de la transacción sin la clave del propietario. La solución fue aceptar solo el formulario “low-S” y luego sacar las firmas del ID con SegWit.
Las correcciones del artículo riman con eso: canonicalizar la codificación antes de confiar en el hash. Una lección conocida, no una criptografía nueva y exótica.
El documento también conecta esto con los recientes secuestros de etiquetas de GitHub Actions, los ataques tj-actions/changed-files de 2025 y los ataques trivy-action de 2026 (cita este último). Después de eso, el consejo fue simple: fijar un hash de confirmación completo, no una etiqueta móvil. Ese consejo sigue siendo válido.
La fijación detuvo esos ataques y esta investigación no cambia eso. Su punto es más estrecho. En el caso Trivy, las confirmaciones maliciosas se destacaron porque no podían firmarse válidamente. Esta es una advertencia contra confiar demasiado en esa indicación: una firma válida prueba quién firmó una confirmación, pero no hace que el hash de la confirmación sea un nombre único para lo que contiene.
Entonces ¿quién tiene que hacer algo? No el desarrollador que fija una acción o un módulo; un hash fijado aún obtiene el código correcto. El trabajo es para las fraguas. El periódico dice que deberían canonicalizar las firmas antes de confiar en ellas.
Las herramientas que bloquean, deduplican o registran la procedencia mediante hash de confirmación deberían hacer lo mismo, verificando y canonicalizando primero en lugar de confiar en el hash sin formato de un objeto firmado que un atacante puede volver a codificar. No todos los sistemas están igualmente expuestos: los esquemas que también fijan un hash independiente de los archivos recuperados, como las derivaciones de salida fija de Nix, mantienen un respaldo; aquellos que se detienen en un hash de confirmación verificado no lo hacen.
Ginesin dice que informó del problema a GNU y Git en enero y a GitHub en marzo, y que hasta la publicación del artículo, ni Git ni ninguna falsificación lo habían abordado. La solución del lado de la falsificación se comprende bien, y el lugar obvio para comenzar es el caso S/MIME, donde GitHub todavía acepta lo que una estricta verificación local rechaza.