gitlab-cve-2026-85706-ioc

CVE-2026-85706 — GitLab Path Traversal IOC Scanner & Detection Toolkit. Detect and hunt for exploitation of the critical unauthenticated GitLab CE/EE path traversal vulnerability with IOC scanning, Sigma, Suricata/Snort, and SIEM detection rules.

🔎 Looking for the fastest path to "am I affected?" Jump to Quick Start.

🚨 Looking for what to patch to? Jump to Fixed Versions & Patch.

Table of Contents

• Vulnerability Summary
• Why This Matters
• Fixed Versions & Patch
• Related Vulnerabilities Fixed in the Same Release
• Repository Contents
• Quick Start
  • 1. Scan your GitLab logs for IOCs
  • 2. Check if your GitLab version is patched
  • 3. Deploy detection rules to your SIEM / IDS
• How the Scanner Works
• Sample Output
• Indicators of Compromise (IOC) Summary
• Detection Content
• Remediation
• Frequently Asked Questions
• Limitations & Disclaimer
• Contributing
• Sources & Further Reading
• License

Vulnerability Summary

An unauthenticated attacker can send a single crafted HTTP request to GitLab's repository commits API, supplying a file.path (or file_path) parameter containing directory-traversal sequences (../, URL-encoded variants, etc.), and have the server return the contents of arbitrary files outside the intended repository directory — including GitLab's own secrets file, database configuration, SSH private keys, and other sensitive server-side data. Because no credentials are required and the request is trivial to construct, GitLab and third-party researchers rate this as maximum severity (CVSS 10.0) and CISA has confirmed active exploitation in the wild.

Why This Matters

• GitLab is used by tens of millions of developers and well over 100,000 organizations to store private source code, CI/CD secrets, and infrastructure credentials.
• A successful exploit can lead directly to source code theft, secrets exposure, and supply-chain compromise — an attacker who reads gitlab-secrets.json, database.yml, or CI/CD runner tokens can pivot into far deeper access than the initial file-read alone suggests.
• The vulnerability requires zero authentication and one HTTP request — there is effectively no barrier to mass scanning, and scanning activity was observed within a day of public disclosure.
• It is now on the CISA KEV catalog, meaning US federal agencies are required to remediate on an accelerated timeline — a strong signal that every organization running self-managed GitLab should treat this with the same urgency, regardless of sector.

Fixed Versions & Patch

GitLab fixed CVE-2026-85706 in the following releases on 2026-09-10:

• 19.3.2
• 19.2.6
• 19.1.8

Any self-managed GitLab CE/EE instance on an earlier patch level within these branches — or on an older major/minor branch entirely — should be considered vulnerable and upgraded immediately. GitLab.com's SaaS offering is patched by GitLab directly and does not require customer action. See docs/remediation.md for a full step-by-step upgrade and incident-response guide.

Upgrade note: on single-node GitLab instances, upgrading to these versions involves downtime while database migrations complete before GitLab restarts. Multi-node instances can apply the patch without downtime by following GitLab's documented zero-downtime upgrade procedure. Version 19.3.2 also ships post-deploy migrations that run after the upgrade completes — factor this into your maintenance window.

Related Vulnerabilities Fixed in the Same Release

CVE-2026-85706 was the headline issue in a critical GitLab security release covering 17 vulnerabilities in total. Two other issues in the same release are worth tracking alongside it, since they affect similar attack surface and credential/secret exposure risk:

Practical takeaway: if you are patching for CVE-2026-85706, you are already pulling in fixes for all of the above in the same 19.3.2 / 19.2.6 / 19.1.8 release — there is no reason to patch for CVE-2026-85706 alone and defer the rest. Treat this as one release to apply in full, not a menu of independently-schedulable fixes.

Repository Contents

🚀 Quick Start

1. Scan your GitLab logs for IOCs

The scanner is pure Python 3 standard library — no pip install required, so you can copy just the one file onto a locked-down GitLab host and run it immediately.

Exit code 1 means at least one potential IOC was found — review report.json immediately. Exit code 0 means no matches were found in the logs you provided (see Limitations — this is not a compromise guarantee).

You can also point it at any arbitrary/rotated log with --generic-log (repeatable flag), and choose --format text|json|csv for the report.

2. Check if your GitLab version is patched

3. Deploy detection rules to your SIEM / IDS

