GitLab's Second CVSS 10 Regex Bug in Nine Days Reaches Back to 2014. If You Patched on October 12, You Are Still Exposed.
If you run self-managed GitLab, upgrade today to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, whichever matches your branch. On October 21 GitLab fixed CVE-2026-110264, an integer overflow in regular expression compilation that, in GitLab's words, could let an unauthenticated user "execute arbitrary code on the GitLab server." It is rated CVSS 10.0, and the affected range starts at GitLab 7.0, which shipped in 2014.
The part that will catch people: nine days earlier, on October 12, GitLab fixed a different CVSS 10.0 regex bug, CVE-2026-97229. If you took that patch, you are on 19.4.2, 19.3.5 (or 19.3.4) or 19.2.8, and every one of those builds is inside the new affected range. If you run 18.11, 19.0 or 19.1, the October 12 advisory said your branch was not affected, and this one says it is. Your October patch does not cover you.
What GitLab fixed on October 21
GitLab's patch release 19.5.1 lists twelve security fixes. The one that matters most is CVE-2026-110264: CVSS 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, classed as CWE-190 integer overflow. GitLab's description is short. Under certain conditions, an unauthenticated user could run arbitrary code on the server "due to integer overflow when compiling a specially crafted regular expression."
The affected range is all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. GitLab backported the fix to four older branches, 18.11 through 19.2, on top of the three current ones (19.3, 19.4 and 19.5) that every other fix in the release covers. Anything older than 18.11 has no fixed build on its own branch, so those instances need a version upgrade, not a patch.
GitLab did not name the component in the advisory text. It did publish two threat detections for self-managed customers, named "Onigmo native worker crash" and "Org mode render error burst." Onigmo is the regular expression engine inside Ruby, which GitLab is written in. The second detection suggests GitLab expects attempts to show up around rendering of Org mode files, a plain-text markup format, but GitLab has not said that is the attack path, and we are not saying it either.
GitLab.com and GitLab Dedicated are already patched. This is a self-managed problem.
How it relates to October 12
CVE-2026-97229, fixed in the October 12 patch release, is also CVSS 10.0, also CWE-190, also unauthenticated code execution through a crafted regular expression. GitLab's description for that one names the route: a regular expression "in a CI/CD configuration, due to insufficient regular expression validation." Its affected range was only 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2.
Both were reported through HackerOne by the same researcher, joaxcar, and credit for both goes to them.
GitLab does not say whether the October 21 bug is a bypass of the October 12 fix, a second route to the same weakness, or something unrelated that happens to look alike. We do not know either. What the two version ranges show is enough to act on: no build that the October 12 release produced is outside the October 21 range, and three older branches went from "not affected" to "affected" in nine days. An admin who read the first advisory carefully and concluded they were fine was right on October 12 and is wrong today.
A note on 19.3: GitLab's October 12 page is titled for 19.3.4 and says 19.3.5 followed to fix an unrelated merge request page bug with the Ona integration. Either one is below 19.3.6.
A two-PoC account that vanished
Our exploit harvester watches GitHub for public proof-of-concept repositories and records what endpoints they target. For these two CVEs it recorded three repositories.
The first was jburgess-r7/CVE-2026-97229-PoC, created October 13 and harvested at 18:01 UTC that day. Its description says it is a CI lint integer-overflow PoC validated against the official 19.4.1 image. It is still up. We have not vetted its code and are not vouching for it.
The other two came from one account, OppositDeer: Gitlab-RCE-CVE-2026-97229, created October 16, and Gitlab-RCE-CVE-2026-110264, created at 04:30 UTC today and harvested at 06:01 UTC. Each had one star. Today the GitHub API returns 404 for the account and both repositories.
Here is the part that makes us distrust it. The harvester extracts the endpoint paths each repository targets. For the account's supposed CVE-2026-110264 exploit, it extracted exactly the same four paths as for the October 13 CVE-2026-97229 PoC: /benign.yml, /output/, /wget/nc and the GitLab CI lint API endpoint. The CI lint endpoint is the October 12 bug's route. So the repository that claimed to exploit a CVE published hours earlier targeted the same endpoints as an exploit for the previous one. The likeliest reading is old code under a new CVE number.
What we cannot tell you is whether it was also malicious. We stored the paths, not the code, and the account is gone. We are not calling it malware. We are saying it was a repository that appeared within a day of the advisory, claimed an exploit for a bug whose route GitLab had not described, matched an older PoC's endpoints exactly, and then disappeared along with its owner. That is the profile to treat as hostile. Do not run unvetted PoC code from a new account on a machine that holds anything you care about, and never on a machine that can reach your GitLab instance.
What our edge saw
We ran our edge check for both CVEs, using the CI lint endpoint pattern from the harvested PoCs, over the 30 days since September 22. It scanned 28,555 edge block events, 29,604 edge canary records and 1,663 origin honeypot captures. Every count was zero for both CVEs.
That is a measurement of our own edge, nothing more. We do not run GitLab, our canaries do not trap GitLab paths, and a scanner hunting real GitLab servers has little reason to probe us. A zero here does not mean nobody is exploiting this. As of this writing, GitLab has not reported exploitation, neither CVE is in CISA's Known Exploited Vulnerabilities catalog (version 2026.10.21), and a web search today found no public report of exploitation.
Two GitLab bugs we wrote about this summer did not stay quiet for long. CVE-2026-19478 was patched on August 17 and watchTowr reported exploitation four days later, which we covered in GitLab Patched It Monday. Our Harvester Had the Exploit Endpoints Tuesday. CVE-2026-85706 was exploited one day after its September 10 patch: GitLab Was Exploited One Day After the Patch. Those dates are not a forecast. They are the reason not to wait for one.
What to do
1. Find your version. The Help page in the GitLab UI shows it, or run gitlab-rake gitlab:env:info on the server.
2. Upgrade to the fixed build for your branch. 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. If you are on 18.10 or older, plan an upgrade to one of those branches today.
3. Do not stop at the October 12 build. 19.4.2, 19.3.5, 19.3.4 and 19.2.8 are not enough.
4. Turn on GitLab's two detections for self-managed instances, "Onigmo native worker crash" and "Org mode render error burst," linked from the release page. Then look back through your logs for crashes or render error bursts since October 12.
5. If you test, test with care. A PoC from an account created this week is untrusted code. Read it before running it, and run it somewhere isolated.
The same shape, again
This is the second time this month we have written that a GitLab patch did not cover what people thought it covered. On October 2, GitLab fixed a second CVSS 9.9 in its AI Gateway's template sandbox, and the builds that had been patched for the first one in February were still exposed: GitLab Fixed a 9.9 in Its AI Gateway's Template Sandbox in February. And in July we wrote about a code execution chain through the Oj JSON parser and Jupyter notebook diffs that GitLab fixed in June under bug fixes, with no CVE: GitLab Fixed This in June and Filed It Under 'Bug Fixes'.
The lesson is the same each time. A patch fixes the bug it names on the branches it lists. When a second bug of the same kind lands in the same component, the first patch is not evidence of anything. Read the new version range against what you are running, not against what you did last week.
Credit, and what we did not do
The research is joaxcar's, reported through GitLab's HackerOne program. The fixes and the detections are GitLab's. We did not find either bug, we have no telemetry of either being used, and we make no claim to have seen anything first. Our contribution is the version comparison, the edge check, and what our harvester recorded about the PoC repositories.
We counted 52 checkable claims in this post before publishing and corrected 7 that overstated what a source said or what we can know, among them whether Onigmo is named in the advisory (it is named only in a detection), whether the October 21 bug is a bypass of the October 12 fix (unknown), whether the vanished repository was malware (we cannot tell), how far a zero at our edge reaches, and a line reading GitLab's extra backports as a measure of how seriously it takes the bug, which no source says. At least 5% of what remains is still wrong, and we do not know which.
If you want to pull our threat feed into your own tools, a free API key takes about 30 seconds: register here.
If this was useful, or was not, rate it at the bottom of the page.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=gitlab-second-cvss-10-regex-bug-october-patch-not-enough
Comments