What happened

On September 10, 2026 GitLab released critical patch versions 19.3.2, 19.2.6 and 19.1.8 for Community Edition and Enterprise Edition, and told every self-managed installation to upgrade "immediately." The headline fix is CVE-2026-85706, which GitLab describes as a path traversal in the repository commits API: "an unauthenticated user could read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement." GitLab scored it CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N).

The same release fixed a second critical issue, CVE-2026-87719 (CVSS 9.9), an insecure deserialization in GitLab EE reachable by an authenticated user with Duo Chat access. It is not on the KEV catalog.

One day later, on September 11, CISA added CVE-2026-85706 to the KEV catalog as "GitLab Community Edition and Enterprise Edition Path Traversal Vulnerability," based on evidence of active exploitation. The federal remediation deadline is September 14. Singapore's Cyber Security Agency followed with an alert on September 17 stating the flaw is "reportedly being actively exploited, and a proof-of-concept exploit is publicly available." CISA lists ransomware use as unknown. Public reporting does not say who is exploiting it or how many servers have been read.

A note on versions: GitLab's advisory lists affected ranges as 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6 and 19.3 before 19.3.2, while the release announcement names only 19.3.2, 19.2.6 and 19.1.8. Other advisories summarize the affected range as 18.7 through 19.1.7. If you are on an 18.x or 19.0 line, move to a supported fixed release rather than relying on a branch cut-off.

Why it matters if you run public infrastructure

A self-managed GitLab server is rarely just a code host. It holds CI/CD variables, deploy keys, runner registration tokens, integration credentials and configuration files, and it is often reachable from the internet because contractors, runners and webhooks need it to be. An unauthenticated arbitrary file read on that server can hand an attacker the secrets to everything the pipelines deploy to. The time from patch to KEV listing was one day, so "we patch GitLab at the next maintenance window" was already too slow.

What to check this week

  1. List every GitLab instance reachable from the internet, including old instances kept for a migration and GitLab installs on non-standard ports. The sign-in page gives them away even when the version is hidden.
  2. Check the version on the admin /help page while signed in, or with gitlab-rake gitlab:env:info. Anything below 19.3.2, 19.2.6 or 19.1.8 on those lines is vulnerable.
  3. Upgrade to a fixed release. Rapid7 notes the updates include database migrations, so single-node installs need downtime. Plan for it today, not next week.
  4. Review logs for the commits API. Look through GitLab and reverse-proxy logs for unusual unauthenticated requests to the repository commits API since at least September 10.
  5. Rotate secrets if the server was exposed and unpatched. Treat CI/CD variables, tokens and any credentials stored in files on the server as potentially read. Rapid7 recommends looking for signs of compromise even after the update is applied.
  6. Ask whether GitLab needs to be public at all. An allowlist or VPN in front of the web interface turns the next unauthenticated GitLab bug from an emergency into a patch.

How Attack Surface Scan covers this

Attack Surface Scan recognizes GitLab by its sign-in page on hosts under your verified domains, including hosts found through certificate transparency logs. GitLab does not show its version to anonymous visitors, so in most cases we cannot confirm the exact release. GitLab is one of the edge products where we then raise a potential match for KEV-listed CVEs like this one, capped at medium severity and tagged potential, with instructions for checking the real version. Where a version is visible, the match is against that exact version and KEV-listed CVEs are ranked first. We do not send exploit payloads or attempt file reads. See Vulnerability matching for the details.

Sources