[{"data":1,"prerenderedAt":237},["ShallowReactive",2],{"seo-verification":3,"blog-gitlab-severidad-maxima-actualizar-instancia-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-gitlab-severidad-maxima-actualizar-instancia-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":179,"ctaBody":180,"ctaButton":181,"ctaUrl":182,"relatedPosts":183},518,"gitlab-severidad-maxima-actualizar-instancia",{"fr":12,"en":13,"ar":14,"es":10},"gitlab-severite-maximale-mettre-a-jour-instance","gitlab-maximum-severity-update-self-managed-instance","gitlab-ثغرة-خطورة-قصوى-تحديث-النسخة","GitLab CVE-2026-110264: actualice su instancia autoalojada","GitLab CVE-2026-110264 (CVSS 10.0): versión corregida por rama, copia de seguridad, actualización Omnibus o Docker y revisión de rastros de compromiso.",11,0,false,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fgitlab-severite-maximale-mettre-a-jour-instance-poster.svg","El 21 de octubre de 2026, GitLab publicó correcciones para CVE-2026-110264, un fallo con nota 10.0 que permite ejecutar código en el servidor sin autenticación. Las correcciones del 12 de octubre no bastan y no existe ninguna medida alternativa: solo la actualización protege una instancia autoalojada. Esta guía le da la versión que debe instalar según su rama, la copia de seguridad previa, los comandos para Omnibus y Docker y las comprobaciones posteriores. En un único nodo sin parada intermedia basta una sesión; si no, prevea más tiempo.",[35,39,79,82,104,107,128,132,135,144,162,165,173,176],{"type":36,"title":37,"body":38},"h2","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\u002FAC:L\u002FPR:N\u002FUI:N\u002FS:C\u002FC:H\u002FI:H\u002FA: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.\n\nVarios 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\u002FCD. 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.",{"type":40,"title":41,"headers":42,"rows":46},"comparison","Qué versión instalar según su rama",[43,44,45],"Su rama","Estado","Versión que instalar",[47,51,55,59,63,67,71,75],[48,49,50],"19.5.x","Afectada antes de 19.5.1","19.5.1",[52,53,54],"19.4.x","Afectada antes de 19.4.3, incluida 19.4.2","19.4.3",[56,57,58],"19.3.x","Afectada antes de 19.3.6, incluida 19.3.5","19.3.6",[60,61,62],"19.2.x","Afectada antes de 19.2.9, incluida 19.2.8","19.2.9",[64,65,66],"19.1.x","Afectada antes de 19.1.9","19.1.9",[68,69,70],"19.0.x","Afectada antes de 19.0.10","19.0.10",[72,73,74],"18.11.x","Afectada antes de 18.11.13","18.11.13",[76,77,78],"Versión anterior a 18.11","Afectada, el rango empieza en 7.0","Seguir la ruta de actualización oficial hasta una rama corregida",{"type":36,"title":80,"body":81},"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á.\n\nEl 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.",{"type":83,"title":84,"steps":85},"steps","Comprobar su versión y preparar la ventana",[86,89,92,95,98,101],{"title":87,"body":88},"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 \u002Fopt\u002Fgitlab\u002Fversion-manifest.txt`. Anote el número completo, no solo la rama.",{"title":90,"body":91},"Identificar la edición instalada","`dpkg -l | grep gitlab` en Debian y Ubuntu, `rpm -q gitlab-ce gitlab-ee` en RHEL y AlmaLinux. El nombre del paquete, `gitlab-ce` o `gitlab-ee`, decide el comando de actualización. Las dos ediciones están afectadas.",{"title":93,"body":94},"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.",{"title":96,"body":97},"Controlar el espacio en disco","`df -h \u002Fvar\u002Fopt\u002Fgitlab`. 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.",{"title":99,"body":100},"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`.",{"title":102,"body":103},"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.",{"type":36,"title":105,"body":106},"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 `\u002Fetc\u002Fgitlab\u002Fskip-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.\n\nLa trampa clásica: esta copia no contiene la configuración. Copie aparte `\u002Fetc\u002Fgitlab\u002Fgitlab-secrets.json` y `\u002Fetc\u002Fgitlab\u002Fgitlab.rb`, por ejemplo con `sudo mkdir -p \u002Froot\u002Fgitlab-config-backup && sudo cp -a \u002Fetc\u002Fgitlab\u002Fgitlab-secrets.json \u002Fetc\u002Fgitlab\u002Fgitlab.rb \u002Froot\u002Fgitlab-config-backup\u002F`. Sin `gitlab-secrets.json`, una restauración deja ilegibles los datos cifrados, como las variables CI\u002FCD 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.",{"type":83,"title":108,"steps":109},"Actualizar según su instalación",[110,113,116,119,122,125],{"title":111,"body":112},"Debian y Ubuntu (paquete Omnibus)","`sudo apt update && sudo apt install gitlab-ce=\u003Cversion>-ce.0`\nSustituya `\u003Cversion>` por la versión de la tabla para su rama. Para la edición Enterprise: `sudo apt install gitlab-ee=\u003Cversion>-ee.0`.",{"title":114,"body":115},"RHEL, AlmaLinux y Oracle Linux","`sudo dnf install gitlab-ce-\u003Cversion>-ce.0.el9`\nUse `.el8` en una máquina de versión 8, y `gitlab-ee-\u003Cversion>-ee.0.el9` para la edición Enterprise.",{"title":117,"body":118},"Docker con docker run","`sudo docker stop gitlab`\n`sudo docker rm gitlab`\n`sudo docker pull gitlab\u002Fgitlab-ce:\u003Cversion>-ce.0`\nVuelva a lanzar `docker run` con exactamente sus opciones originales: mismos puertos, mismos volúmenes para `config`, `logs` y `data`, mismo `--shm-size`. Los datos viven en los volúmenes, no en el contenedor eliminado.",{"title":120,"body":121},"Docker con Compose","Edite la etiqueta de la imagen en `docker-compose.yml` para apuntar a `\u003Cversion>-ce.0` y después:\n`docker compose pull`\n`docker compose up -d`\n`docker compose logs -f gitlab`\nSi su archivo usa una etiqueta flotante, fíjela: una versión anclada hace legible la próxima actualización.",{"title":123,"body":124},"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 con `sudo gitlab-ctl reconfigure`. Deje que las migraciones lleguen al final antes de concluir que la instancia está bloqueada.",{"title":126,"body":127},"Comprobar el resultado","`sudo gitlab-ctl status`\n`sudo gitlab-rake gitlab:env:info`\nLa 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.",{"type":129,"title":130,"body":131},"tip","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.",{"type":36,"title":133,"body":134},"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.\n\nLo 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.",{"type":136,"title":137,"items":138},"ul","Mientras se prepara la ventana: reducir la exposición, sin ilusiones",[139,140,141,142,143],"**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.",{"type":83,"title":145,"steps":146},"Revisar los rastros tras la actualización",[147,150,153,156,159],{"title":148,"body":149},"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.",{"title":151,"body":152},"Releer los registros de GitLab","`sudo ls -la \u002Fvar\u002Flog\u002Fgitlab` y luego `sudo 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.",{"title":154,"body":155},"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.",{"title":157,"body":158},"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.",{"title":160,"body":161},"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.",{"type":36,"title":163,"body":164},"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\u002FCD, 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.",{"type":136,"title":166,"items":167},"Solución de problemas: bloqueos frecuentes",[168,169,170,171,172],"**`E: Version '\u003Cversion>-ce.0' for 'gitlab-ce' was not found`** — apt aún no conoce ese número: vuelva a ejecutar `sudo 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 tail` y no reinicie los servicios a mano hasta que terminen.","**Contenedor iniciado pero vacío** — se volvió a lanzar `docker run` sin los volúmenes originales. Deténgalo y vuelva a crearlo con las mismas rutas para `config`, `logs` y `data`.","**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.",{"type":36,"title":174,"body":175},"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.",{"type":36,"title":177,"body":178},"La documentación oficial","Aviso de la versión correctiva GitLab 19.5.1: https:\u002F\u002Fdocs.gitlab.com\u002Freleases\u002Fpatches\u002Fpatch-release-gitlab-19-5-1-released\u002F\n\nAviso del 12 de octubre de 2026: https:\u002F\u002Fdocs.gitlab.com\u002Freleases\u002Fpatches\u002Fpatch-release-gitlab-19-4-2-released\u002F\n\nActualización de un paquete Linux: https:\u002F\u002Fdocs.gitlab.com\u002Fupdate\u002Fpackage\u002F\n\nActualización de una instalación Docker: https:\u002F\u002Fdocs.gitlab.com\u002Finstall\u002Fdocker\u002Fupgrade\u002F\n\nCopia de seguridad de GitLab: https:\u002F\u002Fdocs.gitlab.com\u002Fadministration\u002Fbackup_restore\u002Fbackup_gitlab\u002F\n\nCrónica de BleepingComputer: https:\u002F\u002Fwww.bleepingcomputer.com\u002Fnews\u002Fsecurity\u002Fgitlab-warns-of-new-max-severity-code-execution-vulnerability\u002F","Una forja en un servidor que es realmente suyo","Un VPS con acceso root le permite elegir su ventana de actualización, sus copias de seguridad y sus registros. Si no quiere encargarse usted mismo de la actualización, está disponible la opción de administración VPS, y support@servorbit.com atiende sus preguntas.","Ver la solución para desarrolladores","\u002Fsolutions\u002Fdeveloppeurs",[184,203,223],{"id":185,"slug":186,"slugs":187,"title":191,"excerpt":192,"readTime":193,"views":18,"isPinned":19,"publishedAt":194,"updatedAt":195,"category":196,"categories":197,"featuredImage":30,"bgImage":31,"posterImage":199,"relatedSolution":200},365,"cve-2026-85706-gitlab-parche-urgente-o-migracion-gitea",{"fr":188,"en":189,"ar":190,"es":186},"gitlab-cve-2026-85706-migration-gitea-vps","cve-2026-85706-gitlab-emergency-patch-or-gitea-migration","cve-2026-85706-gitlab-تصحيح-عاجل-أو-هجرة-إلى-gitea","CVE-2026-85706 GitLab: parche urgente o migración a Gitea","CVE-2026-85706 (CVSS 10.0) expone secrets.yml y claves SSH en GitLab 18.7–19.3.1. Actualiza a 19.3.2 inmediatamente o migra a Gitea en un VPS.",9,"2026-09-19T00:00:00+00:00","2026-10-20T23:18:06+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[198],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fgitlab-cve-2026-85706-migration-gitea-vps-poster.svg",{"categorySlug":201,"appSlug":202},"desarrollo","gitea",{"id":204,"slug":205,"slugs":206,"title":210,"excerpt":211,"readTime":212,"views":213,"isPinned":19,"publishedAt":214,"updatedAt":215,"category":216,"categories":220,"featuredImage":30,"bgImage":31,"posterImage":222,"relatedSolution":30},235,"instalar-gitlab-ce-en-un-vps-guia-completa",{"fr":207,"en":208,"ar":209,"es":205},"installer-gitlab-ce-vps","install-gitlab-ce-on-a-vps-complete-guide","تثبيت-gitlab-ce-على-vps-دليل-شامل","Instalar GitLab CE en un VPS: guía completa","Despliegue GitLab CE en un VPS con Docker Compose. Incluye CVE-2026-90970 (CVSS 9.9): RCE en AI Gateway, versiones vulnerables y comandos de actualización.",18,3,"2026-08-07T00:00:00+00:00","2026-10-20T23:18:07+00:00",{"id":213,"name":217,"slug":218,"color":219,"icon":218},"Despliegue","deploiement","bg-success\u002F10 text-success",[221],{"id":213,"name":217,"slug":218,"color":219,"icon":218},"\u002Fblog\u002Fcovers\u002Finstaller-gitlab-ce-vps-poster.svg",{"id":224,"slug":225,"slugs":226,"title":230,"excerpt":231,"readTime":17,"views":18,"isPinned":19,"publishedAt":232,"updatedAt":195,"category":233,"categories":234,"featuredImage":30,"bgImage":31,"posterImage":236,"relatedSolution":30},347,"estrategia-3-2-1-backup-vps-restic-s3",{"fr":227,"en":228,"ar":229,"es":225},"backup-vps-restic-s3-3-2-1","restic-s3-3-2-1-backup-strategy-vps","restic-s3-3-2-1-backup-strategy-vps-ar","Estrategia 3-2-1 para tu VPS con Restic y S3","Construye una estrategia 3-2-1 completa en tu VPS: Restic hacia Backblaze B2 o Cloudflare R2, timer systemd, política de retención y prueba de restauración automatizada.","2026-09-10T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[235],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fbackup-vps-restic-s3-3-2-1-poster.svg",1793251456371]