• Import detection/sigma_rule_gitlab_cve_2026_85706.yml into your Sigma-compatible pipeline (Splunk via sigma-cli, Elastic Detection Rules, Microsoft Sentinel, Chronicle, etc.).
• Deploy detection/network_ids_cve_2026_85706.rules to Suricata or Snort — start in alert-only mode and tune SIDs/thresholds to your environment before enabling blocking.
• Copy/paste ready-made queries from detection/siem_hunting_queries.md for Splunk (SPL), Elastic/Kibana (KQL + DSL), OpenSearch (PPL), and plain ripgrep/grep triage.

How the Scanner Works

gitlab_cve_2026_85706_ioc_scanner.py parses GitLab's structured JSON logs (production_json.log, api_json.log) as well as generic combined-format reverse-proxy access logs, and flags requests that match the publicly documented exploitation pattern for CVE-2026-85706:

1. Endpoint match — request path hits the vulnerable endpoint family: /api/v4/projects/:id/repository/commits and sub-resources.
2. Parameter match — a file.path / file_path / path style parameter is present in the query string, form body, or JSON body.
3. Payload match — that parameter's value contains a path-traversal sequence (../, URL-encoded, double-encoded, overlong-UTF-8, and semicolon path-segment variants) or references a known sensitive target file (/etc/passwd, gitlab-secrets.json, secrets.yml, database.yml, SSH private keys, etc.).
4. Authentication context — the scanner checks for PRIVATE-TOKEN, Authorization, or a non-null user_id field to determine whether the request was authenticated, matching the unauthenticated / pre-auth exploitation condition central to this CVE.
5. Rate heuristic — independent of payload matching, source IPs making an unusually high volume of requests to the commits API in a short window are flagged as likely scripted reconnaissance.

Findings are scored CRITICAL / HIGH / MEDIUM and exported as structured JSON, CSV, or human-readable text for triage.

Sample Output

(Generated from the sanitized sample fixture in tests/fixtures/.)

Indicators of Compromise (IOC) Summary

Full detail, including host-based and post-exploitation indicators, is in docs/ioc_list.md. Headline network indicators:

• Requests to /api/v4/projects/<id>/repository/commits*
• A file.path / file_path parameter containing ../, %2e%2e%2f, ..%2f, %252e%252e%252f, or similar traversal sequences
• References to /etc/passwd, /etc/shadow, gitlab-secrets.json, secrets.yml, database.yml, id_rsa, .env, or /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml
• The above without a valid PRIVATE-TOKEN / Authorization header or authenticated session
• Abnormally high request volume against the commits API from a single source IP in a short time window

Detection Content

Remediation

See the full playbook in docs/remediation.md. Summary:

1. Patch to GitLab 19.3.2 / 19.2.6 / 19.1.8 or later immediately.
2. If you can't patch immediately, remove public internet exposure (VPN-only access) as a stopgap — there is no complete workaround.
3. Assume compromise on any internet-facing vulnerable instance since disclosure (2026-09-10) and rotate secrets: GitLab secrets file, database credentials, SSH keys, personal access tokens, CI/CD variables, and runner registration tokens.
4. Hunt your logs with this repository's tooling before and after patching.
5. Investigate any flagged findings and engage incident response if exploitation is confirmed.

Frequently Asked Questions

Is GitLab.com (SaaS) affected? No customer action is required for GitLab.com — GitLab patches its SaaS platform directly. This tooling is for self-managed GitLab CE/EE instances.

Do I need authentication to be exploited? No — that's what makes this CVE CVSS 10.0. It's an unauthenticated path traversal against a single API endpoint.

Is there a public exploit / PoC available? As of this writing, no confirmed public proof-of-concept has been identified, though active scanning/probing has been observed. This repository does not contain or link to exploit code — see CONTRIBUTING.md for why, and always check the official GitLab CVE-2026-85706 advisory for the latest vendor guidance.

Will the scanner tell me for certain whether I was compromised? No tool can guarantee that. It performs best-effort detection based on the logs you provide. See Limitations & Disclaimer.

What log retention do I need? GitLab's default log rotation may not retain logs back to the disclosure date (2026-09-10). Pull from your centralized SIEM/log archive if your on-host logs have already rotated — see the note in detection/siem_hunting_queries.md.

Does this repository work for GitLab Helm/Kubernetes or Docker deployments? Yes, as long as you can export production_json.log / api_json.log (or your ingress/reverse-proxy access logs) to a file the scanner can read; use --generic-log for anything outside the three named log types.

Exactly which versions are affected? GitLab CE/EE 18.7 up to (not including) 19.1.8, 19.2 up to (not including) 19.2.6, and 19.3 up to (not including) 19.3.2. Anything older than the 18.7 branch is also unsupported/end-of-life and should be treated as vulnerable and upgraded regardless.

