A un punto y coma del desastre
Un simple git push. Ese comando cotidiano que millones de desarrolladores ejecutan a diario estuvo, hasta el 4 de marzo de 2026, peligrosamente cerca de convertirse en la puerta de entrada a uno de los incidentes de seguridad más graves en la historia de GitHub.
Descubierta por Wiz y registrada como CVE-2026-3854, esta vulnerabilidad de ejecución remota de código (RCE) podía permitir el acceso a repositorios privados de prácticamente cualquier organización alojada en la plataforma. Lo más sorprendente es que fue encontrada con ayuda de inteligencia artificial y solucionada en apenas seis horas.
Lo que ocurre detrás de un git push
Cuando un desarrollador sube código, el proceso no consiste solo en guardar archivos. El comando atraviesa una cadena de servicios internos escritos en distintos lenguajes que se comunican mediante un encabezado HTTP interno llamado X-Stat.
Este encabezado funciona como una lista de parámetros clave=valor separados por punto y coma, que controlan reglas críticas como permisos, políticas de tamaño de archivos o nombres de ramas.
El problema surgió en el primer servicio de la cadena, llamado babeld. Este servicio construía el encabezado X-Stat tras autenticar al usuario, pero cometía un error fatal: no filtraba los puntos y coma en los push options (git push -o).
Ese pequeño detalle permitía a un atacante inyectar nuevos campos dentro del encabezado. Como el sistema priorizaba el último valor leído, era posible sobrescribir parámetros de seguridad y, combinando tres campos internos específicos, lograr ejecución remota de código en la infraestructura de GitHub.
Nube vs. servidores empresariales
La vulnerabilidad afectaba tanto a GitHub.com como a GitHub Enterprise Server (GHES).
En servidores empresariales el ataque era directo. En la nube, los investigadores descubrieron un paso extra con el que podían activar el “modo Enterprise” mediante otro campo inyectable en el encabezado X-Stat, completando así la cadena de explotación.
El hallazgo fue posible gracias a ingeniería inversa asistida por IA con la herramienta IDA MCP, marcando uno de los primeros casos importantes de vulnerabilidades críticas descubiertas en software propietario mediante IA.
Carrera contrarreloj: seis horas
La respuesta de GitHub fue extremadamente rápida:
- 40 minutos para reproducir la vulnerabilidad internamente.
- 2 horas para identificar la causa raíz y desplegar el parche en GitHub.com.
- 6 horas después, mitigación completa y análisis forense.
La investigación confirmó que no hubo explotación maliciosa.
Sin embargo, el problema persistía para instalaciones locales de GHES. Al hacerse pública la vulnerabilidad el 28 de abril, Wiz estimó que el 88% de las instancias seguían vulnerables, requiriendo actualización urgente a la versión 3.19.3 o superior.
Un momento complicado para GitHub
Este incidente llegó en un periodo turbulento para la plataforma, propiedad de Microsoft. Días antes, GitHub sufrió una caída importante que revertía commits ya fusionados para algunos usuarios, sumándose a preocupaciones internas sobre fiabilidad y salida de líderes.
Aun así, la rapidez con la que se solucionó esta vulnerabilidad demuestra la importancia de la colaboración entre investigadores y plataformas. Y por ahora, los desarrolladores pueden respirar tranquilos, ya que el git push vuelve a ser un comando rutinario.
Deja una respuesta