An arbitrary file read on a GitLab server is not “just disclosure.” The same host may hold database credentials, application secrets, repository data, integration tokens, and the keys that protect other stored credentials.

GitLab fixed CVE-2026-85706 on September 10. CISA added it to the Known Exploited Vulnerabilities catalog the next day and set a September 14 remediation deadline for US federal civilian agencies. Self-managed GitLab owners should treat the issue as both an emergency patch and a compromise-assessment task.

TL;DR

  • CVE-2026-85706 is a CVSS 10.0 path-traversal and missing-authentication flaw in the repository commits API.
  • Under certain conditions, an unauthenticated attacker can read arbitrary files from affected GitLab CE and EE servers.
  • Affected ranges start at GitLab 18.7. Fixed patch releases are 19.1.8, 19.2.6, and 19.3.2; upgrade to a current supported release on your branch.
  • GitLab.com was already patched. GitLab Dedicated customers do not need to act; this response is for self-managed installations.
  • CISA’s KEV entry establishes known exploitation. Patch, preserve evidence, hunt API requests, and rotate secrets according to what could have been read.

What the Vulnerability Allows

GitLab attributes the flaw to improper path confinement and missing authentication enforcement in the repository commits API. The vendor says an unauthenticated user could, under certain conditions, read arbitrary files from the server.

The affected versions are precise:

BranchAffectedFixed
18.7 through 19.118.7 up to, but not including, 19.1.819.1.8 or later supported release
19.2Earlier than 19.2.619.2.6 or later supported release
19.3Earlier than 19.3.219.3.2 or later supported release

The same patch release fixes CVE-2026-87719, a CVSS 9.9 GitLab EE deserialization issue. That second flaw requires an authenticated user with Duo Chat access and can expose Advanced Search configuration and sensitive credentials. It reinforces the case for installing the complete patch release rather than trying to shield one URL.

CISA’s September 11 KEV entry supersedes the earlier “probing observed” stage. Public reporting initially described requests searching for vulnerable systems; the official catalog now classifies CVE-2026-85706 as known exploited. CISA does not identify a ransomware campaign, and the public sources do not justify attributing the activity to a named actor.

Patch Without Destroying the Timeline

Take a configuration backup and preserve logs according to your existing response procedure, but do not delay the upgrade to build a perfect evidence collection. Capture volatile and short-retention data first, record the current version and exposure, then patch every production, standby, staging, and disaster-recovery instance.

For Linux package installations, inspect GitLab Rails API and production logs together with NGINX access logs, reverse-proxy or WAF telemetry, load-balancer logs, and any retained packet or flow data. GitLab documents api_json.log and production_json.log as structured request sources.

Hunt for HTTP POST requests to repository commit API paths such as:

/api/v4/projects/<project>/repository/commits/

Prioritize requests containing a file.path parameter, path separators or traversal-like encoding, an unauthenticated identity, unusual response size, or source addresses that touched many projects or instances. This pattern comes from public reporting and is a hunt lead, not proof that every matching request exploited the flaw. Preserve correlation IDs so the same request can be followed across GitLab and proxy logs.

A File Read Becomes a Trust Problem

If suspicious access is found—or logs cannot show what was read—scope the response from the files reachable to the privileges those files confer. Do not blindly regenerate /etc/gitlab/gitlab-secrets.json: GitLab warns that rotating its Rails database-encryption keys incorrectly can make encrypted database values unreadable.

Build a deliberate rotation plan instead:

OwnerActionClose only when
GitLab platformUpgrade every self-managed instance and verify the running version after services restart. Restrict management access and remove abandoned instances from DNS and load balancers.Inventory, network exposure, and reported running versions agree; no affected build remains reachable.
SOC and IRPreserve API, Rails, NGINX, WAF, identity, and host telemetry. Hunt the commits API and correlate suspicious reads with later logins, token use, repository access, and CI/CD activity.Each suspicious source and correlation ID is explained or escalated, with log gaps recorded as uncertainty rather than “no compromise.”
Secrets ownersRotate database, object-storage, SMTP, OAuth, webhook, integration, deploy, personal-access, project, group, and runner credentials that could have been exposed. Revoke active sessions where relevant.Old credentials and sessions fail, new credentials are scoped, and first use of each replacement matches an expected workload.
GitLab administratorHandle gitlab-secrets.json only through GitLab’s documented secret-rotation procedure. Validate decryption before and after any change.Encrypted CI/CD variables, tokens, and other protected database values remain usable, while exposed signing and session secrets have been replaced safely.
CI/CD ownersReview recent pipeline, runner, variable, deploy-key, release, and package-registry activity. Isolate privileged and persistent runners from untrusted projects.Unexpected jobs and runner registrations are investigated; production credentials are no longer available to jobs that do not require them.

Network controls can reduce exposure while patching, but a WAF rule is not a verified fix for parser and encoding variations. If an instance cannot be upgraded immediately, remove it from untrusted networks and follow GitLab and CISA guidance. Do not leave a public login page in place and call it “internal enough.”

The patch closes the read path. Recovery closes the credentials, sessions, and automation paths that a successful read may already have opened.

Sources