Was this actually exploited, or just "at risk"? Confirmed exploited. watchTowr Labs observed the first in-the-wild exploitation attempts about 24 hours after GitLab's public disclosure, and CISA subsequently added CVE-2026-85706 to its KEV catalog specifically because it confirmed real-world exploitation — this is not a theoretical or "responsible disclosure only" finding.

What does the CISA BOD 26-04 "forensic triage" designation mean for me? CISA flagged this CVE as requiring forensic triage under Binding Operational Directive 26-04, meaning the assumption for federal systems is that a vulnerable, internet-facing instance may already have been accessed before it was patched — not just theoretically exposed. The same assumption is a reasonable default for any organization: treat patching as step one of an incident response process, not the end of one. See docs/remediation.md for the full assume-breach checklist (secret rotation, credential review, CI/CD audit).

Was anything else fixed in the same GitLab release? Yes — the September 10, 2026 release fixed 17 security issues in total, including a second Critical-severity issue (insecure deserialization in the GraphQL subscription serializer, GitLab EE) and a High-severity buffer overflow in a Unicode conversion wrapper. See Related Vulnerabilities Fixed in the Same Release. Since all of these ship in the same 19.3.2 / 19.2.6 / 19.1.8 versions, patching for CVE-2026-85706 already remediates them too.

Limitations & Disclaimer

• This tool performs best-effort detection only. Absence of findings does not prove a system was not compromised — logs may have rotated, been tampered with by an attacker, or the relevant fields may not be enabled in your logging configuration.
• Presence of findings does not by itself prove successful exploitation — always manually validate matches against your own network context (known scanners, legitimate automation) before declaring an incident. See the false-positive notes in docs/ioc_list.md.
• This project is not affiliated with or endorsed by GitLab Inc. For authoritative vendor guidance, always consult GitLab's official security release notes and advisories.
• This repository contains no exploit or proof-of-concept code. It is strictly a defensive detection and remediation toolkit — see CONTRIBUTING.md for the project's scope policy.

Contributing

Contributions of new IOCs, detection-rule ports, false-positive reports, and scanner improvements are welcome — see CONTRIBUTING.md for guidelines (including the no-exploit-code policy and data-sanitization requirements).

Sources & Further Reading

• GitLab, Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 (2026-09-10) — official vendor advisory, full table of the 17 security fixes, and upgrade/downtime notes
• watchTowr Labs, Rapid Reaction: GitLab Path Traversal Vulnerability (CVE-2026-85706) (2026-09-11) — first report of in-the-wild probing, roughly 24 hours after disclosure
• SecurityWeek, GitLab Vulnerability Exploited One Day After Disclosure (2026-09-11) — precise affected version ranges (18.7–19.1.8, 19.2–19.2.6, 19.3–19.3.2) and confirmation of active exploitation
• BleepingComputer, GitLab urges users to patch max severity path traversal flaw (2026-09-11) — researcher credit (HackerOne handle "s3ntago") and disclosure context
• CISA Known Exploited Vulnerabilities (KEV) Catalog — CVE-2026-85706 entry, added 2026-09-11, remediation due 2026-09-14
• CISA / GBHackers, CISA Warns of Critical GitLab Vulnerability Exploited in Attacks (2026-09-11/12) — CWE-35 classification and Binding Operational Directive 26-04 forensic-triage guidance
• Horizon3.ai Attack Research — CVE-2026-85706 technical write-up
• Field Effect, GitLab fixes critical vulnerability as internet-wide probing begins — mitigation and inventory guidance
• Independent researcher reporting (dev.to) on observed active scanning activity and attack-flow analysis (2026-09-11/12)

Full citation details and additional context are in docs/timeline.md.

License

Released under the MIT License. Detection content (Sigma, Suricata/Snort rules, SIEM queries) is provided as-is for defensive use; tune thresholds and false-positive handling to your own environment before relying on it operationally.

Keywords

CVE-2026-85706 GitLab CVE-2026-85706 GitLab path traversal GitLab vulnerability GitLab IOC GitLab indicators of compromise GitLab security advisory GitLab exploit detection GitLab CVSS 10.0 GitLab CISA KEV GitLab repository commits API vulnerability GitLab unauthenticated file read GitLab arbitrary file read path traversal CVE 2026 GitLab patch 19.3.2 GitLab patch 19.2.6 GitLab patch 19.1.8 GitLab secrets exposure GitLab CI/CD credential theft Sigma rule GitLab Suricata rule GitLab Snort rule GitLab Splunk GitLab hunting GitLab incident response GitLab threat hunting self-managed GitLab security