Exploit Released for Unpatched GitLab RCE via Jupyter Notebook Diffs

A publicly released proof-of-concept exploit has exposed a serious GitLab RCE vulnerability affecting self-managed instances running version 18.11.3. Security researcher Yuhang Wu at depthfirst published working code demonstrating how a standard authenticated user can achieve arbitrary command execution on the host system without requiring administrative rights or user interaction.

Technical Details

The exploit leverages GitLab’s built-in diff rendering engine for Jupyter notebooks (.ipynb files). To trigger the vulnerability, an attacker with basic commit access to any repository on the self-managed server commits two specifically crafted Jupyter notebook files and submits a request through the web interface to view the diff between them.

When GitLab processes the request, the application attempts to parse and render the structural differences between the two notebook files. Deficiencies in how the server handles input during this diff comparison process allow an attacker to break out of the rendering context and execute system commands. The injected commands run directly under the security context of the git system user, granting full access to repository data, internal configuration files, and local server resources.

The attack chain requires minimal prerequisites:

• No Admin Privileges: Standard, non-privileged user accounts capable of creating or pushing commits to a project can execute the attack.
• No CI/CD Access: The vulnerability exists entirely within the web application’s diff viewing pipeline, meaning access to CI/CD runners or build pipelines is unnecessary.
• No Social Engineering: The exploit runs headlessly upon processing the HTTP request for the file diff, requiring no interaction from victim users or administrators.

Impact on Self-Managed Environments

Because the command execution occurs as the git user, an attacker can read, modify, or delete any repository stored on the server. Furthermore, access to local configuration files (such as gitlab.rb or database credentials stored on the filesystem) can allow lateral movement to underlying databases, internal services, or connected continuous integration infrastructure.

Self-managed installations accessible from public networks or shared across large enterprise developer bases face immediate exposure, as any valid user credential—including compromised developer accounts—can be leveraged to compromise the entire hosting infrastructure.

Recommended Action Guidance

Because a public PoC is actively available, organization administrators operating self-managed GitLab instances should take immediate defensive steps:

• Audit Commit Activity: Inspect web server and application logs for unusual diff requests involving .ipynb files, particularly those originating from recently created accounts or unexpected repositories.
• Monitor Process Execution: Set up endpoint detection rules to alert on suspicious child processes spawned by the git system user or the web application worker processes (such as puma or sidekiq). Command shells (/bin/sh, /bin/bash) or network utilities (curl, wget, nc) executed under the git account should be flagged immediately.
• Apply Upstream Patches: Monitor official GitLab security release channels and apply vendor patches immediately as soon as an explicit hotfix or point release addressing this vulnerability is issued.