Qué corrige la publicación de GitLab de octubre de 2026
El 21 de octubre de 2026, GitLab publicó una versión correctiva crítica para sus ediciones Community y Enterprise. CVE-2026-110264 es un desbordamiento de entero en el compilador de expresiones regulares: según el aviso, un usuario no autenticado podría ejecutar código arbitrario en el servidor GitLab. El vector CVSS 3.1 que indica una fuente secundaria es AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, es decir, exposición de red, sin autenticación y sin interacción del usuario. Las versiones afectadas van desde la 7.0 hasta la versión corregida de cada rama.
Varios fallos circulan ahora alrededor del motor de expresiones regulares de GitLab y es fácil confundirlos. CVE-2026-97229, corregida el 12 de octubre de 2026 en las versiones 19.4.2, 19.3.5 y 19.2.8, afectaba al compilador de regex de las configuraciones CI/CD. Esas tres versiones siguen siendo vulnerables a CVE-2026-110264. CVE-2026-85706, un salto de directorio ya explotado, es otro asunto, tratado en nuestro artículo sobre el parche de urgencia o la migración a Gitea. Atención: la versión 19.3.2 que cita como corregida es en sí misma vulnerable a CVE-2026-110264, porque la rama 19.3 solo queda protegida desde 19.3.6. La misma publicación corrige otros once fallos, de gravedad alta a baja: también justifican la actualización, pero no cambian el procedimiento.
Qué versión instalar según su rama
Desplace la tabla
| Su rama | Estado | Versión que instalar |
|---|---|---|
| 19.5.x | Afectada antes de 19.5.1 | 19.5.1 |
| 19.4.x | Afectada antes de 19.4.3, incluida 19.4.2 | 19.4.3 |
| 19.3.x | Afectada antes de 19.3.6, incluida 19.3.5 | 19.3.6 |
| 19.2.x | Afectada antes de 19.2.9, incluida 19.2.8 | 19.2.9 |
| 19.1.x | Afectada antes de 19.1.9 | 19.1.9 |
| 19.0.x | Afectada antes de 19.0.10 | 19.0.10 |
| 18.11.x | Afectada antes de 18.11.13 | 18.11.13 |
| Versión anterior a 18.11 | Afectada, el rango empieza en 7.0 | Seguir la ruta de actualización oficial hasta una rama corregida |
Está expuesto: la lectura que lo decide
La pregunta no es si su instancia es importante, sino si está autoalojada y por debajo de la versión corregida de su rama. GitLab.com ya está corregido, y los inquilinos de GitLab Dedicated en 19.3.5-internal0 o 19.4.2-internal0 y posteriores ya incluyen las correcciones. Para cualquier instalación que administre usted mismo, en un VPS o en un servidor dedicado, la respuesta es simple: compruebe el número de versión y compárelo con la tabla anterior. Una instancia en 19.4.2 suele creerse al día porque recibió la corrección del 12 de octubre. No lo está.
El aviso no menciona ninguna configuración que anule el fallo. Una instancia accesible desde Internet es evidentemente la más urgente, pero una instancia interna tampoco queda fuera del alcance de un equipo comprometido de la red. En el momento de redactar esto, GitLab no informa de ninguna explotación de CVE-2026-110264 y, según las fuentes consultadas, el fallo no figura en el catálogo de vulnerabilidades explotadas de CISA. Es una ventana para actuar con calma, no un motivo para aplazar.
Comprobar su versión y preparar la ventana
Leer la versión exacta
En la interfaz, el menú de ayuda muestra la versión. En línea de comandos:
sudo gitlab-rake gitlab:env:info. En Docker:docker exec gitlab cat /opt/gitlab/version-manifest.txt. Anote el número completo, no solo la rama.Identificar la edición instalada
dpkg -l | grep gitlaben Debian y Ubuntu,rpm -q gitlab-ce gitlab-eeen RHEL y AlmaLinux. El nombre del paquete,gitlab-ceogitlab-ee, decide el comando de actualización. Las dos ediciones están afectadas.Verificar la ruta de actualización
Salte directamente a la versión corregida solo si no se exige ninguna parada intermedia. GitLab precisa que no se puede subir de golpe a la última versión mayor cuando la ruta impone paradas. En ese caso, instale cada parada con su número exacto. La herramienta de ruta de actualización de la documentación oficial da la lista.
Controlar el espacio en disco
df -h /var/opt/gitlab. El archivo de copia de seguridad y las migraciones necesitan espacio. Una partición casi llena es la primera causa de una actualización interrumpida a mitad.Anunciar el corte
En un único nodo, GitLab avisa de que las migraciones deben terminar antes del arranque: la indisponibilidad es normal. Avise a los equipos, deje terminar los pipelines en curso y anote el estado de los runners con
sudo gitlab-ctl status.Guardar una salida de emergencia
Mantenga abierta una segunda sesión SSH y el número de la versión actual. Si una parada falla, sabrá exactamente a qué versión volver y qué archivo restaurar.
La copia de seguridad primero, y lo que no incluye
El paquete respalda la base de datos automáticamente antes de instalar una versión más reciente. Aun así, GitLab recomienda conservar su propia copia completa y actualizada, y conviene no desactivar ese paso automático (existe para ello el archivo vacío /etc/gitlab/skip-auto-backup). El comando es sudo gitlab-backup create, o docker exec -t gitlab gitlab-backup create para un contenedor llamado gitlab. El archivo es un único .tar, que el parámetro backup_path coloca en local.
La trampa clásica: esta copia no contiene la configuración. Copie aparte /etc/gitlab/gitlab-secrets.json y /etc/gitlab/gitlab.rb, por ejemplo con sudo mkdir -p /root/gitlab-config-backup && sudo cp -a /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /root/gitlab-config-backup/. Sin gitlab-secrets.json, una restauración deja ilegibles los datos cifrados, como las variables CI/CD y los secretos de autenticación en dos pasos. Después saque ambas copias de la máquina, a un almacenamiento distinto. Solo es posible volver atrás con una copia de la base tomada en la misma versión y edición que la que restaura.
Actualizar según su instalación
Debian y Ubuntu (paquete Omnibus)
sudo apt update && sudo apt install gitlab-ce=<version>-ce.0
Sustituya<version>por la versión de la tabla para su rama. Para la edición Enterprise:sudo apt install gitlab-ee=<version>-ee.0.RHEL, AlmaLinux y Oracle Linux
sudo dnf install gitlab-ce-<version>-ce.0.el9
Use.el8en una máquina de versión 8, ygitlab-ee-<version>-ee.0.el9para la edición Enterprise.Docker con docker run
sudo docker stop gitlabsudo docker rm gitlabsudo docker pull gitlab/gitlab-ce:<version>-ce.0
Vuelva a lanzardocker runcon exactamente sus opciones originales: mismos puertos, mismos volúmenes paraconfig,logsydata, mismo--shm-size. Los datos viven en los volúmenes, no en el contenedor eliminado.Docker con Compose
Edite la etiqueta de la imagen en
docker-compose.ymlpara apuntar a<version>-ce.0y después:docker compose pulldocker compose up -ddocker compose logs -f gitlab
Si su archivo usa una etiqueta flotante, fíjela: una versión anclada hace legible la próxima actualización.Aplicar la configuración
En Docker, GitLab se reconfigura y se actualiza en el primer arranque del contenedor. En una instalación por paquete, tras cualquier cambio en
gitlab.rb, aplíquelo consudo gitlab-ctl reconfigure. Deje que las migraciones lleguen al final antes de concluir que la instancia está bloqueada.Comprobar el resultado
sudo gitlab-ctl statussudo gitlab-rake gitlab:env:info
La versión mostrada debe ser la de la tabla. Abra la interfaz, verifique que un repositorio se clona, que un pipeline arranca y que los runners se reconectan.
Ensaye en una copia cuando la instancia es crítica
Restaure la copia de seguridad en una máquina desechable de la misma versión, actualícela y cronometre las migraciones. Obtiene la duración real del corte y descubre las sorpresas sin tocar producción. Destruya la copia después: contiene sus secretos.
Indisponibilidad, migraciones, rutas antiguas: los tres temores
Actualizar una forja en producción da miedo por razones concretas, y el aviso de GitLab las responde sin rodeos. Migraciones de base de datos: la publicación incluye algunas, ordinarias en 19.4.3 y 19.3.6, y posteriores al despliegue en 19.4.3. Corte: en un único nodo es esperable, porque las migraciones deben terminar antes del arranque; en varios nodos se aplican los procedimientos de actualización sin interrupción. Versiones antiguas: por debajo de 18.11, siga la ruta de actualización oficial, parada por parada, sin saltarse ninguna.
Lo que no pierde, si la copia de seguridad existe: sus repositorios, sus incidencias, sus runners registrados y sus tokens. El miedo a romperlo todo es legítimo, pero esperar es la apuesta más arriesgada, porque el detalle técnico del fallo debe hacerse público en el seguimiento de incidencias 90 días después de la publicación de la corrección. Más vale actualizar antes de ese día.
Mientras se prepara la ventana: reducir la exposición, sin ilusiones
- Sin medida alternativa oficial — el aviso de GitLab no enumera ninguna mitigación: la única es la actualización.
- Restringir el acceso de red — limitar la instancia a su VPN o a una lista de direcciones reduce los atacantes posibles. No es una medida oficial, solo una medida de espera.
- No inventar una regla de filtrado — ningún filtro nginx publicado cubre este fallo: escribir uno de memoria da una falsa sensación de protección.
- Vigilar desde ya — aplique las dos reglas de detección publicadas por GitLab, presentadas más abajo, para saber si alguien ya ha intentado algo.
- Fijar una fecha límite — anote en el equipo una fecha de actualización: una medida de espera sin fecha se convierte en costumbre.
Revisar los rastros tras la actualización
Aplicar las dos reglas de detección
GitLab publica dos reglas para instancias autoalojadas: "Onigmo native worker crash" y "Org mode render error burst". Tómelas del aviso oficial para su herramienta de supervisión o de registros.
Releer los registros de GitLab
sudo ls -la /var/log/gitlaby luegosudo gitlab-ctl tail. Busque caídas repetidas de procesos de trabajo y errores de renderizado concentrados en un periodo corto, alrededor del 21 de octubre o antes.Revisar cuentas y tokens
En el área de administración, revise los usuarios recientes, los administradores, los tokens de acceso personal y las claves de despliegue. Todo lo que no tenga un autor conocido merece una explicación.
Revisar runners y proyectos
Liste los runners registrados y los webhooks. Un runner desconocido o un hook añadido recientemente es una puerta de entrada clásica tras una toma de control.
Conservar los registros
Copie los registros útiles fuera de la máquina antes de dejarlos rotar. Si surge una duda dentro de una semana, tendrá con qué comparar.
Si persiste la duda: tratar la instancia como comprometida
La ausencia de alerta no prueba la ausencia de compromiso: las dos reglas de GitLab detectan síntomas, no todas las intrusiones. Si aparece un indicio (regla de detección activada, cuenta o runner desconocido, caídas agrupadas), trate la instancia como comprometida. Sin indicio, la exposición por sí sola justifica la actualización, no la rotación de todos los secretos. Si hay indicio, renueve los secretos de la instancia, las variables CI/CD, los tokens de runner y los tokens de acceso, y vuelva a registrar los runners. Una variable de pipeline que contenga una clave de despliegue o una contraseña de base de datos debe cambiarse en su origen, no solo en GitLab. Es tedioso, y es el precio de una forja que guarda su código y sus accesos de producción.
Solución de problemas: bloqueos frecuentes
E: Version '<version>-ce.0' for 'gitlab-ce' was not found— apt aún no conoce ese número: vuelva a ejecutarsudo apt update, compruebe que el repositorio de GitLab está configurado y revise la ortografía del número y el sufijo-ce.0.- No se puede subir directamente a la versión deseada — su instancia exige paradas. Instálelas una a una con su número exacto y deje terminar las migraciones entre dos.
- Página de error 502 justo después de actualizar — las migraciones siguen en curso. Espere, siga
sudo gitlab-ctl taily no reinicie los servicios a mano hasta que terminen. - Contenedor iniciado pero vacío — se volvió a lanzar
docker runsin los volúmenes originales. Deténgalo y vuelva a crearlo con las mismas rutas paraconfig,logsydata. - Restauración imposible tras una vuelta atrás — la copia debe proceder de la misma versión y de la misma edición. Restaure con la versión que la produjo y vuelva a actualizar.
Una forja en un VPS: qué cambia
Cuando su forja se ejecuta en un VPS donde tiene acceso root, usted decide la ventana de actualización, el lugar de las copias de seguridad y el tiempo de conservación de los registros. Nadie le impone un calendario y nadie actualiza en su lugar: es la contrapartida. Prevea espacio en disco para el archivo, una copia fuera de la máquina y un modo de probar una restauración, como describe nuestra guía sobre copias de seguridad con restic. Para instalar GitLab, nuestra guía de instalación de GitLab CE en un VPS da el punto de partida. Si prefiere delegar la administración del servidor, existe la opción de administración VPS; esta guía se ofrece tal cual, sin soporte para su instancia.
La documentación oficial
Aviso de la versión correctiva GitLab 19.5.1: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
Aviso del 12 de octubre de 2026: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
Actualización de un paquete Linux: https://docs.gitlab.com/update/package/
Actualización de una instalación Docker: https://docs.gitlab.com/install/docker/upgrade/
Copia de seguridad de GitLab: https://docs.gitlab.com/administration/backup_restore/backup_gitlab/
Crónica de BleepingComputer: https://www.bleepingcomputer.com/news/security/gitlab-warns-of-new-max-severity-code-execution-vulnerability/
