GitLab CVE-2026-85706: Four Lines Still Without a Fix

By Scott Bissett · Published: September 11, 2026 · EOL Watch — news analysis · Read at GitLab's patch-release post and maintenance policy, CISA's catalog, and our tracked GitLab data

GitLab has a CVSS 10.0 flaw that lets an unauthenticated stranger read files off a self-managed server, CISA put it on the Known Exploited Vulnerabilities catalog on September 11, 2026 with a three-day deadline, and on the day we published the fix existed for exactly three release lines. GitLab's critical patch release of September 10, 2026 shipped 19.3.2, 19.2.6 and 19.1.8 and stated the impacted versions as “all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2.” Read the two halves of that sentence together. Every line from 18.7 up was affected; only 19.1, 19.2 and 19.3 got a build that day.

Update, October 18, 2026. GitLab has since backported the fix to two of the six unsupported lines. Its critical patch release for 19.0.9 and 18.11.12 opens: “On September 23, 2026, we released versions 19.0.9 and 18.11.12.” The post says those versions carry the fixes for CVE-2026-85706 and CVE-2026-87719 first shipped on September 10, and that GitLab made them available outside its standard maintenance policy. Its impacted range now starts at 18.7 and ends at 18.11.12 and 19.0.9 for the two older lines. No build was released for 18.10, 18.9, 18.8 or 18.7: those four lines are still inside the range with no fixed build. Since publication, 19.1 left security support on September 17, 2026 and 19.2 on October 15, 2026.

That is not an oversight. GitLab's maintenance policy, read live on September 11, backports security fixes to “the previous two monthly releases in addition to the current stable release” and listed the maintained versions as 19.3, 19.2 and 19.1. We wrote in August that this 91-day window would leave 19.0 exposed the first time a serious flaw landed. It landed.

The lifecycle fact that decides your weekend. GitLab 19.0 left security support on August 20, 2026. 18.11 left on July 16, 2026, 18.10 on June 18, 2026, 18.9 on May 21, 2026, 18.8 on April 16, 2026 and 18.7 on March 19, 2026. All six are inside GitLab's impacted range. At publication none had a fixed build; since September 23, 19.0 and 18.11 have one (19.0.9 and 18.11.12), and the other four still do not. And 19.1, the oldest line fixed on September 10, left security support on September 17, 2026.

What the flaw is

CVE-2026-85706 is a path traversal in the repository commits API. In GitLab's words, “under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement.” GitLab scores it CVSS 10.0 (network, low complexity, no privileges, no user interaction, changed scope, high confidentiality and integrity impact) and credits s3ntago through its HackerOne programme. GitLab.com was patched before the post went out; GitLab Dedicated customers need no action. The exposure is self-managed instances, which is to say the servers holding an organisation's source, CI/CD variables and deployment credentials.

CISA added it on September 11, 2026, the day after the patch, with a due date of September 14, 2026 for federal civilian agencies. watchTowr, Horizon3 and the trade press reported exploitation attempts within a day of disclosure.

Quick answer: GitLab 19.5 is supported until January 21, 2027, its end-of-support date. Active support for GitLab 19.5 ends on November 19, 2026; security fixes continue until that end-of-life date. The next GitLab version to reach end of life is 19.3, on November 19, 2026. 65 of 68 tracked GitLab versions are past end of life; the most recent to reach it, 19.2, did so on October 15, 2026. Every GitLab version's release and end-of-support date is on the GitLab lifecycle page.

Running GitLab past end of life?

Extended support past the official EOL date exists for many products in this position — whether it covers GitLab is exactly what we check. Tell us where to reach you and we’ll reply with matched options and pricing guidance — or an honest “no vendor covers this.” Free, no obligation.

Every affected line against the fix list

Fixed builds below are as of October 18, 2026. Dates are our tracked GitLab data, read from GitLab's own release feed every night. “Security support ends” is the day the line drops out of GitLab's three-version maintained set.

Line	First release	Security support ends	Fixed build	Position
19.3	August 20, 2026	November 19, 2026	19.3.2	Maintained
19.2	July 16, 2026	October 15, 2026	19.2.6	Unsupported since its end date
19.1	June 18, 2026	September 17, 2026	19.1.8	Unsupported since 19.4 shipped
19.0	May 21, 2026	August 20, 2026	19.0.9 (backport, September 23)	Unsupported; one-off backport
18.11	April 16, 2026	July 16, 2026	18.11.12 (backport, September 23)	Unsupported; one-off backport
18.10	March 19, 2026	June 18, 2026	None	Affected, unsupported
18.9	February 19, 2026	May 21, 2026	None	Affected, unsupported
18.8	January 15, 2026	April 16, 2026	None	Affected, unsupported
18.7	December 18, 2025	March 19, 2026	None	Affected, unsupported

