GitLab Flaw Lets Any Logged-In User Run Commands on Self-Hosted Servers
Researcher Yuhang Wu 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: commit two specially crafted Jupyter notebook files, then ask GitLab to show the difference between them.
- No admin rights, no CI runner access, no victim clicks required.
- Organisations running their own GitLab servers should patch immediately; GitLab.com is managed by the vendor.
Working attack code is now public that turns any authenticated user of a self-hosted GitLab server into a system operator. Yuhang Wu at depthfirst published the exploit against version 18.11.3, needing nothing beyond a normal account.
GitLab is software companies run in-house to store source code and coordinate developers: a private GitHub, sitting on a server the company owns.
Two carefully built Jupyter notebooks (interactive documents mixing code and notes, widely used by data scientists) get committed to a project. The attacker then requests a diff, the visual comparison of what changed between the two files. That single request fires the exploit. No one else needs to click anything.
The payload lands as the git user, the system account GitLab uses to manage repositories. That account can read every project on the server and rewrite code. One low-privilege employee, or anyone holding a stolen set of login credentials, owns the box. We've covered this pattern before: a weaponised SVG file gave researchers command execution on Bing's own servers on 24 July, and the mechanics here are uncomfortably similar.
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 is patched by the vendor; customer action isn't needed there. If your company runs GitLab on its own hardware or in its own cloud account, this is yours to fix.
Smaller shops that set up GitLab once and stopped updating it are the most exposed. The exploit needs an authenticated account, but on many internal instances registration is open to staff or anyone with a company email.
How bad is it in practice?
Bad. Remote code execution as a service account, triggered by a normal user with no interaction from anyone else, is close to the worst outcome a source-code platform can produce. An attacker who lands here can steal every line of proprietary code, plant back doors in software the company ships to customers, and pivot deeper into the network.
Because the trigger is a diff view, something reviewers open constantly, the attacker doesn't need to engineer anyone. They commit, they request the diff themselves, they're in.
| 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, today. Check the official GitLab security releases page for the exact fixed build.
While patching, restrict who can register on internal instances and audit recent commits for suspicious .ipynb files added by low-activity accounts. Repository logs show the commit; web access logs show the diff request.
Working exploit code is public. Scanning will accelerate fast.
