Si administras GitHub Enterprise Server, deja lo que estás haciendo y actualiza ahora. El 28 de abril de 2026, GitHub y los investigadores de Wiz hicieron pública una vulnerabilidad crítica que lleva activa desde hace tiempo en el núcleo de la infraestructura git de GitHub: el CVE-2026-3854.
El fallo permite a cualquier usuario con acceso de push ejecutar código arbitrario en los servidores de GitHub. No hace falta comprometer credenciales adicionales ni explotar sistemas externos. Un solo comando git push con opciones manipuladas es suficiente.
¿Qué es CVE-2026-3854?
El CVE-2026-3854 es una vulnerabilidad de ejecución remota de código (RCE) con una puntuación CVSS de 8.7 (crítica) en el pipeline interno de git push de GitHub.
El problema tiene su origen en una falta de sanitización del carácter punto y coma (;) en las push options que un usuario puede enviar al servidor. GitHub utiliza internamente este carácter como delimitador en los metadatos de las operaciones de push, y cuando las opciones del usuario se incorporan a esos metadatos sin validación, es posible inyectar campos adicionales que el sistema no esperaba recibir desde el exterior.
El mecanismo de “last-write-wins” en el parseo de campos internos hace que los campos inyectados al final sobrescriban los valores originales, permitiendo al atacante redefinir parámetros críticos de seguridad.
Cómo funciona el ataque
El vector de explotación es un git push con opciones de push manipuladas. El comando git push -o permite enviar pares clave-valor arbitrarios al servidor durante un push. Normalmente, estas opciones controlan comportamientos como notificaciones o flags de revisión. En este caso, se pueden usar para inyectar campos internos del sistema.
El ataque se ejecuta en tres fases:
Fase 1 — Escape del sandbox: Inyectando rails_env con un valor controlado por el atacante, es posible salir del entorno de ejecución aislado que GitHub usa para procesar hooks.
Fase 2 — Redirección de hooks: Inyectando custom_hooks_dir, el atacante redirige la ubicación desde la que el sistema carga los scripts de hook a una ruta arbitraria del sistema de ficheros.
Fase 3 — Ejecución de código: Inyectando repo_pre_receive_hooks con secuencias de path traversal (../), el atacante apunta a un fichero ejecutable bajo su control. El servidor lo ejecuta con los privilegios del proceso de GitHub.
1
git push -o "campo_legitimo=valor;rails_env=atacante;custom_hooks_dir=/ruta/controlada;repo_pre_receive_hooks=../../payload" origin main
El resultado: ejecución de código arbitrario en el servidor con los privilegios disponibles para el contexto de la aplicación.
Impacto: GitHub.com vs GitHub Enterprise Server
La vulnerabilidad afecta de forma diferente dependiendo del entorno:
GitHub.com y GitHub Enterprise Cloud
GitHub.com fue parcheado en menos de 75 minutos desde que el equipo de seguridad validó el reporte. GitHub confirmó que, al revisar los logs, cada activación del código vulnerable correspondía exclusivamente a la actividad de prueba de los propios investigadores de Wiz. Ningún otro usuario o cuenta activó ese flujo. No se requiere ninguna acción por parte de los usuarios de GitHub.com.
GitHub Enterprise Server (GHES)
Esta es la parte preocupante. GHES requiere que los clientes apliquen las actualizaciones manualmente en sus instalaciones. En el momento de la divulgación pública, el 88% de las instancias de GHES seguían sin parchear.
Una instancia GHES comprometida expone:
- Todos los repositorios alojados en esa instancia
- Secretos y credenciales almacenados en el entorno
- Acceso potencial a la red interna corporativa
¿Estás afectado? Versiones vulnerables y corregidas
| Rama GHES | Vulnerable hasta | Versión con parche |
|---|---|---|
| 3.14 | ≤ 3.14.24 | 3.14.25 o superior |
| 3.15 | ≤ 3.15.19 | 3.15.20 o superior |
| 3.16 | ≤ 3.16.15 | 3.16.16 o superior |
| 3.17 | ≤ 3.17.12 | 3.17.13 o superior |
| 3.18 | ≤ 3.18.6 | 3.18.7 o superior |
| 3.19 | ≤ 3.19.3 | 3.19.4 o superior |
| 3.20 | — | 3.20.0 (incluye el parche) |
Si tu instancia de GHES corre cualquier versión anterior a las indicadas en la columna derecha, es vulnerable. La actualización es la única mitigación disponible: no existe un workaround que permita deshabilitar el vector de ataque sin actualizar.
El hallazgo: ingeniería inversa con Inteligencia Artificial
Lo que hace técnicamente notable esta investigación es el método de descubrimiento. Los investigadores de Wiz usaron herramientas de ingeniería inversa asistidas por Inteligencia Artificial — específicamente IDA con integración MCP (IDA MCP) — para analizar binarios compilados de la infraestructura de GitHub. Un análisis que anteriormente requería semanas de trabajo manual se aceleró significativamente con este enfoque.
El flujo de trabajo fue el siguiente: los investigadores identificaron patrones anómalos en el manejo de push options al analizar el binario, trazaron el camino de los datos de usuario a través del código compilado, y encontraron el punto exacto donde el punto y coma no era escapado antes de ser incorporado a los metadatos internos.
La línea de tiempo completa:
- 4 de marzo de 2026 — Wiz descubre la vulnerabilidad y notifica a GitHub
- 4 de marzo de 2026 — GitHub despliega mitigación en GitHub.com en menos de 75 minutos
- 10 de marzo de 2026 — Se asigna el CVE y GitHub publica parches para todas las versiones de GHES con soporte
- 28 de abril de 2026 — Divulgación pública coordinada
Reconocimiento del bug bounty
El CISO de GitHub describió el hallazgo como uno de los más significativos recibidos en su programa de bug bounty:
“A finding of this caliber and severity is rare, earning one of the highest rewards available in our Bug Bounty program.”
Una vulnerabilidad de esta naturaleza — RCE en infraestructura compartida que afecta a millones de repositorios — entra en la categoría más alta de los programas de recompensa por fallos de seguridad.
Qué hacer ahora
Si usas GitHub.com o GitHub Enterprise Cloud: no tienes que hacer nada. El parche ya está aplicado.
Si administras GitHub Enterprise Server:
- Identifica la versión exacta de tu instancia en la interfaz de administración.
- Consulta la tabla de versiones de arriba para confirmar si estás afectado.
- Si estás en una versión vulnerable, actualiza a la versión parcheada correspondiente a tu rama lo antes posible.
- Consulta las notas de lanzamiento de GHES para instrucciones de actualización específicas de tu versión.
Dado que el 88% de instancias seguía sin parchear en el momento de la divulgación, hay que asumir que existen actores maliciosos que en este momento están buscando activamente instancias vulnerables accesibles.
Preguntas frecuentes
¿Necesito tener permisos especiales para explotar esta vulnerabilidad?
Solo necesitas acceso de push a un repositorio en la instancia afectada. Eso incluye colaboradores externos con permisos de escritura, no solo administradores. En organizaciones con repositorios privados accesibles a muchos colaboradores, la superficie de ataque es amplia.¿GitHub.com ha sido comprometido por esta vulnerabilidad?
No. GitHub aplicó el parche en menos de 75 minutos desde que validó el reporte. Al revisar los logs, confirmaron que el código vulnerable solo fue activado por la actividad de prueba de los investigadores de Wiz. No hay evidencia de explotación por terceros.¿Sirve de algo desactivar push options temporalmente como workaround?
No existe un workaround oficial que elimine el riesgo sin actualizar. Las push options son parte del protocolo git estándar y desactivarlas rompería flujos de trabajo legítimos. La única solución efectiva es actualizar GHES a una versión parcheada.¿Cómo afecta esto a repositorios privados?
Un atacante con acceso de push a cualquier repositorio en la instancia podría comprometer el servidor completo, incluyendo todos los repositorios alojados en él — públicos y privados. El impacto no está limitado al repositorio al que el atacante tiene acceso legítimo.Fuentes
- Wiz Research: CVE-2026-3854 — GitHub RCE Vulnerability
- GitHub Blog: Securing the git push pipeline — responding to a critical RCE vulnerability
- Mitchell Hashimoto en X: @mitchellh
Compártelo si te ha resultado útil.
Si gestionas infraestructura y quieres revisar tu postura de seguridad, cuéntame tu situación.
Y… hasta aquí por hoy!
Loading comments from Disqus ...