Analysis updated 2026-07-26
Study how a real GitLab vulnerability works in a safe, isolated environment.
Learn how memory corruption and ASLR bypass techniques function in practice.
Test whether a patched GitLab instance is immune to this specific attack.
Demonstrate a full attack chain from account creation to server access for training.
| wupco/gitlab-rce-demo | berliwu/world-cup-2026-match-prediction-engine | sunapp-ai/sun-to-spotify | |
|---|---|---|---|
| Stars | 37 | 37 | 37 |
| Language | Shell | Shell | Shell |
| Setup difficulty | hard | moderate | moderate |
| Complexity | 5/5 | 3/5 | 2/5 |
| Audience | researcher | developer | vibe coder |
Figures from each repo's GitHub metadata at analysis time.
Requires a specific Linux CPU architecture, Docker, and waiting several minutes for GitLab to fully boot before the exploit can run.
{"i":0,"repo":"wupco/gitlab-rce-demo","stars":37,"lang":"Shell","ok":true,"char_count":1310,"text":"This repository is a self-contained demonstration of a security vulnerability in GitLab, a popular web platform for hosting and managing code. The demo sets up a fresh, isolated copy of GitLab on your own machine, creates a regular user account through the normal public web interface, and then runs a proof of concept attack against that local instance. It is intended for security research and education, not for use against any real or production system.\n\nThe underlying vulnerability involves two bugs in a piece of software called Oj, which GitLab uses to read notebook files when showing differences between versions. By carefully crafting the contents of a repository, an attacker can corrupt the internal state of the parser and eventually force the GitLab server to connect back to a machine the attacker controls. The attacker can then run commands on the GitLab server as a specific system user. A key challenge the demo handles is finding the right memory layout, which varies each time the software starts, a common protection known as ASLR.\n\nRunning the demo requires a Linux computer with a specific processor type, along with Docker and several standard command line tools. The setup script removes any previous demo environment, starts a new GitLab instance, waits for it to fully boot, and creates a test user. A fresh GitLab boot can take several minutes to complete.\n\nAfter setup, the attack is split across two terminal windows. One terminal listens for an incoming connection, while the other runs the exploit script. When the connection succeeds, the listening terminal lets you type commands that run on the GitLab server. The time it takes to find the correct memory layout varies between runs. The repository includes an image showing a successful demo run, and links to a detailed technical writeup of the research behind it."}
A proof-of-concept demo that shows how a real vulnerability in GitLab lets an attacker run commands on the server. It sets up a local copy of GitLab and walks through the attack step by step.
Mainly Shell. The stack also includes Shell, Docker, GitLab.
No license information is provided, so default copyright restrictions apply and usage rights are unclear.
Setup difficulty is rated hard, with roughly 1h+ to a first successful run.
Mainly researcher.
This repo across BitVibe Labs
Verify against the repo before relying on details.