GitLab corrigió una vulnerabilidad crítica (CVE-2026-110264, CVSS 10) que permite a un atacante sin credenciales ejecutar código en el servidor. Afecta a GitLab Community y Enterprise Editions desde la versión 7.0. Actualiza cuanto antes, partiendo por las instancias expuestas a Internet, y revisa si hubo intentos de explotación.
Qué está pasando
El 21 de octubre de 2026, GitLab publicó un aviso de seguridad que corrige varias vulnerabilidades en sus ediciones Community (CE) y Enterprise (EE). La más grave, CVE-2026-110264, tiene un puntaje CVSS de 10, el máximo posible.
Se trata de un desbordamiento de entero (integer overflow) en el compilador de expresiones regulares. Un usuario sin autenticación puede aprovecharlo para ejecutar código arbitrario en el servidor GitLab afectado; es decir, podría tomar el control del servidor que aloja tu código fuente, tus pipelines y sus credenciales.
En el mismo aviso, GitLab corrigió además 2 vulnerabilidades de gravedad alta, 5 de gravedad media y 4 de gravedad baja. El boletín no detalla esas fallas adicionales ni indica que exista explotación activa o código de prueba público.
GitLab también publicó dos reglas de detección para identificar intentos de explotación, que conviene aplicar para evaluar si un servidor pudo haber sido comprometido.
Vulnerabilidades
| CVE | CVSS | Descripción |
|---|---|---|
| CVE-2026-110264 | 10 | Desbordamiento de entero en el compilador de expresiones regulares de GitLab que permite a un usuario no autenticado ejecutar código arbitrario en el servidor. |
Productos afectados
| Producto | Versiones afectadas | Versión corregida |
|---|---|---|
| GitLab Community y Enterprise Editions | Desde 7.0 hasta antes de 18.11.13 | 18.11.13 |
| GitLab Community y Enterprise Editions | 19.0 antes de 19.0.10 | 19.0.10 |
| GitLab Community y Enterprise Editions | 19.1 antes de 19.1.9 | 19.1.9 |
| GitLab Community y Enterprise Editions | 19.2 antes de 19.2.9 | 19.2.9 |
| GitLab Community y Enterprise Editions | 19.3 antes de 19.3.6 | 19.3.6 |
| GitLab Community y Enterprise Editions | 19.4 antes de 19.4.3 | 19.4.3 |
| GitLab Community y Enterprise Editions | 19.5 antes de 19.5.1 | 19.5.1 |
Qué hacer ahora
- Identifica todas las instancias de GitLab CE y EE de tu organización y verifica qué versión tiene cada una.
- Actualiza de inmediato las instancias expuestas a Internet a la versión corregida de su rama (18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 o 19.5.1).
- Actualiza después el resto de las instancias internas a la versión corregida correspondiente.
- Realiza una evaluación de compromiso aplicando las dos reglas de detección publicadas por GitLab (
onigmo_native_worker_crashyorg_mode_render_error_burst) para detectar intentos de explotación.
Te ayudamos a revisar sin costo si tus servidores o equipos usan una versión afectada por esta alerta, y qué conviene hacer primero.
Un servidor GitLab concentra mucho más que código: suele guardar tokens de despliegue, variables de CI/CD con contraseñas y claves de acceso a la nube o a producción. Con un CVSS de 10 y sin necesidad de credenciales, trata esta actualización como urgente y no la dejes para la próxima ventana de mantenimiento. Revisa primero si tu instancia es accesible desde Internet; muchas empresas la publican para que trabajen proveedores o equipos remotos y lo olvidan.
Además de parchear, revisa los registros con las reglas de detección de GitLab. Si encuentras indicios de explotación, asume que los secretos almacenados pudieron filtrarse: rota tokens, claves SSH y variables de CI/CD, y revisa los runners conectados. Si usas una versión antigua fuera de soporte, planifica la migración a una rama vigente, porque las ramas viejas suelen quedarse sin parches.
Cómo te ayuda UpTech
Mientras aplicas la actualización, podemos definir en Cerberus WAF reglas específicas para las rutas y parámetros vulnerables de tu sitio. Reduce la exposición, pero no reemplaza el parche.
Conocer el servicio → Servicios Gestionados TICon Gestión de Parches, las actualizaciones de seguridad de sistemas operativos y aplicaciones se aplican de forma programada, sin depender de que alguien lea esta alerta a tiempo.
Conocer el servicio → Respaldo y MonitoreoLos respaldos inmutables (RPO desde 15 minutos) te dejan un punto de restauración limpio si la falla llega a ser explotada.
Conocer el servicio →Referencias
- https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
- https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/onigmo_native_worker_crash.md?ref_type=heads
- https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md?ref_type=heads