PoC Exploit Published for Patched GitLab RCE Flaw in Self-Managed 18.11.3 Instances

What Happened

Researchers at depthfirst publicly released working exploit code on July 24, 2026 for a GitLab vulnerability that GitLab had already patched six weeks earlier, on June 10. According to the report, the flaw affects self-managed GitLab servers still running version 18.11.3 that have not applied the fix, and allows commands to be executed with the privileges of the git user.

The reported exploitation path requires an authenticated user who has push access to a project. That user commits a specially crafted Jupyter notebook and then opens the commit's diff view, which reportedly leaks a heap-related artifact that leads to remote code execution. The source article's description of the technical mechanism cuts off partway through, so the full exploitation chain is not completely detailed here.

Why It Matters

This is a post-authentication vulnerability, not a pre-auth remote exploit, which somewhat limits the blast radius — but any user with commit/push access to a project (including lower-privileged contributors) may be able to leverage it to run commands as git on the underlying server. For organizations running self-managed GitLab, that can translate into source code exposure, CI/CD pipeline tampering, secrets theft, or a foothold for further lateral movement, depending on how the GitLab host is deployed and what it can reach. Because a fix has been available since June 10 and public exploit code now exists, unpatched instances face materially higher risk of opportunistic exploitation.

What Defenders Should Do Now

• Identify all self-managed GitLab instances and confirm whether any are still running 18.11.3 or another affected pre-patch version; prioritize patching to the fixed release immediately.
• Review who holds push/commit access to repositories — treat this as a reminder to audit and tighten project-level permissions, especially for external contributors or lower-trust accounts.
• Hunt for suspicious commits containing Jupyter notebook (.ipynb) files from unexpected users, particularly ones followed shortly by access to commit diff/comparison views.
• Monitor GitLab server logs and process activity for unexpected commands or child processes spawned under the git service account.
• If patching cannot happen immediately, consider restricting notebook file uploads/commits or limiting diff-rendering features as a temporary compensating control, and increase logging/alerting around the GitLab host in the interim.

Developing Story

This item is based on a single news report and details of the exact vulnerability (such as a CVE identifier) were not provided in the source material available at publication time. Treat specifics as preliminary and consult GitLab's official advisories for authoritative guidance. Original reporting: The Hacker News.