Self-Managed GitLab Gets Another 10.0 and a KEV Deadline

GitLab’s unauthenticated file-read bug, CVE-2026-85706, is on the U.S. government’s known-exploited list, with a September 14, 2026 patch deadline for federal agencies. The flaw scored a perfect 10.0 and needs no login.

Self-managed Community Edition and Enterprise Edition servers still on unpatched 19.3, 19.2 or 19.1 builds are the ones that have to move. GitLab.com already runs the patched code, and Dedicated tenants have no action to take.

Federal Agencies Have Until September 14 to Patch GitLab

On September 11, 2026, a day after GitLab shipped fixes, CISA added one known exploited vulnerability to its catalog: CVE-2026-85706. The agency said the listing rests on evidence of active exploitation. Binding Operational Directive 26-04 sets the federal civilian due date at September 14, 2026, and marks the entry for forensic triage, so agencies are expected to look for signs a box was already read before the patch landed.

watchTowr said it reproduced the bug, then saw behavioral probes against its Attacker Eye honeypot network from 06:00 UTC on September 11, 2026. Jake Knott, the firm’s head of threat intelligence, said mass scanning tends to follow GitLab criticals quickly, and that this one can fire in a single HTTP request.

THE CLOCK ON CVE-2026-85706

• The score: CVSS 10.0, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, no privileges and no user click.
• The patch: Self-managed CE and EE move to 19.1.8, 19.2.6 or 19.3.2; GitLab.com and Dedicated are already covered.
• The federal date: CISA’s known-exploited due date is September 14, 2026, with forensic triage required.
• The first probes: watchTowr logged honeypot hits from 06:00 UTC on September 11, 2026.

Public proof-of-concept write-ups and scanner templates began circulating after the advisory. That does not prove every probe stole a file, but it does collapse the old habit of parking a GitLab upgrade in the next maintenance window.

HOW FAST THIS ONE MOVED

1. August 17, 2026: GitLab ships patches for CVE-2026-19478, a 9.4 unauthenticated GraphQL bug that can change or delete public projects.
2. August 19, 2026: watchTowr reports in-the-wild exploitation of that GraphQL flaw within two days of disclosure.
3. September 10, 2026: GitLab releases 19.3.2, 19.2.6 and 19.1.8, including the 10.0 commits-API file read.
4. September 11, 2026: watchTowr records probes from 06:00 UTC; CISA lists CVE-2026-85706 as known exploited.
5. September 14, 2026: Federal civilian agencies must have publicly exposed, high-risk KEV assets remediated under BOD 26-04.

The September 10 advisory is GitLab’s second ad-hoc critical in less than a month. Operators who treated August’s GraphQL patch as a one-off are now in the same queue again, with a government clock attached.

The Commits API Did Not Ask for a Login

GitLab’s critical patch release for 19.3.2, 19.2.6 and 19.1.8 puts the hole in the repository commits API. The company said an unauthenticated user could, under certain conditions, read arbitrary files on the server because of improper path confinement and missing authentication enforcement. Researcher s3ntago reported it through HackerOne.

The vector is the whole story for internet-facing boxes. An attacker does not need an account, a token or a click from someone inside. GitLab still hedges with “under certain conditions,” and that line is doing a lot of work for a 10.0. Knott’s practical bar is thinner: at least one public project on the instance.

The appeal to attackers of GitLab is obvious, as unauthorized access allows an attacker to gain access to source code, CI/CD secrets, credentials, and the ability to inject code into build pipelines, gaining access or poisoning anything downstream of it.

Jake Knott, head of threat intelligence, watchTowr

GitLab’s public write-up describes file reading, not confirmed remote code execution. The CVSS vector also scores integrity high and changes scope; admins should not treat those extra boxes as proven impact. The files still matter. A GitLab host often holds CI/CD variables, runner tokens, deploy keys, cloud credentials and application secrets that sit one step from production.

Affected builds are GitLab CE and EE from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. GitLab said every deployment type is in scope unless a release note says otherwise, including Omnibus, source, Helm and Docker. Issue records stay private on the tracker for 90 days after the fix, which did not stop watchTowr from reproducing the bug from the advisory and the patch itself.

Half of Exposed GitLab Servers Missed the 2021 Patch

Self-managed GitLab has run this drill before, at the same score, with the same split between GitLab.com and everyone who runs their own box.

On April 14, 2021, GitLab patched CVE-2021-22205, an ExifTool image-upload bug that became an unauthenticated remote-code hole. The score started at 9.9 and moved to 10.0 on September 21, 2021, once GitLab confirmed it needed no login. Fixes shipped in 13.8.8, 13.9.6 and 13.10.3, covering versions from 11.9. On November 1, 2021, Rapid7’s Jake Baines wrote that patches had been out for more than six months, that the firm could see just short of 60,000 internet-facing GitLab installs, and that it still found half of internet-facing installs unpatched.

January 2024 repeated the shape with CVE-2023-7028, another 10.0. Password-reset mail could go to an unverified address and take over an account. The Canadian Centre for Cyber Security, in alert AL24-002 on January 15, 2024, said it learned of the bug on January 11 and of multiple proof of concepts on January 12, and warned of account take over via password reset against self-managed services. It told organisations to keep affected GitLab off the internet until patches were in.

THREE GITLAB MAXIMUM-SEVERITY RUSHES

