Una vulnerabilidad crítica de ejecución remota de código (RCE), identificada como CVE-2026-3854, fue descubierta en la infraestructura interna de git de GitHub. Esta falla podría haber permitido a cualquier usuario autenticado comprometer servidores backend, acceder a millones de repositorios privados y, en el caso de GitHub Enterprise Server (GHES), lograr un control total del servidor.

Los investigadores de Wiz descubrieron la vulnerabilidad mediante ingeniería inversa asistida por IA de binarios compilados de código cerrado. El fallo, clasificado como CWE-77 (neutralización incorrecta de elementos especiales), se originaba en cómo el proxy interno de git de GitHub, babeld, manejaba los valores de las opciones de push suministradas por el usuario.

Cuando un usuario ejecuta git push -o, las cadenas de opciones arbitrarias se envían al servidor. La vulnerabilidad surgía porque babeld copiaba estos valores literalmente en un encabezado interno X-Stat delimitado por punto y coma, sin sanear el carácter de punto y coma, que también se usaba como delimitador de campos.

Dado que el servicio downstream gitrpcd analizaba el encabezado X-Stat usando semántica de last-write-wins, un atacante podía inyectar nuevos campos clave-valor simplemente incluyendo un punto y coma seguido de un nombre y valor de campo dentro de una opción de push.

Campos críticos para la seguridad, como rails_env, custom_hooks_dir y repo_pre_receive_hooks, podían ser sobrescritos mediante este único vector de inyección.

La escalada a RCE requería encadenar tres campos inyectados:

1. Eludir el sandbox — Inyectar un valor no productivo en rails_env cambiaba el binario del hook pre-receive de su ruta de ejecución en sandbox a una ruta sin sandbox, ejecutándose directamente.
2. Redirigir el directorio de hooks — Sobrescribir custom_hooks_dir redirigía la ubicación donde el binario buscaba los scripts de hooks.
3. Recorrido de ruta para ejecución arbitraria — Inyectar una entrada manipulada en repo_pre_receive_hooks con un payload de recorrido de ruta hacía que el binario resolviera y ejecutara un binario arbitrario del sistema de archivos como el usuario del servicio git.

El exploit completo no requería escalada de privilegios, herramientas especiales ni dependencias de zero-days, solo un cliente git estándar.

En GitHub Enterprise Server, la explotación permitía un compromiso total del servidor, incluyendo acceso de lectura/escritura a todos los repositorios alojados y secretos internos.

En GitHub.com, Wiz descubrió inicialmente que la ruta de código de hooks personalizados estaba inactiva por defecto, pero encontró que un flag booleano enterprise_mode en el encabezado X-Stat era igualmente inyectable, habilitando la cadena completa de ataque en la infraestructura compartida de GitHub.com.

Al lograr RCE en los nodos de almacenamiento compartido de GitHub.com, Wiz confirmó que el usuario del servicio git tenía acceso al sistema de archivos de millones de repositorios pertenecientes a otros usuarios y organizaciones en esos nodos.

Los investigadores de Wiz no accedieron a contenido de terceros, usando solo sus propias cuentas de prueba para validar la exposición entre inquilinos.

Cabe destacar que esta es una de las primeras vulnerabilidades críticas en binarios de código cerrado descubiertas utilizando herramientas de IA a gran escala.

Wiz empleó IDA MCP para ingeniería inversa automatizada, permitiendo una reconstrucción rápida de los protocolos internos de GitHub en binarios compilados, un análisis que habría sido prohibitivamente lento de realizar manualmente.

Esto marca un cambio significativo en la metodología de investigación de vulnerabilidades en arquitecturas opacas y multiservicio.

GitHub recibió el informe el 4 de marzo de 2026, lo validó en cuestión de horas y desplegó una solución en GitHub.com a las 19:00 UTC del mismo día, dentro de una ventana de respuesta de aproximadamente 6 horas. La investigación forense de GitHub confirmó que no hubo explotación previa a la divulgación.

Para GitHub Enterprise Server, hay parches disponibles, y los administradores de GHES deben actuar de inmediato:

En el momento de la divulgación, los datos de Wiz indicaban que el 88% de las instancias de GHES seguían sin parchear. Los usuarios de GitHub Enterprise Cloud y GitHub.com no requieren acción alguna.

Los administradores de GHES también deberían auditar /var/log/github-audit.log en busca de operaciones de push que contengan caracteres especiales inusuales en los valores de las opciones de push, como indicadores de intentos de explotación previos.