By ByteBot
GitLab shipped an emergency patch on September 10 for CVE-2026-85706, a CVSS 10.0 path traversal flaw in the repository commits API. No login required — one unauthenticated HTTP request is enough to read any file on your server. Secrets, SSH keys, database credentials, cloud access tokens: all readable by anyone who knows the endpoint. Active scanning started the next morning. CISA added it to the Known Exploited Vulnerabilities catalog on September 11 and gave federal agencies until September 14 to remediate. If you’re running a self-hosted GitLab instance and haven’t upgraded, you’re a live target right now.
What the Vulnerability Does
The flaw lives in the commits API endpoint at /api/v4/projects/{id}/repository/commits/. An attacker sends a POST request with a crafted file.path parameter that escapes the repository directory — standard path traversal mechanics, except GitLab skipped both authentication enforcement and path confinement on this endpoint. The server returns whatever file the path points to. No token. No account. Nothing.
That combination — network-accessible, zero authentication, trivial to execute — is why this hits CVSS 10.0. A PoC exploit was published publicly on Sploitus the same day watchTowr confirmed active scanning. The window between “patch released” and “attacker toolkits updated” was under 24 hours.
What an Attacker Can Read
GitLab servers make rich targets precisely because of what they store. Files an attacker could extract from a vulnerable instance include:
gitlab-secrets.json— GitLab’s master key file for encrypted data/etc/gitlab/gitlab.rb— full server configuration including third-party API keysdatabase.yml— database connection strings and passwords- SSH private keys
- AWS, GCP, and Azure credentials stored in config or environment files
- CI/CD pipeline secrets written to disk
If your GitLab server has stored application tokens or Vault credentials anywhere on the filesystem, those are also in scope. Read access to gitlab-secrets.json alone is effectively full compromise — it contains the keys used to decrypt everything else.
Affected Versions
GitLab.com is already patched and not at risk. Self-managed instances running any of these are vulnerable:
- GitLab CE/EE 18.7 through 19.1.7
- GitLab CE/EE 19.2.0 through 19.2.5
- GitLab CE/EE 19.3.0 through 19.3.1
The patched versions are 19.3.2, 19.2.6, and 19.1.8. Upgrade to whichever matches your current minor version line. This is a second critical CVE for self-managed GitLab in six weeks — CVE-2026-19478 (CVSS 9.4) hit in August and also saw exploitation within days of disclosure. At this point, delaying self-managed GitLab upgrades is a liability, not a maintenance preference.
How to Patch
Run the upgrade command for your deployment type. Refer to the official GitLab patch release notes for full details.
Omnibus on Debian/Ubuntu:
sudo apt-get update && sudo apt-get install gitlab-ee
# Community Edition: replace gitlab-ee with gitlab-ceOmnibus on RHEL/CentOS:
sudo yum update gitlab-eeDocker:
# Update your image tag in docker-compose.yml to 19.3.2-ee.0
docker compose pull && docker compose up -dVerify your current version before upgrading:
cat /opt/gitlab/version-manifest.txt | head -1If you’re multiple versions behind, use the GitLab upgrade path tool to determine intermediate steps before jumping to 19.3.2.
If You Can’t Patch Right Now
There is no vendor-approved workaround that substitutes for patching. That said, if you need a few hours while coordinating a maintenance window:
- Block or rate-limit external access to
/api/v4/projects/*/repository/commits/at your WAF or load balancer - Enable two-factor authentication across your instance
- Disable SAML two-factor bypass in GitLab admin settings
These reduce the attack surface but do not close the vulnerability. Patch as soon as possible.
After Patching: Rotate Your Secrets
Patching stops new exploitation but doesn’t undo access that already happened. Review your access logs for unusual hits to the commits API before September 10. If you see anything suspicious — or can’t rule out prior exposure — rotate:
- All credentials referenced in
gitlab-secrets.json - SSH keys on the server and in CI/CD pipelines
- Cloud provider access keys
- Any application tokens or integration secrets stored in GitLab config
CISA’s Binding Operational Directive 26-04 explicitly flags this vulnerability for forensic triage because exploitation may have occurred before public disclosure. BleepingComputer notes that active in-the-wild probes began at 06:00 UTC on September 11 — meaning any internet-exposed instance was under active attack within hours of the patch release. If your instance was internet-facing before September 10, treat it as potentially compromised until confirmed otherwise.
