CVE-2026-3854: Cuando un git push es suficiente para comprometer GitHub

Clasificación: Vulnerabilidad crítica — CVSS 8.7
Fecha de divulgación pública: 28 de abril de 2026
Investigadores: Wiz Research Team

El descubrimiento de la CVE-2026-3854 ha marcado un hito en la investigación de vulnerabilidades asistida por IA: un error en el saneamiento de cabeceras internas permite a cualquier usuario con acceso normal escalar privilegios hasta el control total del servidor. Este análisis profundiza en cómo una inyección de delimitadores en el protocolo de transporte de Git puede evadir sandboxes de seguridad y comprometer millones de repositorios corporativos de forma silenciosa.

El problema en una línea

Cualquier usuario con acceso normal a un repositorio de GitHub podía, con un solo git push, ejecutar comandos arbitrarios en los servidores que sostienen la plataforma. Sin exploits sofisticados. Sin privilegios especiales. Con el mismo cliente git que usas todos los días.

Eso es CVE-2026-3854.

Contexto: ¿Por qué esto es diferente?

Las vulnerabilidades críticas en plataformas de desarrollo no son raras, pero la mayoría requieren condiciones específicas difíciles de reproducir: autenticación de alto privilegio, acceso a redes internas, configuraciones poco comunes. Esta vulnerabilidad rompe esa norma.

El fallo reside en la infraestructura interna que procesa cada operación de git push en GitHub, tanto en la versión en la nube (GitHub.com) como en las instalaciones autogestionadas (GitHub Enterprise Server). La raíz del problema no está en una librería de terceros ni en un componente marginal: está en el corazón del pipeline que mueve código desde los desarrolladores hasta los servidores de GitHub, miles de millones de veces al día.

Lo que hace especialmente interesante este caso —más allá del impacto— es que fue descubierto mediante ingeniería inversa asistida por IA sobre binarios compilados de código cerrado, algo que hasta hace poco era prácticamente inviable a escala.

Cómo funciona el pipeline interno de GitHub

Para entender el fallo, primero hay que entender el camino que recorre un git push antes de que el código llegue al servidor.

Cuando un desarrollador ejecuta git push por SSH, la solicitud no llega directamente al almacenamiento. Pasa por una cadena de cuatro servicios internos:

[Cliente git] → babeld → gitauth → gitrpcd → hook pre-receive

babeld actúa como el portero: recibe la conexión SSH, consulta a gitauth para verificar si el usuario tiene permiso para hacer push, y con la respuesta de ese servicio construye una cabecera interna llamada X-Stat. Esa cabecera es, en esencia, el pasaporte de la operación: contiene quién es el usuario, qué repositorio quiere modificar, y qué políticas de seguridad aplican a esa sesión.

gitrpcd recibe esa cabecera y configura el entorno de ejecución para los procesos siguientes. El punto crítico: gitrpcd no verifica nada por su cuenta. Confía ciegamente en lo que dice la cabecera X-Stat.

El hook pre-receive es el último eslabón: un binario compilado en Go que decide si el push se acepta o se rechaza, aplicando reglas como límites de tamaño de archivos, validación de LFS o hooks personalizados definidos por el administrador.

El fallo: un delimitador sin vigilancia

La cabecera X-Stat tiene un formato sencillo: pares clave=valor separados por punto y coma. Por ejemplo:

X-Stat: user_id=123;repo_id=456;large_blob_rejection_enabled=bool:true;push_option_0=mi_opcion

Las opciones de push (git push -o "algo") son una funcionalidad estándar de git que permite pasar metadatos adicionales al servidor. babeld las toma directamente del input del usuario y las incrusta en la cabecera X-Stat tal cual, sin ningún proceso de limpieza.

El problema: si el valor de una opción de push contiene un punto y coma, ese carácter parte el campo en dos, creando una nueva entrada en la cabecera. Y como el parser que procesa la X-Stat aplica una regla de última escritura gana —si una clave aparece dos veces, el segundo valor sobreescribe al primero— un atacante puede inyectar campos que anulen configuraciones de seguridad legítimas.

Un ejemplo concreto: si el servidor tiene activada la restricción de tamaño de archivos (large_blob_rejection_enabled=bool:true), un push con la opción -o "x;large_blob_rejection_enabled=bool:false" inyectaría un segundo valor para esa clave, y la restricción quedaría desactivada para esa sesión.

Hasta aquí, el impacto es relevante pero limitado. El salto a ejecución de código es lo que convierte esto en una vulnerabilidad crítica.

De inyección de campos a ejecución de código

El hook pre-receive tiene dos modos de funcionamiento, controlados por el campo rails_env de la cabecera X-Stat:

• Si rails_env tiene el valor production, los hooks personalizados se ejecutan dentro de un sandbox restringido.
• Si rails_env tiene cualquier otro valor, los hooks se ejecutan directamente, sin sandbox, con acceso completo al sistema de archivos, como el usuario git.

Esa distinción —un simple valor de cadena determinando si hay o no aislamiento de seguridad— es el núcleo de la escalada a RCE.

La cadena de explotación combina tres inyecciones sucesivas en la cabecera X-Stat:

Paso 1 — Salir del sandbox
Inyectar un valor no productivo para rails_env. El hook abandona la ruta segura y pasa a la ruta de ejecución directa.

