Alerta de CISA: GitLab expone decenas de miles de instancias y exige parche inmediato por CVE-2021-39935 SSRF

La Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) ha dado un ultimátum: los organismos federales deben parchear sus instancias de GitLab por una vulnerabilidad que fue corregida hace años pero que ahora está siendo explotada activamente en entornos reales. Se trata de una falla de tipo SSRF (Server-Side Request Forgery) conocida como CVE-2021-39935, que GitLab solucionó originalmente en diciembre de 2021.

En aquella corrección, GitLab explicó que el problema afectaba al API de CI Lint, la herramienta que permite validar y simular pipelines de CI/CD, y que en ciertas configuraciones—cuando el registro de usuarios estaba limitado—usuarios externos sin privilegios podían ejecutar solicitudes desde el servidor. El aviso técnico original está disponible en la nota de seguridad de GitLab de diciembre de 2021: GitLab Security Release (06‑12‑2021), y el detalle del CVE puede consultarse en la base de datos del NVD: CVE-2021-39935 (NVD).

Lo que ha vuelto a encender las alarmas es que CISA ha incluido esta vulnerabilidad en su catálogo de vulnerabilidades conocidas y explotadas en el mundo real, y ha impuesto un plazo a las agencias civiles federales para que implementen parches: tres semanas desde la notificación, con fecha límite el 24 de febrero de 2026, conforme a la directiva operativa vinculante BOD 22‑01. El mensaje de CISA es claro: estas fallas siguen siendo una puerta de entrada frecuente para actores maliciosos y requieren atención inmediata. La inclusión en el catálogo de CISA puede consultarse aquí: CISA — alerta sobre CVE‑2021‑39935, y la lista pública de vulnerabilidades explotadas está en: Known Exploited Vulnerabilities Catalog. La directiva que obliga a tomar medidas también puede revisarse en la página de CISA sobre BOD 22‑01: Binding Operational Directive 22‑01.

Más allá del marco federal, CISA ha instado a empresas y organizaciones privadas a priorizar la remediación, porque la exposición es real y cuantificable. El motor de búsqueda de dispositivos conectados Shodan muestra decenas de miles de instancias con la huella de GitLab accesible públicamente: más de 49,000 resultados y casi 27,000 respondiendo por defecto en el puerto 443, según búsquedas públicas de Shodan. Búsqueda GitLab en Shodan y resultados en puerto 443.

Es fácil ver por qué la prioridad es alta: GitLab es una plataforma muy extendida en el mundo del desarrollo. La compañía declara decenas de millones de usuarios y una presencia importante entre grandes empresas, por lo que una vulnerabilidad en su superficie de gestión y CI/CD tiene potencial de impacto masivo. Más información sobre la presencia de GitLab en el sector está en su sitio corporativo: About GitLab.

¿Qué deben hacer los responsables técnicos y de seguridad? El primer paso es obvio y urgente: actualizar a las versiones corregidas de GitLab, siguiendo las indicaciones del propio fabricante. Si la actualización no es inmediata, aplicar mitigaciones oficiales, restringir el acceso a las APIs expuestas y minimizar la exposición de instancias públicas son medidas temporales necesarias. También conviene auditar los registros, rotar credenciales que hayan podido quedar comprometidas y revisar reglas de firewall y controles de acceso para impedir que servicios internos reciban peticiones forzadas desde componentes expuestos.

En la práctica esto puede implicar deshabilitar el acceso público al API de CI Lint si no es estrictamente necesario, desplegar listas blancas de IP, forzar autenticación reforzada en paneles administrativos y supervisar patrones inusuales en tráfico y ejecuciones de pipelines. Si un equipo detecta actividad sospechosa y no puede mitigar la falla, la opción responsable es dejar de usar temporalmente la instancia afectada hasta aplicar la corrección o moverse a una alternativa segura.

La aparición de exploits efectivos contra un defecto corregido años atrás recuerda una lección clásica en ciberseguridad: las correcciones solo son efectivas si se aplican. Una vulnerabilidad parcheada sigue siendo peligrosa mientras existan instalaciones sin actualizar. La presión de CISA sobre entidades federales busca reducir ese gap, pero la responsabilidad recae también en administradores de sistemas y proveedores externos para mantener actualizados sus entornos de desarrollo y entrega continua.

Finalmente, conviene situar este episodio en un contexto más amplio: esta misma semana CISA ha estado emitiendo varias advertencias y ordenando parches por otras fallas críticas explotadas en el terreno. Para equipos de seguridad esto significa priorizar la gestión de parches, identificar activos expuestos y establecer procesos que acorten el tiempo entre la publicación de un parche y su despliegue efectivo.

Si quieres leer las fuentes oficiales citadas en este artículo, aquí están los enlaces principales: la nota de GitLab sobre la corrección (GitLab — Security Release), el registro del CVE en el NVD (NVD — CVE‑2021‑39935), la alerta de CISA que incorpora la vulnerabilidad al catálogo (CISA — alerta (03‑02‑2026)), la lista pública de vulnerabilidades explotadas (KEV Catalog) y una vista de la exposición en Shodan (Shodan — GitLab).

La recomendación final es sencilla: no confiar en que un parche antiguo ya no sea relevante. Si tu organización corre GitLab, comprueba versiones y aplica las correcciones cuanto antes. La industria y las agencias gubernamentales lo están haciendo; ahora le toca al resto.