GitLab’s September 10 critical patch release closes an unauthenticated arbitrary file read in the repository commits API and scores it 10.0 — a number that rests on an integrity impact the advisory’s own description does not describe, in a release that ships no patched 18.x build for the 18.7 installations it names as affected.
What happened
GitLab published a critical patch release on September 10, 2026, shipping versions 19.3.2, 19.2.6, and 19.1.8 and closing 18 security issues. At the top of the table is CVE-2026-85706, which GitLab labels Critical and scores 10.0.
GitLab’s own description of the flaw, verbatim: “GitLab has remediated an issue that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.” The release credits the report to the researcher s3ntago, submitted through GitLab’s HackerOne bug bounty program.
The affected range, as the release states it: all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N.
GitLab’s recommended action, verbatim from the release page: “We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible.” Separately, the company states that “GitLab.com is already running the patched version” and that “GitLab Dedicated customers do not need to take action.” The people who have work to do are the ones running self-managed GitLab.
The same release carries a second critical issue, CVE-2026-87719, an insecure deserialization flaw in the GraphQL subscription serializer scored 9.9 and affecting GitLab Enterprise Edition from 18.3. Sixteen further issues run from 8.5 down to 3.1, including a buffer overflow in a Unicode conversion wrapper, two denial-of-service flaws in the GraphQL complexity limiter, an incorrect-authorization flaw in the CI/CD environment variable scope matcher, and a SAML single sign-on restriction that is not enforced.
Two research firms published assessments on September 11. watchTowr says it is “observing in-the-wild probes” against the flaw but gives no count and no dates for them. Horizon3 describes building a NodeZero Rapid Response test to validate exploitability and lists the file classes an attacker could reach — “configuration information, credentials, secrets, tokens, SSH keys, database credentials, or other server-side data.” Neither firm published working exploit code, and neither published a number for exposed or probed instances. GitLab itself says nothing about exploitation. Probing is not exploitation, and nothing in the primary sources supports calling this exploited.
As of 1:30 a.m. UTC on September 12, the NVD API returns zero results for CVE-2026-85706. GitLab’s self-assigned score is the only score in circulation.
Why it matters
Two metrics in that vector are carrying the 10.0, and both are worth reading closely, because with no NVD record there is no second opinion to compare against.
Recompute the vector with the integrity metric dropped to I:N — an attacker who can read arbitrary files but not change them — and the base score falls to 8.6. Drop the scope change as well, to S:U/C:H/I:N/A:N, the shape a plain unauthenticated file read usually takes, and it falls to 7.5. The distance between “high severity” and a perfect ten is entirely those two metrics.
The scope change is defensible on its face. Reading gitlab-secrets.json or gitlab.rb off a GitLab server does not stay inside GitLab: it hands over CI/CD variables, runner registration tokens, database credentials, and the keys that sign sessions, all of which are authority over other systems. That is what a changed scope is meant to capture.
The integrity impact is harder to read off the description. I:H asserts a total loss of integrity — the attacker can modify data. The advisory describes a read, and only a read: “could have read arbitrary files from the GitLab server.” Either the description understates what the flaw permits, or the vector overstates it. A third reading is more charitable and probably closest: GitLab is scoring the downstream consequence of reading credentials rather than the primitive itself, on the grounds that stolen signing secrets become write access in the next step. That is a judgment about chained impact, not a metric the description supports, and it is precisely the kind of scoring choice that is invisible to anyone who reads only the number. This publication has covered the same ambiguity from the other direction more than once this month, where a described crash outscored a described takeover.
The second problem is more concrete. GitLab says the flaw affects installations from 18.7 onward, and every fixed version in this release is a 19.x build. There is no 18.x release in the batch. GitLab backports security fixes to the current minor and the two before it, which today means 19.3, 19.2, and 19.1 — so an installation sitting on 18.7 through 18.11 is inside the declared affected range and outside the branch that received a fix. For those operators, “upgraded to the latest version as soon as possible” is not a patch. It is a major-version migration, with the runner, database, and extension compatibility work that implies, under a 10.0.
That gap is worth naming because GitLab’s previous critical patch release, 19.2.4 together with 19.1.6, 19.0.8, and 18.11.11, did carry an 18.x build. The affected range in this release reaches further back than the fix does. We found no statement from GitLab addressing the 18.x case, and the release page does not mention it.
The shape is familiar from this week. A JFrog Artifactory release named as the fix for one cataloged flaw left a second one on the same branch open. A Knowns release named as the fix for five CVEs turned out to be the top of the affected range for a later 9.8. The pattern is not vendors hiding things — it is that an affected-version range and a fix-version list are produced by different processes inside the same company, and nobody reconciles them before publication. The reader who patches to the named version and stops has done what the advisory asked and is still exposed.
Self-managed GitLab is also a worse target than its install base suggests. It is where source code, pipeline definitions, signing keys, and cloud deploy credentials sit in one place, usually behind a single hostname, frequently internet-facing because developers and runners need to reach it. An unauthenticated read primitive against that host is a credential-harvesting operation, not an information disclosure. That is the reason to treat two firms’ reports of reconnaissance as a clock, even though neither is evidence of a breach.
What to do
Upgrade self-managed GitLab to 19.3.2, 19.2.6, or 19.1.8, whichever is on your branch. GitLab.com and GitLab Dedicated are patched and need no action, per GitLab.
If you are on 18.7 through 18.11, there is no patched build on your branch in this release. Plan the move to 19.1.8 and, until it lands, block or tightly restrict unauthenticated access to the repository commits API at the reverse proxy or WAF, and put the instance behind network controls if it is internet-facing.
Search access logs for requests to repository commits API paths carrying traversal sequences, including encoded forms. If you find reads that succeeded, treat it as credential compromise: rotate gitlab-secrets.json, CI/CD variables at every scope, runner registration tokens, personal and project access tokens, database credentials, and any cloud role keys stored on the host.
Apply the same release’s CVE-2026-87719 fix if you run Enterprise Edition 18.3 or later — a 9.9 insecure deserialization in the GraphQL subscription serializer is not a second-tier item, and it reaches further back than the path traversal does.
Sourcing note
Written from GitLab’s critical patch release page for 19.3.2, 19.2.6, and 19.1.8 on docs.gitlab.com, dated September 10, 2026, which is the source for the release date, the CVE list, the verbatim description and recommended-action language, the CVSS vector and score, the affected ranges, and the HackerOne credit. The CVSS recomputations are ours, using the published CVSS v3.1 formula against GitLab’s vector with single metrics changed.
The NVD API was queried for CVE-2026-85706 and returned zero results at 1:30 a.m. UTC on September 12, 2026; there is therefore no NVD-assigned score, no CWE, and no CPE range to compare against GitLab’s. The 18.x question was checked against GitLab’s own release pages, which show an 18.11.11 build in the previous critical patch release and none in this one; we found no GitLab statement on whether 18.x will receive a backport, and that remains unresolved. Added September 11, 2026, 9:10 p.m. Central: the statement that GitLab backports to the current minor and the two before it reflects its published maintenance policy as borne out by the release pattern; the policy page itself was not re-read for this story, and the conclusion that no 18.x build exists in this release rests on the release page’s own version list.
watchTowr’s and Horizon3’s assessments, both dated September 11, 2026, are the source for the reconnaissance reports and the file classes at risk. Both are single-vendor observations with no published counts, and neither reports confirmed exploitation. No exploit code was reviewed because neither firm published any. GitLab has made no statement about exploitation, and this page does not treat the flaw as exploited. cisa.gov returns 403 to automated fetching, so the catalog could not be read directly; the NVD record for this CVE does not exist yet, so there is no cisaExploitAdd to report either way, and the flaw carries no federal deadline as of this writing.