GitLab says CVE-2026-97229 needs no account, the third regex-titled critical in 19 days

One CVSS metric and 19 days separate a login-required critical from a no-login one

GitLab's advisory for CVE-2026-97229, published on Monday 12 October 2026, scores the flaw CVSS 10.0. Its advisory for CVE-2026-93577, published 19 days earlier on Wednesday 23 September 2026 (derived), scored 9.9. Both describe an integer overflow in a regular expression compiler that could let an attacker run code on the GitLab server, through a regular expression placed in a CI/CD configuration. The two CVSS vectors that GitLab published differ in exactly one metric: Privileges Required moved from Low to None (derived by comparing them, and recomputed from the CVSS 3.1 formulas, which return 9.9 and 10.0). GitLab's wording moved with it, from "an authenticated user" to "an unauthenticated user".

That is the third critical advisory with "Regular Expression" in its title in 19 days. CVE-2026-89078, a double free in the Regular Expression Parser, and CVE-2026-93577 were both fixed on 23 September. CVE-2026-97229 followed on 12 October. The count behind this briefing's slug, "third critical in three weeks", therefore holds for that component and for GitLab Community and Enterprise Editions (CE and EE). It does not hold on every count. GitLab's AI Gateway received its own critical fix on 2 October, which makes CVE-2026-97229 the fourth critical CVE on GitLab's release pages since 21 September, and the sixth since 10 September (derived). The third section sets the count out line by line.

This briefing reads GitLab's own patch release pages, not the press coverage. The 12 October page was read in full at 14:51 BST on Monday 12 October 2026, with the earlier pages of 23 September, 10 September, 2 October and 17 August, the CVE.org and NVD records, CISA's Known Exploited Vulnerabilities file and the UK guidance cited below. BleepingComputer's report of the same day was read in a browser tab, for what it quotes and for context only, and is secondary. Times are BST unless stated. GitLab is the vendor, sells the product, and is the only source for the flaw's description and its score. Every score here is GitLab's, set as the CVE Numbering Authority: no independent score exists yet.

What the record does not establish matters more than the score. At 14:52 BST CVE.org answered that the record for CVE-2026-97229 does not exist, the NVD returned no results, and CISA's catalogue (version 2026.10.08) did not list it. GitLab's page says nothing about exploitation. It does not say what the "certain conditions" are, how an unauthenticated user reaches a CI/CD configuration, whether a public project is enough, whether any workaround exists, or whether the second fix is a bypass of the first. The sections below take each in turn, then the UK clocks and an ordered checklist.

What GitLab does state is plain. Self-managed CE and EE installations on 19.2, 19.3 or 19.4 need 19.2.8, 19.3.4 or 19.4.2. GitLab.com is already patched and GitLab Dedicated customers need not act. Under Cyber Essentials v3.3 the 14 days for this release end on 26 October (derived), and the 14 days for the 23 September release ended on 7 October, five days ago (derived).

Stated and not stated: GitLab's 12 October advisory, line by line

The left column quotes or closely paraphrases GitLab's page, read at 14:51 BST. The right column lists the questions a defender would ask next, to which the page, the CVE.org record, the NVD and CISA give no answer at 14:52 BST.

GitLab's page 'GitLab Critical Patch Release: 19.4.2, 19.3.4, 19.2.8' of 12 October 2026, read at 14:51 BST, with the CVE.org, NVD and CISA records read at 14:52 BST.

