GitHub parchó CVE-2026-3854: un solo `git push` daba RCE y exponía millones de repositorios

⏱️ Lectura: 6 min

El 28 de abril de 2026, Wiz Research hizo pública CVE-2026-3854, una falla crítica de inyección de comandos en el protocolo interno de GitHub que permitía a cualquier usuario autenticado ejecutar código remoto en los servidores de la plataforma usando solo un cliente git estándar. El bug tocaba a la vez a GitHub.com y a GitHub Enterprise Server (GHES), y según mediciones de Wiz al momento del anuncio el 88 % de las instancias de GHES expuestas a Internet seguían sin parchar.

📑 En este artículo

1. Línea de tiempo verificada
2. Qué falla por dentro: el header X-Stat
3. Impacto distinto en GitHub.com y en GHES
4. ¿Hubo explotación in-the-wild?
5. Qué versiones de GHES quedan a salvo
6. Qué deberíamos llevarnos de este caso
7. Fuentes

Línea de tiempo verificada

GitHub publicó su propio post mortem firmado por la CISO Alexis Wales con marcas de tiempo precisas:

Fecha	Evento
4 mar 2026	Wiz reporta la vulnerabilidad a GitHub. El equipo la reproduce en 40 minutos.
4 mar 2026 — 17:45 UTC	Validación interna completa.
4 mar 2026 — 19:00 UTC	Fix desplegado en github.com (75 minutos desde validación, ~2 h desde el reporte).
10 mar 2026	CVE-2026-3854 asignada y se libera el parche para Enterprise Server.
28 abr 2026	Disclosure pública coordinada por Wiz y GitHub.

CVSS asignado por Wiz: 8.7 (alta). La explotación requería un usuario autenticado con permisos de push sobre cualquier repositorio, condición trivial en una plataforma multi-tenant donde forks y cuentas gratuitas son la norma.

Qué falla por dentro: el header X-Stat

El componente vulnerable es babeld, el proxy interno que GitHub usa para enrutar operaciones git entre el cliente y los nodos de almacenamiento. Cuando un cliente envía git push -o key=value, babeld copia esos valores literalmente al header X-Stat, una cadena con campos key=value separados por punto y coma. El bug, en palabras de Wiz: “babeld copies git push option values directly into the X-Stat header — without sanitizing semicolons”.

Como el parser de X-Stat aplica semántica last-write-wins (la última ocurrencia gana cuando hay claves duplicadas), un atacante podía sobrescribir campos de seguridad con un payload posterior. Wiz encadenó tres inyecciones en una sola operación de push:

1. Bypass de sandbox: inyectar un rails_env no productivo desactiva los aislamientos que GitHub aplica solo en producción.
2. Redirección del directorio de hooks: inyectar custom_hooks_dir redirige la búsqueda de scripts de hooks hacia una ruta controlada por el atacante.
3. Path traversal con payload: inyectar repo_pre_receive_hooks con secuencias de traversal apunta a un binario arbitrario que se ejecuta como el usuario git cuando el servidor invoca el hook pre-receive.

Resultado: “a single git push command was enough to exploit a flaw in GitHub’s internal protocol and achieve code execution on backend infrastructure” (Wiz).

Los investigadores que firman el reporte son Sagi Tzadik, Nir Ohfeld, Ronen Shustin, Hillai Ben-Sasson, Yuval Avrahami y Noam Malron.

Impacto distinto en GitHub.com y en GHES

La diferencia entre la versión SaaS y la self-hosted determina qué exactamente quedaba expuesto:

• GitHub.com: RCE sobre los shared storage nodes. Wiz confirma textual: “millions of public and private repositories belonging to other users and organizations were accessible on the affected nodes”. Es decir, el atacante podía leer y manipular código de tenants ajenos en el mismo nodo físico, rompiendo el aislamiento multi-tenant.
• GitHub Enterprise Server: compromiso completo del servidor. Acceso de lectura y escritura sobre todos los repositorios alojados, más los secretos internos de la instancia. Para una organización que centraliza CI/CD, claves de despliegue y propiedad intelectual en GHES, equivale a una llave maestra.

