GitHub corrigió una falla crítica de git push que afectaba a repositorios privados

GitHub ha revelado detalles de CVE-2026-3854, una vulnerabilidad crítica de remote code execution en su Pipeline de git push que podía dejar expuestos millones de repositorios privados. Según GitHub, Wiz reportó el fallo el 4 de marzo y la corrección se desplegó en GitHub.com en menos de dos horas. Los parches para clientes enterprise self-hosted ya están disponibles.

La importancia de esta noticia está en dónde apareció el fallo. El camino vulnerable estaba dentro de una de las partes más sensibles de la infraestructura de GitHub, la que procesa los push de los desarrolladores. No se trata de otro problema cualquiera de web application. Es una posible vía de acceso a source code, secretos internos y cadenas de suministro de software de las que dependen grandes empresas.

GitHub explicó que un atacante con acceso de push a cualquier repositorio, incluso a uno creado por él mismo, podía abusar de push options sin sanitizar, inyectar metadata interna de confianza y terminar ejecutando comandos arbitrarios en el servidor que procesaba el push. En su explicación oficial, GitHub dijo que el exploit requería un solo comando git push specially crafted. Wiz, cuyos investigadores encontraron el problema a través del programa de bug bounty, señaló que el impacto potencial en GitHub.com podía alcanzar millones de repositorios públicos y privados alojados en nodos compartidos afectados.

La compañía afirma que su equipo reprodujo el problema en 40 minutos, desplegó el fix en GitHub.com ese mismo día y después realizó una revisión forensic. GitHub sostiene que esa revisión no encontró evidencia de explotación antes de la divulgación. También eliminó una ruta de code innecesaria de los entornos afectados como parte de un refuerzo adicional.

El riesgo operativo que queda está ahora en GitHub Enterprise Server. GitHub publicó parches para las versiones soportadas y dijo que los administradores deberían actualizar de inmediato y revisar los audit logs en busca de actividad sospechosa en los push. Ese es el takeaway práctico. Aunque GitHub.com se corrigió con rapidez, los clientes enterprise deberían tratar esto como una remediation de alta prioridad, porque los sistemas de alojamiento de code están muy cerca del resto del stack de software. Como destacó BleepingComputer en su cobertura más amplia y detallaron GitHub y Wiz, este era el tipo de fallo de infraestructura que puede convertir muy rápido un workflow de desarrollo en un incidente de supply chain.