Un push de Git es suficiente para RCE en servidores empresariales de GitHub
El 28 de abril de 2026, Wiz Research y GitHub publicaron los detalles sobre CVE-2026-3854: Una vulnerabilidad de inyección de comandos en GitHub Enterprise Server permite que cualquier usuario autenticado con acceso de push a un repositorio ejecute código arbitrario en el servidor con un simple git push. El 88% de las instancias autohospedadas no estaban patched al momento de la divulgación.
6 min. de lectura
Lo más importante en resumen
- CVSS 8.7 – Un solo git push es suficiente. Cualquier usuario con acceso de push a un repositorio, incluyendo aquellos creados por el usuario, puede ejecutar comandos arbitrarios en el servidor de GitHub Enterprise. No se requiere un kit de explotación, solo un cliente git estándar.
- Inyección de comandos en el manejo de opciones de push. Los valores de las opciones de push no se limpiaron adecuadamente antes de la procesamiento. Un atacante puede utilizar un carácter delimitador para inyectar metadatos adicionales en los encabezados internos del servicio.
- GitHub.com se patched en menos de una hora. Wiz Research descubrió la vulnerabilidad el 4 de marzo de 2026, reportóla a GitHub el mismo día. El parche en GitHub.com se llevó a cabo el 4 de marzo. Los parches de GHES: 10 de marzo. Disclosure pública: 28 de abril de 2026.
- Parches disponibles para todas las versiones de GHES compatibles. 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0 y versiones superiores. Los que ejecutan versiones anteriores no tienen soporte.
El ataque explicado: ¿Por qué un git push es suficiente para RCE?
Las operaciones de git push admiten las llamadas opciones de push, que son pares clave-valor personalizados que transmiten metadatos sobre el push. GitHub Enterprise Server procesaba estos valores en un protocolo interno sin escapar correctamente el carácter delimitador. Como este carácter puede aparecer en la entrada del usuario, valores de opciones de push diseñados con cuidado pueden inyectar campos de encabezado adicionales en la comunicación interna.
El resultado es la ejecución de código en el servidor, no en la capa de repositorio, sino en el servicio backend que procesa el push. Wiz Research describe el ataque como completamente reproducible con un cliente git estándar. No se requiere una herramienta especial, una vulnerabilidad preexistente, ni autorización adicional a menos que el usuario tenga acceso de push a un repositorio.
El escenario de ataque es de baja barrera: cualquier colaborador externo, cualquier empleado con acceso a repositorios, cualquier cuenta comprometida puede aprovechar esta vulnerabilidad. En entornos empresariales con implementaciones a gran escala de GitHub autohospedado, el rango es significativo.
Timeline de la divulgación: ¿Qué pasó entre marzo y abril?
4 de marzo de 2026: Wiz Research descubrió y reportó la vulnerabilidad responsablemente a GitHub. GitHub implementó el parche en menos de una hora en GitHub.com.
10 de marzo de 2026: Los parches para todas las versiones de GitHub Enterprise Server compatibles se publicaron: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. CVE-2026-3854 se asignó un CVSS 8.7.
28 de abril de 2026: Disclosure pública después de la coordinada divulgación completa. Según la investigación de Help Net Security, el 88% de las instancias autohospedadas no estaban patched aproximadamente siete semanas después de la disponibilidad de los parches.
88% no patched. Siete semanas después del parche de GHES, casi todas las instancias autohospedadas seguían funcionando en la versión vulnerable. Esto no es un caso aislado – es el estado normal en la infraestructura de git empresarial.
Lo que los equipos de seguridad en DACH deben hacer de inmediato
1. GHES-versión inmediatamente revisar. Versiones mínimas actualmente pachadas: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. Cualquiera que esté bajo estas versiones o esté ejecutando versiones anteriores a 3.14 está sin soporte y debe actualizar.
2. Revisar los permisos de acceso al repositorio. ¿Quién tiene acceso de push a qué repositorios? Colaboradores externos, cuentas de servicio obsoletas, accesos temporales? Cualquier cuenta de este tipo es un posible ruta de ataque, independientemente de si el repositorio es público o interno.
3. Revisar los registros de servidor por anomalías. GitHub proporciona registros para las operaciones de push. Valores de opción de push inusuales, pushes desde IPs desconocidos o en horarios inusuales deben escalarse para su revisión manual.
4. Revisar los controles de la capa de red. El puerto de administración de GHES (8443) y los puntos finales de servicio internos no deben ser accesibles desde Internet público. Esto no reduce la ruta de ataque a cero, pero aumenta la barrera para los atacantes externos.
Preguntas frecuentes sobre CVE-2026-3854
¿Afecta CVE-2026-3854 a GitHub.com o solo a instancias autohospedadas?
Ambas se ven afectadas. GitHub.com implementó una solución dentro de las horas siguientes al responsable de divulgación de Wiz Research el 4 de marzo de 2026. Los usuarios de GitHub.com están protegidos desde el 4 de marzo. El riesgo afecta únicamente a las organizaciones que ejecutan GitHub Enterprise Server y no han actualizado a las versiones corregidas.
¿Todos los repositorios en un servidor GHES deben considerarse comprometidos?
Depende de si la vulnerabilidad ha sido explotada. Un parche cierra el vector de ataque, pero no corrige una compromisión ya existente. Las organizaciones con código sensible (Infraestructura como Código, credenciales en repositorios, configuraciones de CI/CD) deben revisar la historia de Git y los registros de servidor por actividades sospechosas desde marzo de 2026. En caso de duda: iniciar el proceso de respuesta a incidentes.
¿Pueden las acciones de GitHub o las canalizaciones de CI/CD aprovechar la vulnerabilidad?
Sí. Cualquier componente automatizado que ejecute operaciones de push de Git – flujos de trabajo de Actions, ejecutores de CI/CD, scripts de despliegue – es un vector de ataque potencial si se ejecuta en una versión vulnerable de GHES. Especialmente relevantes: ejecutores externos con acceso a múltiples repositorios y credenciales que pueden estar comprometidas.
¿Cuál es la diferencia entre la vulnerabilidad de la cadena de suministro en el CLI de Bitwarden de GitHub Actions y la CVE-2026-3854?
CVE-2026-3854 es una vulnerabilidad del lado del servidor – el ataque se dirige al propio GitHub Enterprise Server. La vulnerabilidad del CLI de Bitwarden de GitHub Actions es un ataque de cadena de suministro a través de dependencias externas en las canalizaciones. Ambas son críticas, pero con diferentes mecanismos de protección: administración de parches para CVE-2026-3854, pinning de dependencias y procesos de SBOM para los riesgos de cadena de suministro.
Sugerencias de lectura de la redacción
Más del MBF Media Network
Fuente de la imagen del título: Pexels / Markus Spiske (px:1089438)
