GitLab Flaw Lets Any Logged-In User Run Commands on Self-Hosted Servers
A researcher published working exploit code against GitLab 18.11.3 that hijacks the server through two booby-trapped notebooks and a diff request.
Key points
- Security researcher Yuhang Wu of depthfirst published a working proof-of-concept exploit against self-managed GitLab 18.11.3 servers.
- The attack lets any ordinary logged-in user run commands on the server as the
gitsystem account. - The trigger is simple: commit two specially crafted Jupyter notebook files, then ask GitLab to show the difference between them.
- No admin rights, no continuous integration runner access, and no victim clicks are required.
- Organisations running their own GitLab servers should patch immediately; GitLab.com's hosted service is managed by GitLab itself.
A researcher has released working attack code that turns any logged-in user of a self-hosted GitLab server into a full system operator. The exploit, published by Yuhang Wu at depthfirst, targets version 18.11.3 of the software and needs nothing more than a normal account.
GitLab, for readers who have not met it, is a website companies run in-house to store their source code and coordinate their developers. Think of it as a private version of GitHub, sitting on a server the company owns.
The attack works like this. The user commits two carefully built Jupyter notebooks (notebooks are interactive documents that mix code and notes, widely used by data scientists) into a project. Then they ask GitLab to show the diff between the two files, meaning the visual comparison of what changed. That diff request is what fires the exploit.
The payload runs as the git user, the system account GitLab uses to manage repositories. That account can read every project on the server, rewrite code, and reach anything else the process can touch. In practical terms, one low-privilege employee, or anyone who has stolen one set of login details, owns the box.
The write-up was first reported by The Hacker News.
Who is affected?
Only organisations running their own GitLab servers on version 18.11.3, or earlier unpatched builds, are exposed. GitLab.com, the hosted service GitLab operates itself, is patched by the vendor and is not in scope for customer action here. If your company runs GitLab on its own hardware or in its own cloud account, this is your problem to fix.
Smaller shops that set up GitLab once and forgot about it are the most exposed. The exploit needs an authenticated account, but on many internal instances registration is open to staff, contractors, or anyone with a company email.
How bad is it in practice?
Bad. Remote code execution as the git service account, triggered by a normal user with no interaction from anyone else, is close to the worst outcome a source-code platform can hand out. An attacker who lands here can steal every line of proprietary code, plant back doors in software the company ships to its own customers, and pivot deeper into the network.
Because the trigger is a diff view (something reviewers click on constantly) an attacker does not even need to socially engineer anyone. They commit, they request the diff themselves, they win.
| Item | Detail |
|---|---|
| Affected product | GitLab self-managed |
| Confirmed vulnerable version | 18.11.3 |
| Attacker requirement | Authenticated user account |
| Result | Command execution as git |
| PoC status | Public, working |
What should administrators do now?
Upgrade to the latest GitLab release on the patch track for your major version, and do it today. Check the official GitLab security releases page for the exact fixed build that applies to your deployment.
While you are patching, two sensible short-term steps: restrict who can sign up for accounts on internal instances, and audit recent commits for suspicious .ipynb files added by low-activity users. Repository logs will show the commit; the diff request will show in web access logs.
Expect scanning to pick up quickly now that working code is public.
