<- ALL CYBER NEWS
High
GitLab, RCE, PoC, self-managed, silent patch, application security, DevSecOps
GitLab 18.11.3 RCE PoC Runs Commands as git, No CVE
A public PoC gives authenticated users RCE as git on self-managed GitLab 18.11.3. GitLab patched it June 10 but not as a security fix - many stay exposed.
A working public exploit gives any authenticated user with push access remote code execution as the git user on self-managed GitLab 18.11.3. GitLab shipped the fix on June 10 but did not file it as a security fix, so many admins never prioritised it. The PoC went public on July 24 - the grace period is over.
What happened. Researchers at depthfirst published working exploit code on July 24 for a GitLab flaw GitLab had quietly patched six weeks earlier, on June 10. It runs commands as git on any self-managed 18.11.3 server that has not taken the update. Any authenticated user who can push to a project can trigger it - the attacker commits a crafted Jupyter notebook and opens its commit diff, which leaks a heap pointer; enough of those let an automated probe locate libraries in memory, and two more notebooks fire the payload. No admin rights, no CI or runner access, and no victim interaction are required.
Who is affected by the GitLab RCE?
Detail | Value |
|---|---|
Affected | Self-managed GitLab 18.11.3 (not updated since June 10) |
Access required | Any authenticated user with push access |
Runs as | git |
CVE | None filed - shipped as a routine bug fix |
Public PoC | Yes, since July 24 |
Who is affected. Self-managed GitLab instances on 18.11.3 that skipped the June update. GitLab.com (SaaS) is not the concern here; this is the on-prem estate, where patch discipline is uneven and internal-only servers are wrongly assumed safe.
Why did so many miss the GitLab patch?
Because GitLab did not flag it as a security fix - it went out under routine bug updates. That is the crux of the community reaction: with no security advisory, most teams never prioritised it, and now a public PoC has closed the gap for them.
What should you do now?
Update self-managed GitLab immediately - the fix already exists. Then audit who has push access to projects, because "authenticated push user" is a far larger set than most admins assume. Review logs for anomalous commit-diff activity and unexpected processes running as git.
Our read. "Not filed as a security fix" is not the same as "not exploitable" - it just means nobody raised the alarm for you. Relying on vendor severity labels to drive your patch order is how a six-week-old, quietly-fixed bug becomes a same-day emergency the moment a PoC drops. The defensible posture is to verify your own exposure continuously, rather than waiting to be told which of your assets are dangerous.
Reporting by The Hacker News; PoC attributed to depthfirst. Source linked above.
Related: agent data injection hijacks AI agents and our KEV pentest analysis.