Item	Stated by GitLab	Not stated
Flaw	Integer overflow in the CI/CD Regular Expression Compiler. Rated Critical. Cause given: "insufficient regular expression validation".	What the "certain conditions" are. Which feature, setting or code path is involved.
Who can trigger it	"An unauthenticated user", through a specially crafted regular expression in a CI/CD configuration.	How an unauthenticated user supplies a CI/CD configuration. Whether anonymous access to a public project is enough.
Impact	Execute arbitrary code on the GitLab server.	Which account the code runs as, what it can read on the host, and whether runners are touched.
Versions	CE and EE, all versions from 19.2 before 19.2.8, 19.3 before 19.3.4 and 19.4 before 19.4.2. All deployment types unless one is named.	Anything about 19.1 and earlier, beyond a range that starts at 19.2.
Fix and workaround	Upgrade to 19.4.2, 19.3.4 or 19.2.8 "immediately". The page lists no workaround or mitigation.	Whether any setting reduces the exposure, or whether switching off a feature helps.
Score	CVSS 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, set by GitLab.	Any independent score. CVE.org has no record and the NVD has no result.
Exploitation	Nothing. The page has no section on detecting exploitation.	Whether anyone has used the flaw. CISA's catalogue (version 2026.10.08) does not list it.
Reporter	Credit to a researcher, who reported it "through our HackerOne bug bounty program".	When it was reported, and any reward.
Hosted GitLab	GitLab.com "is already running the patched version". GitLab Dedicated customers "do not need to take action".	When GitLab.com was patched, and whether it was attacked first.
Known issue	19.3.4 has a bug affecting merge request pages when the Ona integration is enabled. A fix "will follow in 19.3.5".	A date for 19.3.5, and which branch GitLab prefers a 19.3 instance to move to.
Disclosure	Issues for security fixes are made public "90 days after the release".	Whether details appear sooner. The date is 10 January 2027, a Sunday (derived: 12 October plus 90 days).
Timing	Scheduled releases fall on the second and fourth Wednesdays, with ad-hoc critical patches for high-severity flaws. 12 October is a Monday.	Why it came on a Monday, two days before Wednesday 14 October (derived), or whether any customer was warned earlier.

Two absences are worth setting against GitLab's own earlier pages. The 10 September page for CVE-2026-85706 carried a section headed "Detecting CVE-2026-85706 Exploitation Attempts", with three threat detections, after CISA had listed that flaw. The 12 October page has no such section. And the 2 October AI Gateway page said GitLab had conducted "targeted outreach" to customers before publishing. This page does not say whether any outreach preceded the release. Neither absence shows that nothing happened. Each is a reason to read the page again later rather than to assume.

The release is not a one-CVE change. GitLab lists 24 security fixes: 1 Critical, 5 High, 14 Medium and 4 Low (derived by counting its table). Four entries describe an unauthenticated user: CVE-2026-97229, and three Medium flaws (CVE-2026-16275, CVE-2026-84284 and CVE-2026-85529) that let an unauthenticated user read notes or work item contents, two of them on public projects. Three of the five High entries concern CI/CD pipelines: Developer-role users running pipelines on protected branches (CVE-2026-16301), poisoned cached raw files that make pipelines run crafted content and may expose protected environment variables (CVE-2026-14814), and a scheduled pipeline execution policy that runs pipelines with a new group's privileges after a project transfer (CVE-2026-81839, EE only). A team that upgrades for one number gets all 24, and should read the others.

Three regex criticals, six critical CVEs in 32 days: the count, checked against GitLab's pages

The headline pattern, "three critical flaws in the regex engine in three weeks", was checked against the release pages themselves. GitLab titles its critical releases "Critical Patch Release" and lists severity per fix. Dates are those on GitLab's pages, except 2 October, which comes from GitLab's patch release feed because the AI Gateway page text carries no date.

Critical entries on GitLab's patch release pages, 17 August to 12 October 2026. Scores and the account requirement are GitLab's. 17 August is outside the 31 days from 11 September.

