A newly published proof of concept has raised the urgency of upgrading self-managed GitLab installations. The exploit chains two memory-corruption flaws in Oj, a native Ruby JSON parser, through GitLab's Jupyter notebook diff-rendering functionality. An authenticated user who can push content to a project may be able to execute commands as the git account without administrator privileges, CI runner access or interaction from another victim.
How the Attack Chain Works
The attacker commits specially constructed Jupyter notebook files and causes GitLab to render their differences. One parser flaw can disclose a memory address, helping the attacker locate important libraries despite memory-randomization defenses. A second flaw can corrupt memory and redirect execution toward a system command.
The public exploit was developed for a specific GitLab 18.11.3 environment on x86-64, so it is not a universal one-click tool. However, researchers said adapting it to nearby builds on the same architecture may require only limited changes. Successful commands run under the account used by GitLab's Puma application process, potentially placing source code, Rails secrets, service credentials and accessible internal systems at risk.
The Patch Was Easy to Miss
GitLab corrected the issue on June 10 through an update to the Oj dependency. The important complication is that the change appeared in release documentation as a bug fix rather than in the security-fix table. No CVE or CVSS score was assigned to the complete GitLab attack chain.
Affected version ranges include GitLab 15.2.0 through 18.10.7, 18.11.0 through 18.11.4 and 19.0.0 through 19.0.1. Administrators should upgrade to 18.10.8, 18.11.5, 19.0.2 or a later supported release. Installations on older, unsupported branches must move to a maintained version because they will not receive a backport.
Check the Running Image
Organizations using GitLab Helm charts or the GitLab Operator should inspect the GitLab version inside the Webservice container that runs Puma. Checking only the chart or Operator version may create a false sense of security.
In my view, this case exposes a serious weakness in vulnerability-management workflows. Many organizations prioritize updates by scanning security advisories for CVEs and severity ratings. When a dangerous correction is categorized as an ordinary bug fix, that process can fail even if administrators follow their documented procedures.
There is no confirmed evidence of exploitation in the wild, but public code changes the risk calculation. GitLab operators should upgrade promptly, review access granted to external contributors and monitor notebook-diff requests, application crashes and unexpected processes launched by the GitLab service account.