GitLab RCE Alert: Jupyter Notebook Diff Exploit (PoC Released)
Hey everyone,
Just saw that depthfirst has finally dropped the PoC for that GitLab RCE involving Jupyter notebooks. If you are running a self-managed instance—specifically version 18.11.3—and haven't patched since June 10, you need to prioritize this immediately.
The mechanics are pretty wild. An authenticated user just needs push access to a project. They commit a crafted Jupyter notebook, and when they open the commit diff, it triggers a heap leak that lets them execute commands as the git user. It is a textbook example of how complex file parsing features (like rich diff visualization) can turn into critical attack surfaces.
While the exploit drops you into a git shell, the risk of lateral movement is real. The git user often has significant read access to repositories and can sometimes interact with repository hooks that might trigger other processes. If you have developers pushing .ipynb files frequently, your blast radius is higher.
You can check your current version using the Omnibus utility:
sudo gitlab-rake gitlab:env:info | grep "Version:"
I am currently auditing our logs to see if any external collaborators pushed notebooks recently. You can scan your repo history for these extensions with:
find /var/opt/gitlab/git-data/repositories -name "*.git" -exec git --git-dir="{}" log --all --pretty=format: --name-only \; | sort -u | grep "\.ipynb$"
Has anyone looked into mitigating this via WAF rules, or is pushing the patch the only reliable fix? I'm considering blocking .ipynb uploads via Push Rules as a temporary stopgap.
Blocking the extension via Push Rules is a solid interim measure, but be careful of bypasses using obscure character encodings in the filename. We pushed the patch last night, and the regression testing was minimal. Given the git user context, the privilege escalation potential depends heavily on your underlying OS hardening. If your gitlab-rails console is accessible to that user, you are effectively owned.
We saw a similar spike in attempts on our honeypot immediately after the PoC dropped. The heap leak in the diff view is nasty because it looks like legitimate developer activity.
If you cannot patch immediately, I recommend restricting Developer role permissions or using a protected branch scheme that requires code owner approval for any file changes containing .ipynb. It adds friction, but it stops the auth+push requirement.
Great write-up. For detection, we are leveraging the GitLab audit logs. You can query for push events targeting files with that extension.
# Rails console snippet for checking recent pushes
PushEvent.where("created_at > ?", 6.weeks.ago).each do |event|
puts "#{event.author_name} pushed to #{event.project.name}"
end
This won't catch the exploit itself, but it helps identify the vector usage.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access