Date and release	Critical entry, as GitLab titles it	Score, and whether an account is needed
17 Aug, Monday: 19.2.4, 19.1.6, 19.0.8, 18.11.11	CVE-2026-19478, code injection via a GraphQL directive, CE and EE	9.4, no account
10 Sep, Thursday: 19.3.2, 19.2.6, 19.1.8	CVE-2026-85706, path traversal in the repository commits API, CE and EE. In CISA's catalogue from 11 Sep	10.0, no account
10 Sep, Thursday: same release	CVE-2026-87719, insecure deserialization in a GraphQL subscription serializer, EE only	9.9, an account with Duo Chat access
23 Sep, Wednesday: 19.4.1, 19.3.3, 19.2.7	CVE-2026-89078, double free in the Regular Expression Parser, CE and EE	9.9, an account needed
23 Sep, Wednesday: same release	CVE-2026-93577, integer overflow in the Regular Expression Compiler, CE and EE	9.9, an account needed
23 Sep, Wednesday: 19.0.9, 18.11.12	No new entry. A backport of the two 10 Sep fixes "outside of our standard maintenance policy"	Not applicable
2 Oct, Friday: AI Gateway 19.2.4, 19.3.2, 19.4.1	CVE-2026-90970, improper neutralization in a custom flow prompt template, self-hosted AI Gateway	9.9, an account with Duo Agent Platform access
12 Oct, Monday: 19.4.2, 19.3.4, 19.2.8	CVE-2026-97229, integer overflow in the CI/CD Regular Expression Compiler, CE and EE	10.0, no account

The verdict, each figure derived from the table. The regex count is right: three critical advisories titled "Regular Expression", two on 23 September and one on 12 October, 19 days from the first release to this one. Whether the three are one "engine" is not stated. GitLab titles them Regular Expression Parser, Regular Expression Compiler and CI/CD Regular Expression Compiler, and says nothing of a shared component. The slug's "third" also holds for CE and EE alone since 11 September. It becomes fourth if the separate AI Gateway product is counted, so the slug is kept and this is the qualifier.

In the 31 days from 11 September to 12 October, GitLab's pages show four distinct critical CVEs first fixed (three in CE and EE, one in the AI Gateway) on three release pages, plus a fourth page, the 23 September backport, that re-lists two older ones. Counting from 10 September, one day earlier, the figure is six. Two CE and EE scores in that period are the maximum, 10.0: CVE-2026-85706 on 10 September and CVE-2026-97229 on 12 October, 32 days apart. Both need no account. Adding the 17 August release, whose CVE-2026-19478 is scored 9.4 and also needs no account, gives three no-account criticals in 56 days.

The rhythm matters more than the count. GitLab says scheduled releases fall on the second and fourth Wednesdays, with ad-hoc critical patches for high-severity flaws in between. Of the four critical dates, only 23 September, a fourth Wednesday, fell on a scheduled day (derived). 10 September was a Thursday, 2 October a Friday and 12 October a Monday. An estate that patches GitLab only on the scheduled Wednesdays would have applied the 10 September fix on 23 September, 13 days later and 9 days after CISA's due date for CVE-2026-85706 (derived, under that assumed policy). The next scheduled day is Wednesday 14 October, two days after this release, then 28 October (derived from GitLab's statement). The intervals between the four critical dates are 13, 9 and 10 days (derived).

How CVE-2026-97229 differs from the two regex criticals of 23 September

Three advisories read side by side. The middle column comes from GitLab's 23 September page and the CVE.org and NVD records for those two flaws. The right column is the 12 October page.

GitLab's pages of 23 September and 12 October 2026, with the CVE.org and NVD records for CVE-2026-89078 and CVE-2026-93577, read 12 October 2026.

Item	CVE-2026-89078 and CVE-2026-93577 (23 September)	CVE-2026-97229 (12 October)
GitLab's title	Double Free issue in Regular Expression Parser, and Integer Overflow issue in Regular Expression Compiler	Integer Overflow issue in CI/CD Regular Expression Compiler
Who	"An authenticated user", for both	"An unauthenticated user"
Cause given	A double free when parsing, and an integer overflow when compiling, a crafted regular expression in a CI/CD configuration	"Insufficient regular expression validation", for a crafted regular expression in a CI/CD configuration
CVSS vector (GitLab)	9.9, Privileges Required Low. Availability impact Low for the double free, High for the overflow	10.0, Privileges Required None, Availability impact High. Otherwise identical to the overflow's vector
Weakness (CVE.org)	CWE-415 double free, and CWE-190 integer overflow	No record yet
Affected	CE and EE from 19.2 before 19.2.7, 19.3 before 19.3.3, 19.4 before 19.4.1	CE and EE from 19.2 before 19.2.8, 19.3 before 19.3.4, 19.4 before 19.4.2
CVE record published	23:04 and 23:05 UTC on 23 September. The NVD entry carries a published time of 00:17 on 24 September	None at 14:52 BST on CVE.org, and no NVD result
CISA's SSVC entry	24 September: exploitation none, automatable no, technical impact total	None, because there is no CVE record to attach it to
Credit	A researcher, through HackerOne, on both	A researcher, through HackerOne. The same credited name as on both of the others

