A working exploit for a GitLab remote code execution flaw patched in June is now public
Every unpatched self-managed GitLab $GTLB server running 18.11.3 is now one authenticated push away from full remote code execution. Researchers published a working exploit on July 24 for a flaw the company quietly patched six weeks earlier, on June 10, with no CVE ever assigned.
Every self-managed GitLab installation still running version 18.11.3 is now exposed to a public, working remote code execution exploit. Security researchers at depthfirst published proof-of-concept code on July 24 for a vulnerability GitLab $GTLB had quietly patched six weeks earlier, on June 10, across the 19.0.2, 18.11.5 and 18.10.8 releases. The exploit chains two long-standing memory-safety flaws in Oj, a Ruby JSON parsing library: an attacker commits a crafted Jupyter notebook, opens its commit diff to leak a heap pointer, repeats the process to locate key libraries in memory, then fires the payload using two more notebooks. Any authenticated user who can push to a project can execute it, gaining access to source code, Rails secrets and internal services, according to The Hacker News. GitLab never filed the fix as a security advisory, and no CVE or CVSS score was ever assigned to the underlying flaw. That matters beyond GitLab's own users: organizations that prioritize patching by CVE severity, a standard practice across the industry, would have had no signal that this particular June update was urgent.