GitLab's CVSS-10.0 Vulnerability Is Being Exploited Right Now — Here's Who Actually Owes a CRA Article 14 Report

On 2026-09-10, GitLab shipped 19.3.2, 19.2.6, and 19.1.8 for self-managed Community and Enterprise Edition. The headline fix is CVE-2026-85706, an unauthenticated path-traversal bug in the repository commits API with a maximum CVSS score of 10.0. Twenty-four hours later, on 2026-09-11, CISA added it to the Known Exploited Vulnerabilities catalog with a remediation deadline of 2026-09-14 for federal civilian agencies. That deadline has already passed — if you run a self-managed instance and haven't patched, you're not looking at a theoretical risk window anymore.

There's a second, less-noticed coincidence in the timing: 2026-09-11, the day this vulnerability went from "patched" to "actively exploited," is also the exact day CRA Article 14 — the Cyber Resilience Act's 24-hour/72-hour/14-day vulnerability-reporting duty — became legally binding. We wrote about this same calendar collision for Forgejo six days ago, and the conclusion there was "no manufacturer, nobody owes a report for the tool itself" — Forgejo is community-governed. GitLab is the opposite case, and it's worth walking through precisely, because the reporting duty attaches somewhere real this time.

What the vulnerabilities actually are

GitLab's own patch notes list two critical issues in the same release, quoted directly rather than paraphrased:

CVE-2026-85706 (CVSS 10.0): "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." Affects CE and EE from 18.7 up to (not including) 19.1.8, 19.2 up to 19.2.6, and 19.3 up to 19.3.2.

CVE-2026-87719 (CVSS 9.9, EE only): an authenticated user with Duo Chat access could submit "a specially crafted GraphQL subscription argument to bypass serialization and perform server object lookup," exposing Advanced Search instance configuration and credentials. Same affected-version pattern, EE from 18.3 up to the same three patched releases.

The independent security research firm watchTowr published a rapid-reaction technical breakdown of CVE-2026-85706 that's worth reading in full if you run an internet-facing instance. The short version: the vulnerable endpoint is /api/v4/projects/{id}/repository/commits/, and improper path confinement on the file.path parameter lets an unauthenticated attacker walk outside the repository and read arbitrary files off the server — configuration files, CI/CD secrets, SSH keys, anything the GitLab process user can reach. watchTowr called out "the low complexity of exploitation" as the reason for their high-confidence call that this would "rapidly transition to indiscriminate, in-the-wild exploitation" — and their own honeypot network (Attacker Eye) detected exactly that: internet-wide scanning starting around 06:00 UTC on 2026-09-11, hours after GitLab's patch went out and attackers reverse-engineered it from the diff.

That's a materially different risk posture than the Forgejo case. Forgejo's RCE was a proactive fix with no evidence of exploitation at publication time. This one had scanning activity within a day and a federal KEV listing within 24 hours — patch first, read the rest of this after.

Patch and check now, in order

1. Check your version. GitLab's admin area shows it in the footer, or hit GET /api/v4/version on your instance if you have API access.
2. Upgrade immediately to 19.3.2 (from any 19.3.x), 19.2.6 (from any 19.2.x), or 19.1.8 (from any 19.1.x). If you're on 18.7–19.0.x or earlier, upgrade through a supported release path to one of these three, following GitLab's documented upgrade path tooling — don't skip straight to 19.3.2 from a much older release without checking the required stopping points. GitLab.com (the SaaS product) was already running the patched version before this release note published, so this is a self-managed-only action item.
3. If you can't patch same-day, put your instance behind a reverse proxy or WAF rule that blocks requests to /api/v4/projects/*/repository/commits/* containing .. or absolute-path patterns in the file.path query parameter. This doesn't fix the underlying bug, but it closes the specific exploitation path watchTowr documented while you schedule the upgrade.
4. Audit for prior exploitation, not just going forward. Because scanning began the day after patch release, grep your instance's access logs for requests to the commits API with file.path values pointing outside the repo tree (../, absolute paths, or references to files like config/secrets.yml, database.yml, .env, or SSH private key paths). If you find any that predate your patch, treat every credential that could have been in a readable file as compromised — rotate CI/CD variables, deploy tokens, database credentials, and any signing keys stored on that host, and check whether the API rate-limited or logged full request bodies (some proxy configurations only log the path, not query parameters, which is a gap worth closing regardless of this specific CVE).
5. If you run GitLab EE with Duo Chat enabled, treat CVE-2026-87719 as equally urgent even though it needs an authenticated session — any account compromise, including a low-privilege one, becomes a path to Advanced Search configuration and credential exposure.

