GitLab's Patch Race Against Active Exploits

Attackers began probing for a maximum-severity GitLab vulnerability within hours of its public disclosure, according to preemptive exposure management firm watchTowr — activity that began at 06:00 UTC on September 11, 2026. The speed of that response, and the low bar for exploitation, are the two details that make this patch cycle different from a routine vendor release.

GitLab has released patches for multiple flaws, including CVE-2026-85706, a path traversal issue in the repository commits API rated CVSS 10.0. A second critical bug in GitLab Enterprise Edition, an insecure deserialization flaw tracked as CVE-2026-87719 with a CVSS score of 9.9, was patched in the same release.

A read primitive with maximum severity

The headline flaw is an improper path confinement problem in the repository commits API. Per GitLab, the issue stems from "improper path confinement and missing authentication enforcement in the repository commits API" — a combination that, under certain conditions, lets an unauthenticated user read arbitrary files from the GitLab server.

A missing authentication check paired with an unconfined path is a familiar shape: the API is reachable without credentials, and the path parameter is not restricted to the directory the endpoint was meant to serve. What an attacker can reach through that gap is the part that matters. watchTowr said the issue allows an external attacker to read log files and GitLab-specific configuration files, which in practice can yield credentials, secrets, and sensitive information.

The CVSS score of 10.0 reflects the worst case on both axes: no authentication required to reach the vulnerable endpoint, and a read primitive deep enough to expose secrets the rest of the platform trusts.

Who is exposed, by version

The flaw affects specific release lines of both GitLab Community Edition and Enterprise Edition. According to GitLab, the impacted ranges are:

• All versions from 18.7 before 19.1.8
• All versions from 19.2 before 19.2.6
• All versions from 19.3 before 19.3.2

The fixes are available in released patches — versions 19.3.2, 19.2.6, and 19.1.8. Any self-managed instance sitting in one of the above ranges is exposed until it is upgraded or its public access is restricted.

One public project is all it takes

The exploitation bar is unusually low. According to Jake Knott, head of threat intelligence at watchTowr, the only prerequisite is that at least one public project must exist on the instance. That is a near-default state for many GitLab deployments, particularly those used for open-source work or public documentation, which removes the usual reconnaissance step of finding a bespoke misconfiguration before attacking.

Because the vulnerable surface is the repository commits API, the endpoint is also reachable in the ordinary course of using the product. An attacker does not need an account, an access token, or an approved role in a project to send a request at it.

Credentials and CI/CD secrets at risk

The value of the read primitive goes beyond whatever happens to sit in a log directory. GitLab configuration files and logs frequently contain the material that ties a deployment together: tokens used by runners, credentials for connected services, and secrets referenced by CI/CD pipelines. Once that material is in hand, the blast radius extends well past the GitLab server itself.

Knott framed the appeal directly in a statement shared with The Hacker News.

"This is the second instance of a critical severity GitLab vulnerability in recent weeks, following the previous GraphQL code injection (CVE-2026-19478) that was almost immediately actively exploited," Jake Knott, head of threat intelligence at watchTowr, said in a statement shared with The Hacker News. "Exploitation requires just one requirement, at least one public project must exist."

— Jake Knott, head of threat intelligence at watchTowr

The same statement tied the pattern to what attackers do after they get in.

"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, which as we've seen throughout this year has been a favorite of attackers."

— Jake Knott, head of threat intelligence at watchTowr

The comparison to CVE-2026-19478 matters because it establishes a tempo rather than a hypothetical. That GraphQL code injection bug was, per Knott, almost immediately actively exploited after disclosure, and it is now the second critical GitLab vulnerability in recent weeks.

Eyes on the logs

For defenders, watchTowr's guidance points to a concrete detection opportunity rather than a general warning. The firm said organizations should review log files for HTTP POST requests to '/api/v4/projects/{id}/repository/commits/' URIs containing 'file.Path' parameters to identify potential exploitation attempts.

That signature is specific. The endpoint path, the HTTP method, and the parameter name together describe the shape of an attempt to reach the vulnerable code path, which means an organization with the relevant request logs retained can check retrospectively — not just forward — for probes that may have already occurred.

Knott's statement on the likely trajectory was direct.

"Based on the history, the transition of this vulnerability to indiscriminate mass exploitation is likely not far away, and defenders have limited time to act."

— Jake Knott, head of threat intelligence at watchTowr

The second critical flaw in the same release

The repository commits API bug is not the only critical issue fixed in versions 19.3.2, 19.2.6, and 19.1.8. GitLab also patched an insecure deserialization vulnerability in GitLab EE, tracked as CVE-2026-87719 with a CVSS score of 9.9, that could result in information disclosure.

This one is authenticated rather than open to anyone. GitLab said the flaw could allow an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument to bypass serialization and perform server object lookup.

The distinction is worth keeping straight when triaging. CVE-2026-85706 is reachable without credentials; CVE-2026-87719 requires an authenticated account with Duo Chat access. Both are rated critical, and both are fixed in the same upgrade — which simplifies the remediation decision even though the two bugs differ in who can reach them.

Patch now, or close the door

GitLab's guidance for organizations running self-managed instances exposed to the internet is to apply the patches as soon as possible, or to limit public access where it is not required. For teams that cannot move immediately, restricting who can reach the instance changes the exposure profile: an internet-facing GitLab server in an affected version range is reachable by anyone with the endpoint path, while an internal-only deployment is reachable only by those already on the network.

Applying the upgrade addresses both critical issues at once. Checking logs for the '/api/v4/projects/{id}/repository/commits/' pattern with 'file.Path' parameters addresses the separate question of whether anything already tried.

The affected version list is the practical checklist. An instance is exposed if it is running any version from 18.7 before 19.1.8, from 19.2 before 19.2.6, or from 19.3 before 19.3.2. Upgrading to 19.1.8, 19.2.6, or 19.3.2 moves it out of that set.

The reason this particular bug deserves attention beyond its severity score is the combination of prerequisites: no authentication to reach the vulnerable endpoint, and only the existence of a single public project for exploitation to be viable. That is not an exotic configuration. It is a common one, and watchTowr's observation that probes began at 06:00 UTC on September 11, 2026, suggests attackers were already testing the endpoint while many administrators were still reading the advisory. For organizations running self-managed GitLab, the practical question is not whether the flaw is serious — a CVSS 10.0 read primitive that can expose credentials answers that — but how quickly the instance can be moved out of the affected range or cut off from the public internet. The detection signature for existing logs offers a parallel path: it can tell defenders whether an attempt already reached their server, even in cases where patching is delayed. Given Knott's assessment that the shift toward indiscriminate mass exploitation is likely not far away, the window for both actions — upgrade and log review — is narrow by the source's own account.