[{"data":1,"prerenderedAt":237},["ShallowReactive",2],{"seo-verification":3,"blog-gitlab-maximum-severity-update-self-managed-instance-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-gitlab-maximum-severity-update-self-managed-instance-en",{"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-maximum-severity-update-self-managed-instance",{"fr":12,"en":10,"ar":13,"es":14},"gitlab-severite-maximale-mettre-a-jour-instance","gitlab-ثغرة-خطورة-قصوى-تحديث-النسخة","gitlab-severidad-maxima-actualizar-instancia","GitLab CVE-2026-110264: update your self-managed instance","GitLab CVE-2026-110264 (CVSS 10.0): fixed version per branch, backup, Omnibus or Docker upgrade, then a check for traces of compromise.",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,"Security & Monitoring","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","On October 21, 2026, GitLab released fixes for CVE-2026-110264, a flaw rated 10.0 that lets an unauthenticated attacker run code on the server. The October 12 fixes are not enough, and no workaround exists: only an upgrade protects a self-managed instance. This guide gives you the version to target for your branch, the backup to take first, the commands for Omnibus and Docker, then the checks to run afterwards. On a single node with no intermediate stop, one session is enough; otherwise plan for more.",[35,39,79,82,104,107,128,132,135,144,162,165,173,176],{"type":36,"title":37,"body":38},"h2","What the GitLab release of October 2026 fixes","On October 21, 2026, GitLab released a critical patch for its Community and Enterprise editions. CVE-2026-110264 is an integer overflow in the regular expression compiler: according to the advisory, an unauthenticated user could execute arbitrary code on the GitLab server. The CVSS 3.1 vector reported by a secondary source is `AV:N\u002FAC:L\u002FPR:N\u002FUI:N\u002FS:C\u002FC:H\u002FI:H\u002FA:H`, meaning network exposure, no authentication, no user interaction. Affected versions run from 7.0 up to the fixed version of each branch.\n\nSeveral flaws are circulating around GitLab's regular expression engine right now, and they are easy to mix up. CVE-2026-97229, fixed on October 12, 2026 in versions 19.4.2, 19.3.5 and 19.2.8, targeted the regex compiler for CI\u002FCD configurations. Those three versions remain vulnerable to CVE-2026-110264. CVE-2026-85706, an already exploited path traversal, is a different matter, covered in our article on the emergency patch or the move to Gitea. Note that the version 19.3.2 it cites as fixed is itself vulnerable to CVE-2026-110264, since the 19.3 branch is only protected from 19.3.6. The same release fixes eleven other flaws, from high to low severity: they also justify the upgrade, but they do not change the procedure.",{"type":40,"title":41,"headers":42,"rows":46},"comparison","Which version to install for your branch",[43,44,45],"Your branch","Status","Version to install",[47,51,55,59,63,67,71,75],[48,49,50],"19.5.x","Affected before 19.5.1","19.5.1",[52,53,54],"19.4.x","Affected before 19.4.3, including 19.4.2","19.4.3",[56,57,58],"19.3.x","Affected before 19.3.6, including 19.3.5","19.3.6",[60,61,62],"19.2.x","Affected before 19.2.9, including 19.2.8","19.2.9",[64,65,66],"19.1.x","Affected before 19.1.9","19.1.9",[68,69,70],"19.0.x","Affected before 19.0.10","19.0.10",[72,73,74],"18.11.x","Affected before 18.11.13","18.11.13",[76,77,78],"Any version older than 18.11","Affected, the range starts at 7.0","Follow the official upgrade path to a fixed branch",{"type":36,"title":80,"body":81},"Are you exposed: the reading that settles it","The question is not whether your instance is important, but whether it is self-managed and below the fixed version of its branch. GitLab.com is already fixed, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already carry the fixes. For any installation you administer yourself, on a VPS or a dedicated server, the answer is simple: check the version number and compare it with the table above. An instance on 19.4.2 often assumes it is up to date because it received the October 12 fix. It is not.\n\nThe advisory names no configuration that would disable the flaw. An instance reachable from the Internet is obviously the most urgent, but an internal instance is not out of reach of a compromised workstation on the network. At the time of writing, GitLab reports no exploitation of CVE-2026-110264 and, according to the sources consulted, the flaw is not in the CISA catalog of exploited vulnerabilities. That is a window to act calmly, not a reason to postpone.",{"type":83,"title":84,"steps":85},"steps","Check your version and prepare the window",[86,89,92,95,98,101],{"title":87,"body":88},"Read the exact version","In the interface, the help menu shows the version. On the command line: `sudo gitlab-rake gitlab:env:info`. On Docker: `docker exec gitlab cat \u002Fopt\u002Fgitlab\u002Fversion-manifest.txt`. Write down the full number, not just the branch.",{"title":90,"body":91},"Identify the installed edition","`dpkg -l | grep gitlab` on Debian and Ubuntu, `rpm -q gitlab-ce gitlab-ee` on RHEL and AlmaLinux. The package name, `gitlab-ce` or `gitlab-ee`, decides the upgrade command. Both editions are affected.",{"title":93,"body":94},"Check the upgrade path","Jump straight to the fixed version only if no intermediate stop is required. GitLab states that you cannot upgrade directly to the latest major version when the path requires stops. In that case, install each stop with its exact number. The upgrade path tool in the official documentation gives the list.",{"title":96,"body":97},"Check disk space","`df -h \u002Fvar\u002Fopt\u002Fgitlab`. The backup archive and the migrations need room. An almost full partition is the first cause of an upgrade interrupted halfway.",{"title":99,"body":100},"Announce the outage","On a single node, GitLab warns that migrations must finish before startup: downtime is expected. Warn your teams, let running pipelines finish and note the state of the runners with `sudo gitlab-ctl status`.",{"title":102,"body":103},"Keep an exit route","Keep a second SSH session open and the current version number at hand. If a stop fails, you will know exactly which version to return to and which archive to restore.",{"type":36,"title":105,"body":106},"Back up first, and know what the backup leaves out","The package backs up the database automatically before installing a newer version. GitLab still recommends keeping your own full, up-to-date backup, and you should not disable that automatic step (the empty file `\u002Fetc\u002Fgitlab\u002Fskip-auto-backup` exists for that). The command is `sudo gitlab-backup create`, or `docker exec -t gitlab gitlab-backup create` for a container named gitlab. The archive is a single `.tar` file, placed locally by the `backup_path` setting.\n\nThe classic trap: this backup does not contain the configuration. Copy `\u002Fetc\u002Fgitlab\u002Fgitlab-secrets.json` and `\u002Fetc\u002Fgitlab\u002Fgitlab.rb` separately, for example with `sudo mkdir -p \u002Froot\u002Fgitlab-config-backup && sudo cp -a \u002Fetc\u002Fgitlab\u002Fgitlab-secrets.json \u002Fetc\u002Fgitlab\u002Fgitlab.rb \u002Froot\u002Fgitlab-config-backup\u002F`. Without `gitlab-secrets.json`, a restore leaves encrypted data unreadable, such as CI\u002FCD variables and two-factor authentication secrets. Then move both copies off the machine, to separate storage. A rollback is only possible with a database backup taken on the same version and edition as the one you restore to.",{"type":83,"title":108,"steps":109},"Upgrade according to your installation",[110,113,116,119,122,125],{"title":111,"body":112},"Debian and Ubuntu (Omnibus package)","`sudo apt update && sudo apt install gitlab-ce=\u003Cversion>-ce.0`\nReplace `\u003Cversion>` with the version from the table for your branch. For the Enterprise edition: `sudo apt install gitlab-ee=\u003Cversion>-ee.0`.",{"title":114,"body":115},"RHEL, AlmaLinux and Oracle Linux","`sudo dnf install gitlab-ce-\u003Cversion>-ce.0.el9`\nUse `.el8` on a version 8 machine, and `gitlab-ee-\u003Cversion>-ee.0.el9` for the Enterprise edition.",{"title":117,"body":118},"Docker with docker run","`sudo docker stop gitlab`\n`sudo docker rm gitlab`\n`sudo docker pull gitlab\u002Fgitlab-ce:\u003Cversion>-ce.0`\nThen run `docker run` again with exactly your original options: same ports, same volumes for `config`, `logs` and `data`, same `--shm-size`. The data lives in the volumes, not in the deleted container.",{"title":120,"body":121},"Docker with Compose","Edit the image tag in `docker-compose.yml` to target `\u003Cversion>-ce.0`, then:\n`docker compose pull`\n`docker compose up -d`\n`docker compose logs -f gitlab`\nIf your file uses a floating tag, pin it: a pinned version makes the next upgrade readable.",{"title":123,"body":124},"Apply the configuration","On Docker, GitLab reconfigures and upgrades itself on the container's first start. On a package install, after any change to `gitlab.rb`, apply it with `sudo gitlab-ctl reconfigure`. Let the migrations run to completion before deciding the instance is stuck.",{"title":126,"body":127},"Check the result","`sudo gitlab-ctl status`\n`sudo gitlab-rake gitlab:env:info`\nThe displayed version must match the table. Open the interface, check that a repository clones, that a pipeline starts and that the runners reconnect.",{"type":129,"title":130,"body":131},"tip","Rehearse on a copy when the instance is critical","Restore the backup on a disposable machine of the same version, upgrade it, then time the migrations. You get the real length of the outage and discover surprises without touching production. Destroy the copy afterwards: it holds your secrets.",{"type":36,"title":133,"body":134},"Downtime, migrations, old upgrade paths: the three fears","Upgrading a production forge is frightening for precise reasons, and the GitLab advisory answers them plainly. Database migrations: the release includes some, regular ones in 19.4.3 and 19.3.6, and post-deploy ones in 19.4.3. Downtime: on a single node it is expected, since migrations must finish before startup; on multiple nodes, zero-downtime upgrade procedures apply. Old versions: below 18.11, follow the official upgrade path, stop by stop, without skipping a step.\n\nWhat you do not lose, provided the backup exists: your repositories, your issues, your registered runners and your tokens. The fear of breaking everything is legitimate, but waiting is the riskier bet, because the technical detail of the flaw is due to become public on the issue tracker 90 days after the patch release. Better to upgrade before that day.",{"type":136,"title":137,"items":138},"ul","While the window is being prepared: reduce exposure, without illusions",[139,140,141,142,143],"**No official workaround** — the GitLab advisory lists no mitigation: the only one is the upgrade.","**Restrict network access** — limiting the instance to your VPN or an address list reduces the possible attackers. It is not an official measure, only a stopgap.","**Do not invent a filtering rule** — no published nginx filter covers this flaw: writing one from memory gives a false sense of protection.","**Monitor now** — apply the two detection rules published by GitLab, presented below, to learn whether someone has already tried something.","**Set a deadline** — write down an upgrade date for the team: a stopgap without a date becomes a habit.",{"type":83,"title":145,"steps":146},"Check for traces after the upgrade",[147,150,153,156,159],{"title":148,"body":149},"Apply the two detection rules","GitLab publishes two rules for self-managed instances: \"Onigmo native worker crash\" and \"Org mode render error burst\". Take them from the official advisory into your monitoring or log tool.",{"title":151,"body":152},"Read GitLab's logs","`sudo ls -la \u002Fvar\u002Flog\u002Fgitlab` then `sudo gitlab-ctl tail`. Look for repeated worker process crashes and rendering errors concentrated over a short period, around or before October 21.",{"title":154,"body":155},"Check accounts and tokens","In the admin area, review recent users, administrators, personal access tokens and deploy keys. Anything without a known author deserves an explanation.",{"title":157,"body":158},"Check runners and projects","List the registered runners and the webhooks. An unknown runner or a recently added hook is a classic entry point after a takeover.",{"title":160,"body":161},"Keep the logs","Copy the useful logs off the machine before letting them rotate. If a doubt appears in a week, you will have something to compare against.",{"type":36,"title":163,"body":164},"If doubt remains: treat the instance as compromised","The absence of an alert does not prove the absence of a compromise: GitLab's two rules detect symptoms, not every intrusion. If a sign appears (a detection rule firing, an unknown account or runner, clustered crashes), treat the instance as compromised. Without a sign, exposure alone justifies the upgrade, not rotating every secret. If there is a sign, renew the instance secrets, the CI\u002FCD variables, the runner tokens and the access tokens, and register the runners again. A pipeline variable that holds a deploy key or a database password must be changed at the source, not only in GitLab. It is tedious, and it is the price of a forge that holds your code and your production access.",{"type":136,"title":166,"items":167},"Troubleshooting: common blockers",[168,169,170,171,172],"**`E: Version '\u003Cversion>-ce.0' for 'gitlab-ce' was not found`** — apt does not know this number yet: run `sudo apt update` again, check that the GitLab repository is configured, then check the spelling of the number and the `-ce.0` suffix.","**Cannot jump straight to the target version** — your instance requires stops. Install them one by one with their exact number and let the migrations finish between two.","**502 error page right after the upgrade** — migrations are still running. Wait, follow `sudo gitlab-ctl tail` and do not restart services by hand until they are done.","**Container started but empty** — `docker run` was run again without the original volumes. Stop it and recreate it with the same paths for `config`, `logs` and `data`.","**Restore fails after a rollback** — the backup must come from the same version and the same edition. Restore with the version that produced it, then upgrade again.",{"type":36,"title":174,"body":175},"A forge on a VPS: what changes","When your forge runs on a VPS where you have root, you decide the upgrade window, the backup location and how long logs are kept. Nobody imposes a schedule on you, and nobody upgrades on your behalf: that is the other side of the deal. Plan disk space for the archive, a copy off the machine, and a way to test a restore, as described in our guide on backups with restic. To install GitLab, our guide to installing GitLab CE on a VPS gives the starting point. If you would rather delegate server administration, the VPS administration option exists; this guide is provided as is, without support for your instance.",{"type":36,"title":177,"body":178},"Official documentation","GitLab 19.5.1 patch release advisory: https:\u002F\u002Fdocs.gitlab.com\u002Freleases\u002Fpatches\u002Fpatch-release-gitlab-19-5-1-released\u002F\n\nOctober 12, 2026 advisory: https:\u002F\u002Fdocs.gitlab.com\u002Freleases\u002Fpatches\u002Fpatch-release-gitlab-19-4-2-released\u002F\n\nUpgrading a Linux package: https:\u002F\u002Fdocs.gitlab.com\u002Fupdate\u002Fpackage\u002F\n\nUpgrading a Docker installation: https:\u002F\u002Fdocs.gitlab.com\u002Finstall\u002Fdocker\u002Fupgrade\u002F\n\nBacking up GitLab: https:\u002F\u002Fdocs.gitlab.com\u002Fadministration\u002Fbackup_restore\u002Fbackup_gitlab\u002F\n\nBleepingComputer report: https:\u002F\u002Fwww.bleepingcomputer.com\u002Fnews\u002Fsecurity\u002Fgitlab-warns-of-new-max-severity-code-execution-vulnerability\u002F","A forge on a server that is truly yours","A VPS with root access lets you choose your upgrade window, your backups and your logs. If you do not want to handle upgrades yourself, the VPS administration option is available, and support@servorbit.com is there for your questions.","See the developer solution","\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-emergency-patch-or-gitea-migration",{"fr":188,"en":186,"ar":189,"es":190},"gitlab-cve-2026-85706-migration-gitea-vps","cve-2026-85706-gitlab-تصحيح-عاجل-أو-هجرة-إلى-gitea","cve-2026-85706-gitlab-parche-urgente-o-migracion-gitea","CVE-2026-85706 GitLab: emergency patch or Gitea migration","CVE-2026-85706 (CVSS 10.0) exposes secrets.yml and SSH keys on GitLab 18.7–19.3.1. Patch to 19.3.2 immediately or migrate to Gitea on a 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},"development","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,"install-gitlab-ce-on-a-vps-complete-guide",{"fr":207,"en":205,"ar":208,"es":209},"installer-gitlab-ce-vps","تثبيت-gitlab-ce-على-vps-دليل-شامل","instalar-gitlab-ce-en-un-vps-guia-completa","Install GitLab CE on a VPS: complete guide","Deploy GitLab CE on your VPS with Docker Compose. Covers CVE-2026-90970 (CVSS 9.9): AI Gateway RCE, vulnerable versions and update commands.",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},"Deployment","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,"restic-s3-3-2-1-backup-strategy-vps",{"fr":227,"en":225,"ar":228,"es":229},"backup-vps-restic-s3-3-2-1","restic-s3-3-2-1-backup-strategy-vps-ar","estrategia-3-2-1-backup-vps-restic-s3","3-2-1 Backup Strategy for Your VPS with Restic and S3","Build a complete 3-2-1 strategy on your VPS: Restic to Backblaze B2 or Cloudflare R2, systemd timer, retention policy and automated restore test.","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",1793251330102]