The CRA Article 14 question, and why GitLab is a different case than Forgejo

CRA Article 14 doesn't create a blanket "anyone who self-hosts vulnerable software owes ENISA a report" rule. It binds manufacturers of products with digital elements, both terms defined in Article 3:

• Product with digital elements: "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately."
• Manufacturer: "a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge."
• Open-source software steward — the lighter-touch category under Article 24 — is explicitly defined as "a legal person, other than a manufacturer," that sustains development of an open-source product without itself marketing it commercially under its own name.

That last exclusion is the whole answer here. GitLab Inc. is a for-profit company that develops GitLab CE and EE and markets both — including the free CE tier, which is how the "or free of charge" language in the manufacturer definition matters — under its own trademark, as part of a commercial business built on paid EE tiers and GitLab.com hosting. It isn't a foundation sustaining someone else's project; it's the entity building and selling the product. That puts GitLab Inc. squarely in the manufacturer bucket, not the steward bucket that let Forgejo's maintainers off the hook in our earlier analysis. GitLab Inc. being a US-incorporated company doesn't change this: the CRA, like GDPR and the AI Act before it, applies to products placed on the EU market regardless of where the manufacturer is based — non-EU manufacturers of in-scope products are required under Article 18 to designate an EU-based authorised representative.

So for CVE-2026-85706 and CVE-2026-87719 specifically — both now confirmed actively exploited per the CISA KEV listing — the Article 14 clock (24-hour early warning to the coordinating CSIRT and ENISA, 72-hour full notification, 14-day final report once a fix is available) runs against GitLab Inc. as manufacturer, not against your organization for running a self-managed instance. We have no visibility into whether GitLab Inc. filed a report through the CRA's single reporting platform — that's not public information — but the obligation, if it exists at all here, sits with them. This is worth naming plainly because it's the first real-world test case most of our readers will actually recognize: a commercial vendor, a CVSS-10.0 bug, active exploitation, and a reporting regime that went binding on literally the same day the exploitation started.

What that does — and doesn't — take off your plate

Not owing an Article 14 report doesn't mean you owe nothing. Two separate obligations can attach to your organization independently of GitLab Inc.'s manufacturer duty:

The practical upshot: even in a case like this, where a large commercial vendor clearly carries the manufacturer-side reporting duty, self-hosting doesn't buy you a pass on patch discipline or on your own regulatory clocks. It just means you're reading the right regulation (NIS2, if it applies to you) instead of the wrong one (CRA Article 14, which doesn't reach an internal deployment of someone else's commercial product). We went through the mechanics of what actually happens when a report is filed in our Article 14 single-reporting-platform runbook if you want the manufacturer-side process in detail, even though — per the analysis above — it's GitLab Inc.'s process to run this time, not yours.

If you're weighing self-managed GitLab against a managed alternative for EU-data-residency reasons independent of this incident, that's a separate comparison we've covered elsewhere — this post is specifically about the patch-now-and-know-your-clock question for whichever GitLab deployment model you're already running.

Patch first. Then figure out which regulatory clock, if any, is actually yours to watch — for most self-managed GitLab operators reading this, after 2026-09-16, the honest answer is "none from CRA, but check NIS2 if you're in scope, and check your logs regardless."