GitHub Enterprise Server tiene SSRF crítica que expone credenciales internas (CVE-2026-9312)
Una vulnerabilidad sin autenticación en GitHub Enterprise Server recibió un puntaje de 9,2 en CVSS y permite redirigir llamadas internas para filtrar credenciales. Las correcciones están en las versiones 3.16.20, 3.17.17, 3.18.11 y 3.19.8.
GitHub ha corregido una vulnerabilidad crítica de server-side request forgery en GitHub Enterprise Server, la edición auto-hospedada que bancos, fintechs y organismos públicos ejecutan dentro de su propio centro de datos para mantener el código bajo control. Catalogada como CVE-2026-9312 y divulgada por el mismo GitHub el 27 de mayo, la vulnerabilidad recibió una puntuación de 9,2 en CVSS 4.0 y permite que un atacante sin ninguna autenticación obligue al servidor a realizar solicitudes contra servicios internos, con potencial de exponer credenciales.
Cómo funciona la falla
El punto de entrada es un endpoint de carga que valida incorrectamente los datos recibidos. Inyectando secuencias de path traversal en los parámetros de la solicitud, el atacante interrumpe el flujo previsto y redirige llamadas internas de API a destinos bajo su control, el patrón clásico de SSRF registrado como CWE-918. A partir de ahí, según el registro publicado por GitHub, es posible alcanzar servicios internos y exponer credenciales sensibles.
El vector CVSS se encarga del resto. La falla no requiere privilegios (PR:N) ni interacción del usuario (UI:N), lo que la hace accesible desde el borde de la red, pero requiere condiciones específicas en el entorno: la cadena tiene alta complejidad (AC:H) y requisitos de ataque presentes (AT:P). Cuando se cumplen estas condiciones, el impacto sobre la confidencialidad, integridad y disponibilidad del sistema es alto en los tres ejes (VC:H/VI:H/VA:H). Es la suma del acceso sin credencial con impacto total lo que respalda el 9,2.
Las fallas de SSRF son la plaga recurrente de las aplicaciones corporativas expuestas a internet porque transforman el servidor en un procurador del atacante: quien se comunica con el sistema externo comienza a comunicarse, por medio, con todo lo que el sistema puede ver internamente. En un producto que orquesta código fuente, esta "visión interna" incluye precisamente lo que nadie quiere que se filtre.
Qué versiones necesitan parches
Cuatro líneas de lanzamiento están afectadas: de la 3.16.0 a la 3.16.19, de la 3.17.0 a la 3.17.16, de la 3.18.0 a la 3.18.10 y de la 3.19.0 a la 3.19.7. Las correcciones han salido en las versiones 3.16.20, 3.17.17, 3.18.11 y 3.19.8, listadas en las notas de lanzamiento de administración de la plataforma. Las instalaciones en cualquier versión anterior dentro de estos rangos siguen expuestas.
Aquí está el detalle operativo que separa GitHub Enterprise Server de la nube pública de GitHub: la actualización es responsabilidad del cliente. No hay un parche silencioso aplicado por el proveedor durante la noche. El reloj de remediación comienza a contar para el equipo de infraestructura de cada empresa, y cada día de retraso es un día más de ventana.
Qué cambia para Brasil
La lectura brasileña pasa por donde el GHES suele ser instalado. Las empresas que no pueden o no quieren entregar el repositorio a la nube de GitHub, como bancos, aseguradoras, integradores de gobierno y consultorías de TI que custodian el código de clientes regulados, mantienen la versión auto-hospedada para retener el repositorio dentro del perímetro y atender exigencias de residencia de datos bajo la LGPD y las normas del Banco Central. El efecto colateral es que muchas de estas instancias quedan accesibles por internet para permitir trabajo remoto e integración con pipelines de entrega.
Un SSRF sin autenticación en este contexto pesa más que el promedio. GitHub Enterprise Server está relacionado con secretos de CI/CD, runners de construcción y registros internos de artefactos. Una credencial filtrada por este camino no solo abre un repositorio: abre la cadena que compila y empaqueta el software que va a producción. Para una consultoría que hospeda el código de decenas de clientes en la misma instancia, el cálculo del impacto es inmediato, y el incidente de uno se convierte en incidente de todos.
La recomendación práctica no depende de que se haya observado una explotación. Las brechas pre-autenticación alcanzables a través de la red entran en la parte superior de la lista por definición, y la ventana entre la publicación del aviso y el escaneo masivo de servidores expuestos suele medirse en días. Quien opera GHES orientado a internet debería tratar la actualización a la versión corregida como tarea de la semana y, en paralelo, revisar qué tokens de servicio estuvieron al alcance del endpoint vulnerable. El parche cierra la puerta; la rotación de credenciales aborda la pregunta que el parche no responde, la de quién ya ha pasado por ella.