Un portavoz de Wiz citado por SecurityWeek la describió como potencialmente “one of the most severe SaaS vulnerabilities ever found”, capaz de exponer “codebases of nearly all of the world’s biggest enterprises”.

¿Hubo explotación in-the-wild?

No. El propio análisis forense de GitHub descarta uso malicioso previo a la disclosure. Su telemetría muestra que el camino de código vulnerable solo se activó durante las pruebas de Wiz. Wales lo explica así en el post de GitHub: “the exploit forces the server to take a code path that is never used during normal operations on github.com. This is not something an attacker can avoid or suppress, as it is an inherent consequence of how the injection works”. La conclusión oficial: ningún dato de cliente fue accedido, modificado ni exfiltrado.

Esto convierte a CVE-2026-3854 en un caso casi de manual de divulgación responsable: vector hipercrítico, ventana de exposición real (~6 días entre reporte y patch a Enterprise Server), pero sin víctimas conocidas porque la detección llegó antes que cualquier actor.

Qué versiones de GHES quedan a salvo

Según el advisory oficial de GitHub, las primeras versiones parchadas por rama son:

Rama GHES	Primera versión segura
3.14.x	3.14.25
3.15.x	3.15.20
3.16.x	3.16.16
3.17.x	3.17.13
3.18.x	3.18.7
3.19.x	3.19.4
3.20.x	3.20.0

Si tu organización opera GHES auto-hospedado y todavía está en una versión anterior, asumí que estás del lado del 88 % vulnerable y priorizá el upgrade. Wiz publicó además reglas de detección para que sus clientes identifiquen instancias afectadas en su inventario.

Qué deberíamos llevarnos de este caso

Más allá del bug puntual, CVE-2026-3854 deja un par de lecciones útiles para cualquiera que opere infraestructura compartida:

• Los headers serializados ad-hoc son una superficie de ataque real. Usar punto y coma como delimitador sin sanitización equivale a permitir SQL injection en una cláusula WHERE. Cualquier protocolo interno que vaya de un componente confiable a otro debe asumir que la fuente original puede ser hostil.
• last-write-wins como semántica por defecto en parsing es peligroso. La defensa en profundidad acá hubiera sido fallar ante claves duplicadas, no quedarse con la última. Es un patrón que aparece en cookies, headers y formularios HTTP.
• Multi-tenancy compartido amplifica el blast radius. El mismo bug en una instancia dedicada habría comprometido un tenant. En github.com comprometía nodos enteros con repos de organizaciones no relacionadas. La separación física de tenants críticos sigue siendo cara, pero es la única defensa real contra escalación cross-tenant.
• La disclosure responsable funciona cuando la respuesta es seria. 40 minutos para reproducir, 75 minutos para parchar producción y un post mortem público con timestamps marca la diferencia entre un incidente y una crisis.

Para developers individuales en github.com no hay acción técnica pendiente: el fix se desplegó hace casi dos meses y no hubo explotación. Para administradores de GHES, en cambio, la lectura es directa: si todavía no actualizaste, estás corriendo una infraestructura críticamente vulnerable que Wiz ya documentó paso a paso en su blog.

Fuentes

• Wiz Research — CVE-2026-3854 technical breakdown
• GitHub Security Blog — Securing the git push pipeline
• The Hacker News — Researchers Discover Critical GitHub CVE-2026-3854 RCE Flaw
• BleepingComputer — GitHub fixes RCE flaw that gave access to millions of private repos
• SecurityWeek — Critical GitHub Vulnerability Exposed Millions of Repositories
• Help Net Security — 88% of self-hosted GitHub servers exposed to RCE
• CVE-2026-3854 — Registro oficial