GitLab's Worst-Rated Flaw Needs Just One Public Project

One Public Project Is the Only Requirement

CVE-2026-85706 needs almost nothing from an attacker to work. The flaw sits in GitLab's repository commits API, where improper path confinement and a missing authentication check let an unauthenticated user send a request carrying a file path parameter and read arbitrary files back from the server, no login required. watchTowr's Jake Knott put the barrier to entry in one sentence: "Exploitation requires just one requirement, at least one public project must exist." Most self-managed GitLab instances have at least one, whether the owner thinks of it as public-facing or not.

The flaw carries a CVSS score of 10.0, the maximum the scale allows, and affects GitLab Community and Enterprise Edition versions 18.7 through 19.1.7, 19.2 through 19.2.5 and 19.3 through 19.3.1. A server exposed this way does not just leak source code. The commits API sits close enough to configuration files, CI/CD pipeline definitions and deployment tokens that a successful read can hand an attacker the credentials to move further into whatever that GitLab instance builds and deploys.

A Patch Existed Before the Deadline Did

Less than 24 hours passed between the fix shipping and the first probes hitting watchTowr's honeypots. CISA's own catalog entry followed within hours of that. watchTowr's assessment is that attackers had already reverse engineered and reproduced the vulnerability from the patch itself, the same pattern that turns a disclosure into a race the moment it goes public. CISA's deadline binds only US federal civilian agencies, not a business in Munich or Manchester, but the exploitation timeline it is reacting to does not stop at that border.

The Third One Servola Has Tracked Since August

This is not GitLab's first critical flaw this summer, it is the third one actively probed within roughly four weeks. Servola covered a GitLab flaw bundled with critical issues in Ray and Apple software on August 18, then a GraphQL code-injection flaw in GitLab itself, CVE-2026-19478, on August 24, a bug TheHackerNews's own reporting on this new flaw explicitly ties back to as the prior exploited-shortly-after-disclosure case. Three critical CVEs against one widely self-hosted platform in a month is not a coincidence to shrug off as bad luck. It is a signal that GitLab's attack surface and the speed at which researchers and attackers alike now reverse engineer a patch have outpaced how often most self-managed owners check for one.

None of the three flaws share a root cause. What they share is a compressed window: each was probed or exploited within days of its patch shipping, not weeks. An owner who checked for GitLab updates on a monthly cadence would have missed the safe window on all three.

What Changes for a Business Running Self-Managed GitLab

The concrete step is small: confirm your instance is on 19.1.8, 19.2.6 or 19.3.2 or later, then check access logs for POST requests against the repository commits endpoint carrying a file path parameter, the indicator watchTowr recommends hunting for. The larger step is the one that actually prevents a repeat. NIS2 already asks EU organizations to show they can verify a patch reached every managed system, not just that GitLab published one. A self-hosted instance with no one assigned to watch CISA's KEV catalog or GitLab's own security advisories in real time will keep discovering critical flaws from a news article instead of from a monitoring alert.

A business that treats each of these as an isolated fire drill will handle this one fine and miss the next one at the same speed. A business that assigns someone to own GitLab's patch cadence the way it owns its firewall rules stops being three-for-three on late discovery.

Read next: Exploited Weeks Before PaperCut Ever Patched  |  GitLab's Critical Flaw Spared SaaS, Hit Self-Hosted