Exploit for CVE-2026

> **Exploit disclosure status:** GitLab has confirmed the vulnerability, but the precise trigger, affected implementation, and RCE chain are not publicly documented as of 13 October 2026. **This repository is not a working RCE PoC.** It uses a real, patched GitLab server and documented CI Lint API to study the legitimate CI/CD regex interface. It does not pretend normal lint requests exploit the vulnerability.

On **12 October 2026**, GitLab published fixes for **CVE-2026-97229**, an integer overflow / insufficient regex validation issue impacting GitLab CE/EE. GitLab says a specially crafted regular expression in a CI/CD configuration could, under certain conditions, allow **unauthenticated arbitrary code execution on the GitLab server**.

**Reported by:** [joaxcar]( credited by GitLab.

| GitLab CE/EE release | Affected versions | GitLab's current fix |

**Severity:** CVSS 3.1 **10.0** (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Self-managed operators should upgrade immediately. GitLab.com was already patched; GitLab Dedicated customers were told no action was required for this issue.

Source: [GitLab's official critical patch release](

| [compose.yaml](compose.yaml) | Starts official **gitlab/gitlab-ce:19.4.2-ce.0** on **127.0.0.1:8929** |

| [fixtures/legitimate-ci-regex.yml](fixtures/legitimate-ci-regex.yml) | Real GitLab `.gitlab-ci.yml` rules using regex operators |

| [tools/ci_lint.py](tools/ci_lint.py) | Posts that configuration to a local GitLab **project-scoped CI Lint API** |

| [tools/version_audit.py](tools/version_audit.py) | Offline version inventory matching the published affected ranges |

| [tools/instance_version.py](tools/instance_version.py) | Reads a running localhost GitLab server’s real version via its Metadata API |

| [docs/RESEARCH.md](docs/RESEARCH.md) | Public sources, known facts, unknowns, and source-review process |

| [docs/DEFENSIVE_GUIDE.md](docs/DEFENSIVE_GUIDE.md) | Patching, validation, and defensive triage |

| [tests/](tests/) | Automated tests for API request construction, parsing and version classification |

This replaces an earlier made-up 8-bit arithmetic simulator. **No synthetic "vulnerable compiler" is presented as evidence GitLab.**

You need a Linux Docker engine with sufficient RAM and disk for GitLab's official omnibus image. Docker Desktop on Windows may have unsupported volume-permission behaviors according to GitLab documentation; a Linux host or Linux VM is preferred.

Open ** Initial boot requires provisioning. To retrieve the locally generated root password, consult the container's `/etc/gitlab/initial_root_password` file. Set up a **private local project** and create a personal access token with the minimum access necessary for project CI linting.

**Never connect this research environment to the public internet.** Only port 8929 is published and it is bound to localhost. No external exploit endpoint is used.

### 2. Test actual GitLab regex validation

GitLab documents regex operators `=~` and `!~` in CI/CD rules, and the project-scoped CI Lint API at `POST /api/v4/projects/:id/ci/lint`.

Set `GITLAB_TOKEN` in your local shell (PowerShell: `$env:GITLAB_TOKEN = "YOUR_LOCAL_TOKEN"`); do not commit tokens. Supply the numeric ID of your local private project:

python -m tools.ci_lint --project-id 1 --config fixtures/legitimate-ci-regex.yml --output result.json

This uses the real GitLab application and returns its actual JSON lint response (normalized to validity, errors and warnings). It is a legitimate configuration check, **not evidence of exploiting this CVE**.

The first reports **affected** and exits 2; the second reports **fixed_for_this_cve**. Unlisted release lines are explicitly **outside_documented_ranges**, not automatically marked safe.

To inspect your **actual local GitLab installation** via GitLab’s documented metadata endpoint:

This uses your existing `GITLAB_TOKEN` and requests `GET This is local inventory, not an exploit test.

Unit tests run without Docker or network access. End-to-end CI lint needs a running local GitLab instance and its token. The optional, manually triggered GitHub Actions workflow only executes offline unit tests, so it cannot claim to verify real GitLab server behavior. Automatic runs are paused while repository Actions jobs are failing.

Local Docker runtime data are stored in `.gitlab-runtime/` and ignored by Git. `docker compose down` preserves these host directories.

- No verified vulnerable regex payload or RCE execution primitive

- No confirmed CVE-specific source file or exact patched hunk

- No bypass of authentication, and no claim that lint accepts unauthenticated malicious expressions

- No remote instance scanning, shell execution, or exploitation

GitLab documents that details of security issues are normally made public **90 days after the associated patch release**. Research should be updated with attributed code references when verified details emerge.

- [GitLab 19.4.2 critical patch advisory](

- [GitLab CI job rules: regular expressions](

- [GitLab CI Lint API](

- [GitLab Metadata API](

- [GitLab Docker installation](

- [CERT-EU advisory](

**Research integrity:** Attribute GitLab and joaxcar. Do not label this repository "working CVE-2026-97229 exploit" until an independently reproducible CVE-specific result exists. It is a practical technical investigation using real vendor software, not an attack tool.