Skip to content
Exploit for CVE-2026

Exploit for CVE-2026

Sploitus September 12, 2026

**GitLab CE/EE Repository Commits API Unauthenticated Path Traversal (CVSS 3.1: 10.0, Critical)**

**Status: Actively exploited in the wild · Listed in CISA KEV (2026-09-11, due 2026-09-14) · Patched by GitLab 2026-09-10**

[![CI](

[![License: MIT](

[![CVSS](

[![CISA KEV](

A free, open-source **incident response and threat hunting toolkit** for

**CVE-2026-85706** — a critical, unauthenticated path traversal

vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE)

affecting the **repository commits API**. This repository gives security

teams, SOC analysts, detection engineers, and GitLab administrators a

ready-to-run **IOC (Indicators of Compromise) scanner**, **Sigma / Suricata

/ Snort detection rules**, **Splunk / Elastic / OpenSearch hunting

queries**, and a **step-by-step remediation guide** — everything you need

to detect exploitation attempts, confirm patch status, and respond to this

GitLab zero-day / n-day vulnerability quickly.

> 🔎 **Looking for the fastest path to "am I affected?"** Jump to

> 🚨 **Looking for what to patch to?** Jump to

> [Fixed Versions & Patch](#fixed-versions--patch).

- [Vulnerability Summary](#vulnerability-summary)

- [Fixed Versions & Patch](#fixed-versions--patch)

- [Repository Contents](#repository-contents)

- [1. Scan your GitLab logs for IOCs](#1-scan-your-gitlab-logs-for-iocs)

- [2. Check if your GitLab version is patched](#2-check-if-your-gitlab-version-is-patched)

- [3. Deploy detection rules to your SIEM / IDS](#3-deploy-detection-rules-to-your-siem--ids)

- [How the Scanner Works](#how-the-scanner-works)

- [Indicators of Compromise (IOC) Summary](#indicators-of-compromise-ioc-summary)

- [Detection Content](#detection-content)

- [Frequently Asked Questions](#frequently-asked-questions)

- [Limitations & Disclaimer](#limitations--disclaimer)

- [Sources & Further Reading](#sources--further-reading)

| **Vendor / Product** | GitLab Community Edition (CE) & Enterprise Edition (EE), self-managed |

| **Vulnerability class** | Path Traversal / Improper Limitation of a Pathname (CWE-22) |

| **Affected component** | Repository Commits API (`/api/v4/projects/:id/repository/commits...`) |

| **Root cause** | Improper path confinement combined with missing authentication enforcement in the affected API endpoint |

| **Authentication required** | **None** — unauthenticated, pre-auth exploitation |

| **Attack vector** | Network, single HTTP request |

| **CVSS 3.1 score** | **10.0 (Critical)** |

| **Impact** | Arbitrary file read on the GitLab server — configuration files, secrets, source code, potentially SSH keys and database credentials |

| **Disclosed / Patched** | September 10, 2026 (GitLab security release) |

| **CISA KEV** | Added September 11, 2026; federal remediation due **September 14, 2026** |

| **Exploitation status** | **Confirmed active scanning / probing observed in the wild** within ~24 hours of disclosure |

| **Public PoC** | Not confirmed publicly available at time of writing |

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**.

- GitLab is used by tens of millions of developers and well over 100,000

organizations to store **private source code, CI/CD secrets, and

- 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

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

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`](docs/remediation.md) for a full

step-by-step upgrade and incident-response guide.

├── README.md ← you are here

├── LICENSE ← MIT

│ ├── gitlab_cve_2026_85706_ioc_scanner.py ← main IOC scanner (stdlib-only Python 3)

│ └── requirements.txt ← documents "no dependencies needed"

│ ├── sigma_rule_gitlab_cve_2026_85706.yml ← Sigma rule (SIEM-agnostic)

│ ├── network_ids_cve_2026_85706.rules ← Suricata/Snort signatures

│ └── siem_hunting_queries.md ← Splunk / Elastic / OpenSearch / grep queries

│ ├── ioc_list.md ← full IOC reference (network, host, post-exploitation)

│ ├── remediation.md ← patch & incident-response playbook

│ └── timeline.md ← public disclosure & exploitation timeline

│ ├── test_scanner.py ← unit tests (stdlib unittest)

│ └── fixtures/sample_production_json.log ← sanitized sample log for testing

└── .github/workflows/ci.yml ← GitHub Actions: lint, test, smoke-test on every push

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

git clone

python3 scanner/gitlab_cve_2026_85706_ioc_scanner.py \

--production-log /var/log/gitlab/gitlab-rails/production_json.log \

--api-log /var/log/gitlab/gitlab-rails/api_json.log \

--nginx-log /var/log/gitlab/nginx/gitlab_access.log \

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](#limitations--disclaimer) — this

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

python3 scanner/gitlab_cve_2026_85706_ioc_scanner.py --check-version 19.2.3

# → GitLab 19.2.3 is VULNERABLE to CVE-2026-85706. Upgrade to 19.2.6 or later immediately...

python3 scanner/gitlab_cve_2026_85706_ioc_scanner.py --check-version 19.2.6

# → GitLab 19.2.6 is PATCHED for CVE-2026-85706 (fixed in 19.2.6).

### 3. Deploy detection rules to your SIEM / IDS

- Import [`detection/sigma_rule_gitlab_cve_2026_85706.yml`](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`](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.

[`detection/siem_hunting_queries.md`](detection/siem_hunting_queries.md)

for Splunk (SPL), Elastic/Kibana (KQL + DSL), OpenSearch (PPL), and plain

`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`,

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.

CVE-2026-85706 IOC Scan Report — 2 finding(s)

============================================================

[CRITICAL] 2026-09-11T02:14:33.120Z src=203.0.113.9 method=POST auth=False

path: /api/v4/projects/42/repository/commits/HEAD

reason: path-traversal sequence in file path parameter; known sensitive/system file referenced; unauthenticated request (matches pre-auth exploitation condition)

[CRITICAL] 2026-09-11T02:16:45.501Z src=203.0.113.9 method=POST auth=False

path: /api/v4/projects/17/repository/commits/abc123

matched: ..%2f..%2f..%2fopt%2fgitlab%2fembedded%2fservice%2fgitlab-rails%2fconfig%2fsecrets.yml

reason: path-traversal sequence in file path parameter; unauthenticated request (matches pre-auth exploitation condition)

(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`](docs/ioc_list.md). Headline network indicators:

- Requests to `/api/v4/projects//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

- Abnormally high request volume against the commits API from a single

| [`detection/sigma_rule_gitlab_cve_2026_85706.yml`](detection/sigma_rule_gitlab_cve_2026_85706.yml) | Sigma (SIEM-agnostic) | Log-based detection rule convertible to Splunk, Elastic, Sentinel, Chronicle, QRadar, etc. |

| [`detection/network_ids_cve_2026_85706.rules`](detection/network_ids_cve_2026_85706.rules) | Suricata / Snort | Network-layer signatures for inline IDS/IPS sensors |

| [`detection/siem_hunting_queries.md`](detection/siem_hunting_queries.md) | Splunk, Elastic/Kibana, OpenSearch, grep/ripgrep | Copy-paste hunting queries for manual/ad-hoc investigation |

See the full playbook in [`docs/remediation.md`](docs/remediation.md).

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,

4. **Hunt your logs** with this repository's tooling before and after

5. **Investigate** any flagged findings and engage incident response if

No customer action is required for GitLab.com — GitLab patches its SaaS

platform directly. This tooling is for **self-managed** GitLab CE/EE

**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`](CONTRIBUTING.md) for why, and always check the

official [GitLab CVE-2026-85706 advisory](

**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](#limitations--disclaimer).

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`](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.

- 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

- 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`](docs/ioc_list.md#6-false-positive-considerations).

- This project is **not affiliated with or endorsed by GitLab Inc.** For

authoritative vendor guidance, always consult GitLab's official security

- This repository contains **no exploit or proof-of-concept code**. It is

strictly a defensive detection and remediation toolkit — see

[`CONTRIBUTING.md`](CONTRIBUTING.md) for the project's scope policy.

Contributions of new IOCs, detection-rule ports, false-positive reports,

and scanner improvements are welcome — see

[`CONTRIBUTING.md`](CONTRIBUTING.md) for guidelines (including the

no-exploit-code policy and data-sanitization requirements).

- GitLab, *Critical Security Release: GitLab 19.3.2, 19.2.6, 19.1.8*

(2026-09-10) — official vendor advisory and patch notes

- watchTowr Labs, *Rapid Reaction: GitLab Path Traversal Vulnerability

- CISA Known Exploited Vulnerabilities (KEV) Catalog — CVE-2026-85706

- Horizon3.ai Attack Research — CVE-2026-85706 technical write-up

- Independent researcher reporting on active scanning activity

Full citation details and additional context are in

Released under the [MIT License](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

`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

Extracted Entities

Attack Types (1)

CWE Weaknesses (1)

Domains (1)

IP Addresses (1)

Platforms (1)