CVE-2026-19478 is the immediate predecessor, not a 10.0. GitLab said an unauthenticated user could remotely modify or delete public projects and user data through a GraphQL directive. Fixes went out in 19.2.4, 19.1.6, 19.0.8 and 18.11.11. Knott called CVE-2026-85706 the second critical GitLab bug in recent weeks after that GraphQL issue was almost immediately exploited. The 2021 lesson sits under all of it: a patch on GitLab.com does not move the long tail of self-hosted servers.

What the Other 17 Fixes Still Open

The same release closes 18 security bugs, two of them critical. Teams that only cherry-pick the 10.0 still leave Enterprise Edition customers on a 9.9 deserializer, a high-severity remote-code path that starts at version 12.3, and several ways for a logged-in Developer to reach protected CI/CD variables.

CRITICAL AND HIGH FIXES IN THIS RELEASE

The remaining ten items are nine medium and one low, including a SAML SSO bypass, a Workhorse senddata credential leak that GitLab dates to 10.1.0, a generic-package swap that can hide a replaced artifact from its owner, and two protected-environment approval bypasses that GitLab engineer Peter Arts found internally.

Duo Chat Can Hand Over Search Credentials

CVE-2026-87719 is EE-only and needs an account with Duo Chat access, which is why it sits behind the 10.0 in every headline. GitLab said a crafted GraphQL subscription argument could bypass serialization, trigger a server-side object lookup, and expose Advanced Search instance configurations and sensitive credentials. Researcher kyyblin reported it. The score is 9.9, with high impact on confidentiality, integrity and availability. Any shop that turned Duo Chat on for staff should treat this as a same-day patch, not a follow-up ticket.

A Project Import Still Reaches Code Execution

CVE-2026-88765 is the long-lived one. GitLab said an authenticated user could import a crafted project export, overflow the Unicode conversion buffer used in Advanced Search indexing, and get remote code execution. The hole is scored 8.5 with high attack complexity, and it affects EE from version 12.3 through the patched builds. Researcher joaxcar reported it. Teams that allow project imports from outside their trust boundary should review recent imports, even after they upgrade.

Protected Variables Leak to the Developer Role

The 10.0 is the internet-facing emergency. The CI/CD bugs are how GitLab gets owned from the inside, by someone who already has a Developer seat or a Security Manager role and wants production credentials.

CVE-2026-79708 let a Developer run a scheduled pipeline execution-policy test against group projects and read protected CI/CD variables meant for higher roles, a scope-check failure GitLab scored 8.5 on EE from 19.0. CVE-2026-13210, scored 7.7 on CE and EE from 15.7, let an authenticated user pull CI/CD variables outside their environment because the environment-scope pattern matcher did not validate input. CVE-2026-16794, a 4.3 on EE from 18.11, let a Security Manager run arbitrary CI/CD jobs and obtain protected variables in group projects through compliance-framework management.

Those variables are often deploy tokens, signing keys, cloud access keys and registry passwords. A Developer who can read them does not need the commits-API 10.0. They already sit on the path into production.

SECRETS TO ROTATE AFTER A SUSPECT HIT

• GitLab tokens: Personal access tokens, project and group tokens, and incoming-mail tokens stored on the host.
• Runner material: Registration and authentication tokens for GitLab Runners, plus any cache credentials those runners hold.
• Deploy keys: Deploy tokens, deploy keys and webhook secrets that can push or pull outside the GitLab UI.
• CI/CD variables: Protected and environment-scoped variables, including cloud keys, package-registry passwords and signing secrets.
• Search and app secrets: Advanced Search credentials on EE, database passwords, and anything in GitLab configuration files the git user can read.

If logs show odd commits-API traffic from before the upgrade, rotate in that order and then check for new users, runners, webhooks, scheduled pipelines and CI/CD variables that nobody on the team added.

Downtime Is Built Into the Single-Node Patch

GitLab said the patch includes database migrations. A single-node instance will sit down while those migrations finish, because GitLab will not start until they complete. Multi-node sites can stay up if admins follow GitLab’s zero-downtime upgrade procedures. Version 19.3.2 also carries post-deploy migrations that can run after the main upgrade.

That downtime is a reason to prep backups, disk space and the documented upgrade path. It is not a reason to wait. Unsupported or far-behind installs may need staged stops rather than a jump straight to 19.3.2. GitLab’s own note is blunt: upgrade affected installations to the latest version as soon as possible. Restricting the UI to a VPN or an allowlist while the patch rolls is only a temporary cut in exposure.

Hunt the Commits API Before September 14

watchTowr told defenders to search logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ that carry a file.path parameter. Look for encoded traversal sequences, odd source addresses, repeated errors, and responses that involve files with no business in a repo commit. GitLab has not published a full exploit format, so a single signature will miss variants. Compare the traffic with the instance’s normal commits-API pattern.

Internet-facing self-managed GitLab is the first pile. Internal boxes still need the other 17 fixes, because several of those bugs start from an authenticated Developer, a Security Manager, or a Duo Chat user. After the upgrade, preserve logs if the hunt looks dirty, treat reachable secrets as burned, and rebuild if you cannot show the host was clean.

CISA’s due date for federal civilian agencies is September 14, 2026. The catalog line also asks for forensic triage on this CVE, which is a formal way of saying: check whether someone already read the files.