GitLab's range starts at 18.7 and says nothing about 18.6 and earlier, so neither do we. An instance on 18.6 or older is out of GitLab's impacted statement and out of support by a wider margin still; it needs the same upgrade for a longer list of reasons.

What we are not saying. GitLab has not called 19.0 or 18.x unfixable; it applied its published policy, which limits backports to three lines, and on September 23 made an exception for 19.0 and 18.11. We are also not saying the flaw has been exploited against a specific unsupported instance. We are saying what GitLab's impacted range and its maintained-version list say together: at publication six lines that real estates run were inside the range and outside the fix, four still are, and the calendar explains why.

The 19.1 trap

The shortest path to CISA's September 14, 2026 deadline for anyone on 19.1 was 19.1.8, one patch step on the same line. It was also the shortest path to being unsupported again. GitLab ships its monthly release on the third Thursday, and 19.1's security support ended on September 17, 2026, the day 19.4 shipped and the maintained set became 19.4, 19.3 and 19.2. The next critical patch, on September 23, was built for those three lines (19.4.1, 19.3.3 and 19.2.7), and a 19.1.8 instance was outside it. 19.2.6 bought time until October 15, 2026, which has also passed; 19.3.2 buys until November 19, 2026. An upgrade made for this CVE today should land on a line GitLab currently maintains.

What to do, by line

19.3: still maintained; install the newest patch on the line (19.3.2 or later carries the fix). GitLab publishes upgrade paths for each line; a same-line patch is a short one.

19.2 or 19.1: 19.2.6 and 19.1.8 carry the fix, but both lines are now out of security support. Patch first if you have not, then upgrade to a line GitLab currently maintains.

19.0 or 18.11: since September 23, 2026 there is a build to install: 19.0.9 or 18.11.12. Install it now, then plan the upgrade, because both lines remain out of security support and the next flaw may not get a backport.

18.10, 18.9, 18.8, 18.7: there is nothing to install on your line. Take the instance off the public internet today if it is on it, then follow GitLab's upgrade path to a currently maintained line. GitLab's own advice for public-facing self-managed instances is to patch immediately or remove public access, and for these lines only the second half is available until the upgrade lands.

Everyone self-managed: the flaw is an unauthenticated file read on the server. After patching, treat anything readable from the GitLab host as potentially read: rotate CI/CD variables and runner registration tokens, and review access logs on the commits API for the period since the patch release.

Federal agencies: CISA's due date was September 14, 2026, under BOD 26-04.

Frequently Asked Questions

Which GitLab versions fix CVE-2026-85706?

GitLab's critical patch release of September 10, 2026 ships the fix in 19.3.2, 19.2.6 and 19.1.8 for Community Edition and Enterprise Edition. GitLab.com is already patched and GitLab Dedicated customers need no action. On September 23, 2026 GitLab also released 19.0.9 and 18.11.12, which backport the same fix to those two lines outside its standard maintenance policy. 18.10, 18.9, 18.8 and 18.7 have no fixed build.

Is there a fix for GitLab 19.0 or 18.x?

For 19.0 and 18.11, yes, since September 23, 2026: GitLab released 19.0.9 and 18.11.12, backporting the fix outside its standard maintenance policy, which covers only the current stable release and the two monthly releases before it. Both lines remain out of security support (19.0 since August 20, 2026). For 18.10, 18.9, 18.8 and 18.7, no: they are inside GitLab's stated impacted range and have no fixed build, so the only route is an upgrade to a line GitLab currently maintains.

Is GitLab 19.1.8 a safe place to land?

Only briefly. GitLab 19.1 left security support on September 17, 2026, when 19.4 shipped and the maintained set moved to 19.4, 19.3 and 19.2. An instance patched to 19.1.8 for CISA's September 14 deadline was unsupported three days later. 19.2 then left security support on October 15, 2026. Land on a line GitLab currently maintains, listed on its maintenance policy page.

What is the CISA deadline?

CISA added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog on September 11, 2026 with a due date of September 14, 2026 for federal civilian agencies, the three-day window CISA reserves for its most urgent entries.

GitLab — every monthly line with its release day, end of bug fixes and end of security fixes, from GitLab's release feed
GitLab 19.0 stopped receiving security patches on August 20 — the 91-day window, written before this flaw landed
GitLab Runner — rides the same clock
Exploited & Unpatchable — the feed of KEV entries on products past their fix window
How we verify our dates — the rules every number on this site is held to