Three things are the same and two are different. Same: the CI/CD configuration as the place the regular expression sits, the integer overflow wording in two titles, the earliest affected branch, 19.2, and the credited reporter. Different: the account requirement, and the stated cause, which moved from a named weakness (a double free, an integer overflow) to "insufficient regular expression validation".

Whether CVE-2026-97229 is a way around the fix for CVE-2026-93577 is not stated, and this briefing does not claim it. One fact on the 12 October page belongs beside the question. Its bug-fix lists for 19.4.2, 19.3.4 and 19.2.8 each carry two entries that name Ruby regular expression patches: "Add Ruby regexp program size patch for 3.3 and 3.4" and "Add Ruby regexp repeat-range double-free patch for 3.3 and 3.4". Neither appears in the 23 September page's bug-fix lists. GitLab does not link them to any CVE. A double-free patch on 12 October, after a double-free CVE was fixed on 23 September, may be a separate issue or a further layer, and the reader should treat the link as open. The practical point for a defender is simpler: an instance updated on 23 September to 19.4.1, 19.3.3 or 19.2.7 does not have the 12 October changes.

One reporter is credited on all three regex entries and on four other entries across the 10 September, 23 September and 12 October pages, seven in all (derived by counting the credit lines). Three of the seven are the criticals. That is consistent with one person finding the three regex flaws in sequence and GitLab fixing them in instalments. The other four credited entries are in other areas, so the credit does not confine the pattern to one component. The reading is an inference: GitLab states no reason for the sequence. The NCSC's name for the wider pattern, vulnerability swarming, is in the UK section.

Earlier briefings on this site cover other GitLab flaws, and each differs from this one. CVE-2026-85706 is a file-read flaw in the repository commits API, scored 10.0 and listed by CISA a day after its fix. The AI Gateway flaw of 2 October sits in a separate self-hosted service and needs an account with Duo Agent Platform access. CVE-2026-97229 is described as code execution in CE and EE itself.

Is it exploited? What CISA, GitLab and the press said at 14:52 BST

Sources read on 12 October 2026 between 14:52 and 15:11 BST. The right column is the nearest precedent on the same product, for contrast.

Source	CVE-2026-97229	CVE-2026-85706 (fixed 10 September)
CISA catalogue, version 2026.10.08	Not listed	Listed 11 September, due 14 September, with forensic triage flagged
CISA's SSVC entry in the CVE record	No CVE record yet	Exploitation active, automatable yes, technical impact total (12 September)
GitLab's patch page	No statement on exploitation	States it was added to CISA's catalogue and publishes three threat detections
BleepingComputer, 12 October (secondary)	No statement on exploitation	Reports CISA listed it a day later and told federal agencies to fix within three days
A web search for the identifier, run again at 15:11 BST	No page found that mentions it	Not searched

The nearest precedent is on the same product and is 31 days old. GitLab fixed CVE-2026-85706 on 10 September, CISA listed it on 11 September, one day later, and the due date was 14 September, three days after the listing and four days after the fix (derived). A precedent is not a prediction. It shows that an unauthenticated, network-reachable, CVSS 10.0 flaw in the same product was in the catalogue within a day, which is a reason not to read the 14 days below as a licence to wait. It does not show that CVE-2026-97229 is exploited. The two flaws differ: one reads files, the other is described as running code, and GitLab has not said whether the second is as easy to trigger as the first.