Paso 2 — Redirigir el directorio de hooks
Inyectar custom_hooks_dir con una ruta controlada por el atacante. El binario buscará scripts de hooks en esa ubicación en lugar de la predeterminada.

Paso 3 — Apuntar a un binario arbitrario
Inyectar repo_pre_receive_hooks con una definición de hook cuyo campo de script incluye una secuencia de path traversal (../../...). El binario construye la ruta final uniendo el directorio inyectado con el traversal, llegando a un ejecutable arbitrario en el sistema de archivos.

El resultado: el sistema ejecuta ese binario como el usuario git, sin restricciones, antes de procesar el push. Desde ese momento, el atacante tiene control completo del servidor.

# Salida real del exploit contra una instancia GHES
remote: uid=500(git) gid=500(git) groups=500(git)

¿GitHub.com también? Sí, con un paso más

Cuando los investigadores aplicaron la misma cadena contra un repositorio en GitHub.com, la ejecución de código no ocurrió inmediatamente. La razón: GitHub.com tiene desactivada por defecto la ruta de hooks personalizados mediante otra bandera en la cabecera X-Stat.

El detalle revelador: esa bandera también viaja en la misma cabecera y, por tanto, también es inyectable con exactamente el mismo mecanismo. Una inyección adicional —activar el modo empresarial— fue suficiente para que la cadena completa funcionara en la infraestructura compartida de GitHub.com.

La diferencia de impacto entre GHES y GitHub.com no es técnica, sino arquitectónica. En GHES, el atacante compromete una instancia. En GitHub.com, compromete un nodo de almacenamiento compartido que sirve repositorios de múltiples organizaciones y usuarios. El usuario git que ejecuta el código tiene acceso, por diseño, a todos los repositorios almacenados en ese nodo. Los investigadores de Wiz confirmaron, sin acceder a contenido ajeno, que desde los nodos comprometidos eran accesibles millones de repositorios de terceros.

El papel de la IA en el descubrimiento

Este caso tiene una dimensión metodológica que merece atención propia. GitHub es código cerrado: sus binarios internos no están disponibles para inspección. Auditar una cadena de componentes compilados en busca de inconsistencias de parseo entre servicios habría requerido semanas de trabajo manual con herramientas de ingeniería inversa convencionales.

El equipo de Wiz utilizó IDA MCP, una integración que conecta el desensamblador IDA Pro con capacidades de análisis asistido por IA, para reconstruir la lógica interna de los binarios de GitHub a una velocidad que de otro modo no habría sido viable. Esto les permitió trazar el flujo del input de usuario a través de toda la cadena de servicios, identificar las rutas de ejecución condicionadas por rails_env, y mapear los campos inyectables antes de validarlos con captura de tráfico real en una instancia de prueba.

El hallazgo tiene implicaciones que van más allá de esta vulnerabilidad concreta: la barrera para auditar software de código cerrado está bajando. Eso es bueno para los investigadores defensivos. Y potencialmente preocupante si los mismos recursos están disponibles para actores maliciosos.

Exposición real: el 88% de instancias sin parchear

GitHub solucionó el problema en GitHub.com pocas horas después de recibir el reporte. Para GitHub Enterprise Server, publicó parches el 10 de marzo de 2026. Sin embargo, en la fecha de divulgación pública —casi dos meses después— los datos de Wiz indicaban que el 88% de las instancias GHES seguían ejecutando versiones vulnerables.

Este dato no es sorprendente para quienes administran entornos empresariales, pero sí es un recordatorio de cuánto tiempo permanecen expuestas las organizaciones incluso cuando existe un parche disponible. Las razones habituales: ventanas de mantenimiento rígidas, procesos de validación interna previos a la actualización, o simplemente falta de visibilidad sobre qué versión está corriendo en producción.

Qué hacer ahora

Para instancias de GitHub Enterprise Server

La prioridad es actualizar. Las versiones que incluyen el parche son:

Cualquier instancia en versión 3.19.1 o anterior es vulnerable.

Para GitHub.com

No se requiere ninguna acción. El parche fue aplicado en la infraestructura de GitHub directamente.

Conclusión

CVE-2026-3854 es un recordatorio de algo que la industria sabe pero frecuentemente subestima: los sistemas distribuidos heredan la superficie de ataque de todos sus componentes, más las interfaces entre ellos. Un servicio que confía ciegamente en el anterior. Un parser que no escapa delimitadores. Una ruta de ejecución sin sandbox que nadie eliminó. Cada pieza, razonable por separado. Devastadoras juntas.

La buena noticia es que GitHub actuó con rapidez y no existe evidencia de explotación maliciosa antes de la divulgación. La mala noticia es que, mientras escribimos esto, la mayoría de los servidores autogestionados siguen sin parchear.

Referencias

• Wiz Research — CVE-2026-3854 Breakdown, abril 2026. wiz.io/blog/github-rce-vulnerability-cve-2026-3854
• The Hacker News — Researchers Discover Critical GitHub CVE-2026-3854 RCE Flaw, abril 2026. thehackernews.com
• GitHub Security Blog — Securing the git push pipeline. github.blog/security
• GitHub Advisory GHSA-64fw-jx9p-5j24. github.com/advisories