BREAKING: GitLab CVE-2026-110264 lets attackers run code on self-managed servers with no login, even ones patched Oct 12
How to fix CVE-2026-110264: upgrade GitLab to 19.5.1, 19.4.3, 19.3.6, or the 19.2.9, 19.1.9, 19.0.10 and 18.11.13 backports. A crafted Org-mode file gives no-login code execution on self-managed GitLab, and servers patched on October 12 are exposed again.
Contents
Anyone who can get GitLab to render a crafted Org-mode file can run code on a self-managed GitLab server, with no account. GitLab shipped a critical patch release on October 21, 2026 for CVE-2026-110264, an integer overflow in Onigmo, the Ruby regular expression engine GitLab ships inside its packages. GitLab rates it CVSS 10.0 and lists every version from 7.0 (2014) as affected. If you upgraded for CVE-2026-97229 on October 12, you are vulnerable again: 19.4.2, 19.3.5 and 19.2.8 are all below the new fixed versions.
This is our operator read of the GitLab critical patch release notes and the two detection rules GitLab published in its TLDR detection repo. The CVE record and NVD entry were not public yet when we published.
How to fix
Upgrade to the fixed patch on the minor version you run. GitLab backported this one past its usual three-release support window, so even 18.11 gets a package.
# Omnibus on Debian/Ubuntu (use gitlab-ce and -ce.0 for Community Edition)
sudo apt-get update
sudo apt-get install gitlab-ee=19.4.3-ee.0 # pick your train from the table below
# Omnibus on RHEL/Alma/Rocky
sudo dnf install gitlab-ee-19.4.3-ee.0.el9
# Docker
docker pull gitlab/gitlab-ee:19.4.3-ee.0
| You run | Upgrade to | Patched on Oct 12 to |
|---|---|---|
| 19.5.0 | 19.5.1 | (19.5 was not out) |
| 19.4.x before 19.4.3 | 19.4.3 | 19.4.2, still exposed |
| 19.3.x before 19.3.6 | 19.3.6 | 19.3.5, still exposed |
| 19.2.x before 19.2.9 | 19.2.9 (backport) | 19.2.8, still exposed |
| 19.1.x before 19.1.9 | 19.1.9 (backport) | not covered then |
| 19.0.x before 19.0.10 | 19.0.10 (backport) | not covered then |
| 7.0 through 18.11, before 18.11.13 | 18.11.13 (backport) | not covered then |
Plan for downtime on a single node. GitLab says 19.4.3 and 19.3.6 carry regular database migrations that must finish before GitLab starts, and 19.4.3 adds post-deploy migrations. Multi-node installs can use the zero-downtime procedure. Helm chart users need the chart release that ships one of these GitLab versions. Anything older than 18.11 has no direct patch: it has to climb the normal upgrade path to 18.11.13 or later.
GitLab published no workaround. If you cannot upgrade in the next few hours, the detection notes give the one lever that matters: the no-login path needs a public project holding the .org file. Making projects private, turning off open sign-up and putting the instance behind your VPN shrinks who can plant or reach that file. That is exposure reduction, not a fix.
One operator check
Check what is running, then check whether anyone has been probing the Org renderer:
# Running version (Omnibus, or inside the Docker container)
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# Org-mode render timeouts per client, from GitLab's own detection notes
grep '"exception.class":"Timeout::Error"' /var/log/gitlab/gitlab-rails/exceptions_json.log* \
| grep '"extra.class_name":"OtherMarkup"' | grep -E '"extra.file_name":"[^"]*\.org"' \
| grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn
# Native Ruby crashes through org-ruby or Onigmo
grep -B1 -A20 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log* \
| grep -E 'org-ruby|headline\.rb|match_at|onig_search_gpos|onig_compile|compile_tree'
Five or more .org render timeouts from one ip/... client inside 30 minutes is the threshold GitLab's rule uses. In a repository checkout you suspect, look for the payload itself: rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'. Normal Org files do not have 500-character TODO keyword lines.
Where the bug lives
GitLab's advisory says only that a specially crafted regular expression overflows an integer when it is compiled. Its detection write-ups say more. GitLab renders .org files with the org-ruby gem. That gem takes custom keywords from a #+TODO: line and puts the raw keyword into Regexp.new. A keyword with more than 32,767 repeats pushes Onigmo's repeat ID past a signed 16-bit limit, and the wrapped value causes an out-of-bounds write when the regex runs. With heap grooming, GitLab says, that becomes a system() call as the git user.
That user owns the repositories, gitlab-secrets.json, CI/CD variables and runner tokens. A successful run is quiet: GitLab's own notes say the exploit does not reliably crash, so a clean crash log does not clear you.
The bug-fix lists back this up. 19.5.1, 19.4.3, 19.3.6 and 19.2.9 add a "Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0" and update gitlab-markup to 2.2.0. The fix lives in the Ruby runtime GitLab bundles plus the markup layer. If you run GitLab from source on a Ruby you built yourself, upgrading the Rails code may not carry the runtime patch. Omnibus, Docker and Helm get it with the package.
This is the fourth Onigmo code-execution report from the same HackerOne researcher, joaxcar, in about a month. CVE-2026-93577 and CVE-2026-89078 (September 23) needed a logged-in user. CVE-2026-97229 (October 12) went through CI/CD regexes and stopped at 19.2. This one comes in through file rendering and reaches back to 7.0.
Who is not in scope
- GitLab.com. GitLab says the SaaS already runs the fix.
- GitLab Dedicated on 19.3.5-internal0, 19.4.2-internal0 or later. Those builds already include the fix.
- GitLab Runner. The advisory names GitLab CE/EE, not Runner. Runners still execute what a compromised server sends them, so patch the server first.
Everyone else on CE or EE is in range. GitLab has not published preconditions beyond "certain conditions," so do not rule yourself out by configuration.
What this is not
It is not a CI/CD config bug like the October 12 one, and the October 12 packages do not cover it. It is not known to be exploited: GitLab reports no attacks, and it is not in the CISA KEV catalog (version 2026.10.21) as of publication. GitLab's detection rules say the attack is noisy, with many render timeouts before one lands, which is why the log check above is worth running today.
Where HOL Guard fits
HOL Guard pauses risky actions by AI coding agents on developer machines. It does not sit in front of a GitLab server and does not block this exploit. The fix is the upgrade. We track the issue end to end on the HOL Guard security campaign page for CVE-2026-110264.
Other fixes in the same release
- CVE-2026-15723 (8.2): account takeover of LDAP-backed users, only when OmniAuth SAML and LDAP auto-linking are both on.
- CVE-2026-112212 (7.5): cache poisoning of OAuth/OIDC discovery documents behind a shared cache, redirecting some sign-in flows.
- Nine medium and low issues, including GraphQL token-scope and group milestones API authorization bugs.
Every fix in this list ships only in 19.3.6, 19.4.3 and 19.5.1. The 19.2.9, 19.1.9, 19.0.10 and 18.11.13 backports carry the critical fix but none of the other security fixes, so treat them as a bridge to a supported train, not a place to stay.
References
- GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
- GitLab TLDR detection: Org mode render error burst
- GitLab TLDR detection: Onigmo native worker crash
- CVE-2026-110264 record (not yet published at time of writing)
- The Hacker News coverage
- Our October 12 write-up of CVE-2026-97229
Continue reading
All posts
BREAKING: GitLab critical patch fixes no-login code execution on self-managed servers (CVE-2026-97229)
How to fix CVE-2026-97229: upgrade GitLab to 19.4.2, 19.3.5 or 19.2.8. A crafted regex in CI/CD config could run code on a self-managed GitLab server with no login. GitLab.com is already patched.

BREAKING: New no-login code execution bug in Magento and Adobe Commerce (CVE-2026-103849)
How to fix CVE-2026-103849: upgrade Adobe Commerce or Magento Open Source to the 2026-oct build for your line (APSB26-153), and keep September's VULN-39341 hotfix in place.

BREAKING: PHP2Shell lets attackers run code on PHP web servers with no login. Update PHP now (CVE-2026-109618, CVE-2026-109619)
How to fix CVE-2026-109618: upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart Apache and PHP-FPM. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets attackers run code on PHP web servers with no login. PHP 8.1 and older get no upstream fix.