The NCSC adds two cautions, from guidance reviewed on 1 May 2026. Sources such as CISA's catalogue report exploitation that has already occurred, so absence from them is not evidence of safety. And its table of response times starts from the answer yes to "Has the vulnerability been added to the CISA KEV?", so those rows do not apply to CVE-2026-97229 today. They would apply the day CISA lists it.

Five labels that sound like controls

A label can pass for a control when the question is asked quickly. Each of the five below is true of something. None of them, on GitLab's page, stops this flaw on a self-managed server.

Five labels, and what GitLab's 12 October page and the other sources read actually say. Items marked inference are this briefing's reading, not GitLab's statement.

Label	What it sounds like	What the record says
Self-managed	Ours, so under our control	It means the patching is yours. GitLab asks all self-managed installations to upgrade "immediately". No one else will install 19.4.2 on a server you run.
Behind the VPN	Only our staff can reach it	The advisory says nothing about networks. Its vector says the attack travels over the network and needs no privileges. A VPN narrows who can try. It does not remove the flaw, and a contractor's laptop or a build runner on the VPN is as "unauthenticated" to GitLab as a stranger (inference).
GitLab.com is already patched	The vendor has fixed it	True of GitLab.com, and Dedicated customers need not act. Neither is your server. The request to upgrade is addressed to self-managed installations.
Only CI/CD configuration	A narrow, internal feature	The advisory says where the regular expression sits, not who can put it there, and rates the attacker as unauthenticated. How a stranger supplies a CI/CD configuration is not stated.
DevSecOps platform	A product category, run by someone else	BleepingComputer repeats GitLab's claim of over 30 million registered users and more than half of the Fortune 100. That is scale, not a control. A self-managed instance is a server you run.

The step from code execution on the GitLab server to what an attacker could reach is this briefing's inference, not GitLab's statement. A GitLab server holds the source repositories and, in the usual design, the CI/CD variables, runner credentials and deploy credentials that pipelines use. GitLab itself treats such values as sensitive: its 23 September advisory CVE-2026-92470 concerns "sensitive CI/CD variable values", and its 12 October advisory CVE-2026-14814 mentions "protected environment variables". The advisory for CVE-2026-97229 does not say which account the code would run as, so how much of that is in reach is not established. The NCSC, in a blog of 4 June 2026 about package ecosystems rather than GitLab, says recent attacks "exploited the considerable implicit trust in CI/CD and automation pipelines". The trust is the same one.

The UK: the 14 days, the NCSC's clocks, the supply chain and the 72 hours

Cyber Essentials v3.3 (April 2026) requires software in scope to be updated within 14 days of release where the vendor describes the fix as critical or high risk, or where the CVSS v3 base score is 7 or above. Its definition of software includes commercial off-the-shelf applications, and the update requirement applies to servers, so a self-managed GitLab server is in the clause's reach if it is in the assessed scope. GitLab calls this release critical and scores the flaw 10.0, so the clock is 14 days from 12 October, ending on Monday 26 October 2026 (derived). The same clause says an update that covers several issues must be installed within 14 days if any is critical or high risk, which matters because this release carries 1 Critical and 5 High fixes. The 14 days for the 23 September release ended on 7 October (derived). A server still below 19.4.1, 19.3.3 or 19.2.7 is already outside them for two critical fixes.

UK sources as read on 12 October 2026, from 14:55 BST. The last column applies each to the 12 October release.

