Introducción
Durante años, los equipos de datos y los equipos de desarrollo de software operaron en infraestructuras separadas. Los primeros orquestaban sus procesos mediante schedulers dedicados, scripts shell o plataformas ETL propietarias. Los segundos vivían entre repositorios git, pipelines CI/CD y registros de contenedores. Ambos mundos se han fusionado progresivamente: los equipos de data engineering han adoptado GitLab de forma masiva como columna vertebral de sus pipelines — dbt, Apache Spark, ingestión en tiempo real, pruebas de calidad de datos, despliegue de modelos. Y con esa convergencia llega un riesgo que pocas organizaciones han mapeado con claridad.
Una brecha en el corazón del motor CI/CD
El 12 de octubre de 2026, GitLab divulgó la CVE-2026-97229, una vulnerabilidad de severidad máxima (CVSS 10.0) que afecta al compilador de expresiones regulares integrado en su motor CI/CD. La falla — un desbordamiento de entero (integer overflow) — reside en el componente que analiza, compila y evalúa las expresiones regulares presentes en los archivos de configuración de pipelines.
En términos prácticos: cuando el compilador calcula la memoria necesaria para procesar los estados y transiciones de una expresión regular, un desbordamiento aritmético puede producir un tamaño muy inferior al real. El motor asigna entonces un espacio insuficiente, escribe más allá de los límites del búfer y abre la puerta a la ejecución de código arbitrario en el servidor. El análisis de Rapid7 precisa que la explotación práctica requiere derechos de contribución sobre un proyecto público — condición fácilmente satisfecha en las instancias self-managed que permiten la creación de proyectos abiertos, configuración habitual en muchos despliegues empresariales.
Están afectadas todas las instalaciones de GitLab CE y EE en las versiones 19.2, 19.3 y 19.4 anteriores a los parches (19.2.8, 19.3.5 y 19.4.2 respectivamente). Las instancias de GitLab.com y GitLab Dedicated fueron corregidas desde el momento de la divulgación.
El problema real: qué almacenan los pipelines de datos
Para un equipo de data engineering, el archivo .gitlab-ci.yml no es un simple archivo de build. Concentra las variables CI/CD que alimentan las conexiones a los almacenes de datos (Snowflake, BigQuery, Redshift), las claves de acceso a los buckets de almacenamiento de objetos, los tokens de autenticación hacia los catálogos de datos, los secretos de los registros de contenedores que alojan las imágenes de procesamiento, y las claves de despliegue en la nube.
Un atacante que ejecute código en el servidor de GitLab no compromete únicamente el repositorio fuente. Accede a la totalidad de las variables secretas de los pipelines, puede inyectar modificaciones silenciosas en los jobs de transformación o desviar los flujos de datos antes de que lleguen a las capas de reporting. En una arquitectura de datos moderna donde GitLab orquesta la ingestión, la transformación y la publicación, la superficie de exposición supera con creces el perímetro DevOps tradicional.
Lo que los equipos de datos deben hacer ahora
La prioridad absoluta es actualizar las instancias self-managed a las versiones 19.4.2, 19.3.5 o 19.2.8. GitLab no ha documentado ninguna medida de mitigación alternativa: la actualización es la única remediación disponible.
Más allá del parche inmediato, varios aspectos merecen revisión en las próximas semanas:
- Rotación de secretos: renovar las variables CI/CD que dan acceso a los sistemas de datos críticos, las claves de nube y los tokens de API, sin esperar a confirmar si ha existido explotación
- Revisión de derechos de contribución en los proyectos públicos o semi-abiertos que alojan pipelines de datos
- Externalización hacia un vault dedicado para las credenciales más sensibles, en lugar de almacenarlas de forma nativa en las variables de GitLab
- Monitoreo de procesos hijos lanzados desde los componentes del servidor GitLab, señal temprana de una explotación no detectada
La convergencia datos-DevOps exige una gobernanza unificada
Esta vulnerabilidad pone de manifiesto una brecha de madurez frecuente: los equipos de datos han adoptado las herramientas DevOps sin integrar siempre las prácticas de seguridad que las acompañan. A medida que los pipelines de datos se convierten en infraestructura crítica — alimentando dashboards ejecutivos, modelos de scoring o flujos de reporting regulatorio —, su seguridad no puede seguir delegándose por defecto al equipo de plataforma. El archivo de configuración CI/CD se ha convertido, queramos o no, en una pieza de gobernanza de datos de pleno derecho.