Published on gastropod.io on 09-17-2026

GitLab CVE-2026-85706 Lets Unauthenticated Attackers Read Server Files; Probing Began the Morning After the Patch

Tags: vulnerability-intelligence, software-supply-chain-security, gitlab, ci-cd-security, path-traversal, cisa-kev, credential-theft

GitLab released versions 19.3.2, 19.2.6, and 19.1.8 of Community Edition and Enterprise Edition on September 10 (GitLab patch release). The most severe fix is CVE-2026-85706, rated CVSS 10.0: a path traversal in the repository commits API. Improper path confinement combined with missing authentication enforcement lets an unauthenticated user read arbitrary files from the GitLab server. Affected versions are 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. GitLab.com and GitLab Dedicated were already patched. Every self-managed deployment type needs the upgrade, including Omnibus, source, and Helm chart installs.

watchTowr observed in-the-wild probes against its honeypots starting at 06:00 UTC on September 11. The only prerequisite watchTowr identified is that the instance hosts at least one public project. CISA added the CVE to its Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until September 14 to remediate. It is the second critical self-managed GitLab flaw in a few weeks, after the GraphQL code injection tracked as CVE-2026-19478 (The Hacker News). The same release also fixes CVE-2026-87719 (CVSS 9.9), an Enterprise Edition deserialization flaw that lets an authenticated user with Duo Chat access obtain Advanced Search configuration and credentials through a crafted GraphQL subscription argument.

To look for exploitation attempts, search web server logs for POST requests to /api/v4/projects/{id}/repository/commits/ that contain a file.path parameter (Security Affairs).

The files readable through this flaw include SSH keys, database credentials, deploy tokens, CI/CD variables, and other configuration data. Upgrading stops new reads. It does not revoke anything an attacker already copied. For an instance that was reachable from the internet while unpatched, rotate every secret the GitLab service account could read: runner registration tokens, deploy tokens, CI/CD variables, database credentials, integration and webhook tokens, and SSH keys.

A self-managed GitLab instance usually stores source code, runs CI, and often hosts the organization's package and container registries as well. Deploy tokens and CI variables let whoever holds them publish packages, push container images, and trigger pipelines under an identity the organization already trusts. Stolen CI credentials that stay valid after the initial incident were also the path in the JetBrains Cadence breach, which I have already covered here: https://gastropod.io/news/compromised-jetbrains-cadence-due-to-teamcity-sever-vulnerabilities.

After rotation, the response team needs a list of every package and image version published or consumed while the stolen credentials were valid. The start of that window is uncertain. The vulnerable code shipped starting with 18.7, so for an internet-facing instance the window starts when an attacker could first have found the flaw, which may be earlier than the September 10 disclosure.

For builds that resolve packages and images through Gastropod, that list comes from records Gastropod already keeps. Gastropod identifies every artifact by PURL and sha256 digest and logs each pull with the user or token, source IP, and time. Filtering that log by date range returns every version that entered a build during the exposure window, and the digest history shows whether a given version changed between pulls. The blast-radius graph shows which services depend on any version the team decides to distrust, and a block rule at intake stops that version from being pulled again. Gastropod's hosted repositories restrict publishing to accounts with the publisher role and use scoped API tokens, so a credential read from a GitLab server does not grant publish rights in Gastropod. Gastropod does not detect the file read itself. Patching, log review, and secret rotation on the GitLab host cover that part.

The product page shows the per-pull audit log and blast-radius views.

Sources: