GitLab RCE PoC Published — Patch Self-Managed Instances Now

A working proof-of-concept exploit for a remote code execution vulnerability in self-managed GitLab has been published, putting every unpatched instance on the internet at immediate risk.

What Happened

Security researcher Yuhang Wu of depthfirst published a functional PoC that executes arbitrary commands as the git user on unpatched GitLab 18.11.3 instances. The attack vector is deceptively simple: an ordinary authenticated user — no admin privileges required — commits two specially crafted Jupyter notebooks and triggers the exploit through a standard repository action. Server-side processing of those notebooks executes attacker-controlled commands under the git OS account.

The git user on a self-managed GitLab server has broad access to repository data, hooks, and in many configurations SSH key management. On instances where git shares file access with other services or carries elevated OS-level permissions, the blast radius extends further — potentially covering every repository and secret on that host.

Why It Matters

A published, working PoC collapses the exploitation timeline from "nation-state actors only" to "anyone with a GitLab account and a search engine." Self-managed GitLab instances are common in enterprises and development teams precisely because they hold the most sensitive assets: source code, CI/CD pipeline secrets, deploy keys, API tokens, and internal tooling.

Unlike GitLab.com, which is patched by GitLab's own infrastructure team, self-managed instances require the operator to apply updates. Many organizations run months behind on patch cycles because upgrades require coordination with development teams. That lag is now a live liability.

The authenticated-only requirement does limit opportunistic mass scanning — an attacker needs a valid account on your instance. But on organizations that allow open registration, permit guest access, or have had credentials exposed in prior breaches, that bar is trivially low. Insider threat is an equally valid vector.

What To Do

1. Identify your GitLab version immediately. Navigate to Admin Area → Help or run gitlab-rake gitlab:env:info on the host. If you are on 18.11.3 or any earlier unpatched version, treat this as an emergency.

2. Apply the GitLab security patch. Check the GitLab security releases page for the fixed version and update using your standard gitlab-ctl or package manager workflow. Consult GitLab's upgrade path documentation if you are more than one minor version behind.

3. Audit recent Jupyter notebook commits. Until you can patch, review recent .ipynb file commits across repositories for unexpected contributors. Consider temporarily disabling Jupyter notebook processing in GitLab settings if the feature is not actively used.

4. Restrict registration and guest access. If your instance does not require controlled provisioning, enable Admin Area → Settings → Sign-up restrictions to require admin approval for new accounts.

5. Review git user OS permissions. If git has access to files outside /var/opt/gitlab, tighten those permissions now. RCE as git should not cascade into broader host compromise.

The window between PoC publication and active in-the-wild exploitation is measured in hours. Patch first, document later.