Source, as read	What it says	Date or status for this release (derived)
Cyber Essentials v3.3, Security Update Management (April 2026)	Update within 14 days of release if the vendor says critical or high risk, or the CVSS v3 base score is 7 or above. Software must be licensed and supported. Automatic updates where possible.	Monday 26 October 2026. For the 23 September release: Wednesday 7 October, passed.
NCSC vulnerability management, principle 1 (reviewed 1 May 2026)	Best-practice timescales for all updates: internet-facing services 5 days, operating system and applications 7 days, internal or air-gapped 14 days. Aim to shorten them.	Saturday 17 October, Monday 19 October and Monday 26 October.
NCSC vulnerability management, principle 2: responding to active exploitation	For a flaw in CISA's catalogue that is internet accessible, automatable and gives total control: update immediately, within 24 hours, with an investigation by an assured incident response provider. Under 48 hours if not automatable, under 72 hours if not internet accessible.	Not in the catalogue at 14:52 BST, so the rows do not yet apply. They would the day CISA lists it.
The same page: vulnerability swarming	After a product sees a wave of attacks, more flaws are likely to be found. Be ready to deploy further vendor updates in the days after a disclosure, without delaying the first.	GitLab fits only in part: one flaw is in the catalogue, the regex flaws are not shown to be exploited. Wednesday 14 October is a scheduled release day.
NCSC supply chain guidance (reviewed 22 October 2025) and blog (4 June 2026)	Vulnerabilities can be introduced and exploited at any point in the supply chain. Recent attacks exploited implicit trust in CI/CD pipelines. Monitor CI/CD activity, and rotate credentials if compromise is suspected.	Inference: a build server is a supply chain control point. The guidance is written about suppliers and packages, not about GitLab.
UK GDPR Article 33 and the ICO's breach guide	Report a notifiable personal data breach to the ICO within 72 hours of becoming aware of it, where feasible, and give reasons if later. Information may be given in phases.	The clock runs from awareness of a breach, not from the patch. If a compromised GitLab holds personal data (staff names and work email addresses at least, an inference), it starts then.

What a UK organisation should be able to show an assessor or an auditor is shorter than the guidance, and it is mostly dates. The list below is this briefing's reading of the clauses above, not a scheme requirement. The Cyber Security and Resilience Bill and the NIS Regulations were not read for this briefing.

What to do, in the order worth doing

The order follows the NCSC's own: know what you run, update, check whether you were already reached, then close the gap that lets the next one in. This is defender level only. No payload, request or regular expression is given here. If public exploit code appears, do not test your server with it: the NCSC warns that such code has a history of attacking the person who runs it.

What could not be verified

Status as read at 14:52 BST on 12 October 2026 and re-checked at 15:11 BST. Each line says how this briefing handles the gap.

Question	Status	How this briefing handles it
Is CVE-2026-97229 exploited?	Not in CISA's catalogue. GitLab and BleepingComputer are silent. No web result mentions the identifier.	Stated as not shown, and time-stamped.
The NVD and CVE.org records	CVE.org: the record does not exist. NVD: no results.	Scores quoted from GitLab's page and attributed to GitLab.
What the "certain conditions" are, and how hard the flaw is to trigger	Not stated. GitLab's vector says attack complexity Low, which is its own rating.	Reported as not stated.
How an unauthenticated user reaches a CI/CD configuration, and whether a public project is enough	Not stated.	No guess made.
Whether restricting access to the instance protects it	Not stated.	Offered only as temporary narrowing, labelled inference.
A workaround	None on the page.	Upgrading is the only stated action.
Whether CVE-2026-97229 bypasses the 23 September fix	Not stated. The Ruby regexp patches in the bug-fix lists are not linked to any CVE.	Both facts given, no conclusion drawn.
19.1 and earlier	The advisory's range starts at 19.2. Nothing else is said.	Reported. Not assumed safe.
Whether GitLab's maintenance policy makes an older version supported for Cyber Essentials	The policy was not read.	Left to the reader's assessor.
BleepingComputer's description of the compiler, and its 09:09 timestamp	Secondary. The page gives no time zone.	Used for context and for what it quotes from GitLab.
Any victim, exposure count or install base	None published.	None claimed.

The question that exposes the gap

Five labels each sound like a control. On GitLab's page, none of them is one for a self-managed server. The page offers one control, a version number, and the previous one is 19 days old. If a stranger with no account ran one command on your GitLab server tonight, which log would show it, who reads that log, and which secrets in your pipelines would the stranger now hold?

Key facts