How the Exploitarium Repository Is Structured for Each Vulnerability: A Complete Guide to Its PoC Architecture

Each vulnerability in Exploitarium lives in a self-contained sub-directory with a README, minimal PoC code, and auxiliary scripts, enabling standalone reproduction without cross-folder dependencies.

The bikini/exploitarium repository is a curated archive of independent proof-of-concept (PoC) projects. Understanding how this repository structures each vulnerability helps security researchers quickly locate, comprehend, and execute exploits. This guide breaks down the folder-level conventions, file patterns, and execution workflows found throughout the codebase.

---

Self-Contained Vulnerability Folders

Every vulnerability resides in its own top-level directory. This isolation-by-design ensures that researchers can work with a single PoC without downloading or configuring unrelated dependencies.

According to the repository's top-level README.md (lines 27-71), each entry is catalogued with:

• Directory name matching the vulnerability (e.g., curl-smtp-expn-recipient-crlf-injection/)
• Original source — either a commit hash for migrated repositories or "direct entry"
• File count — the number of tracked files in that PoC

---

Standard Files Found in Every Vulnerability Directory

While specific implementations vary, most folders contain a predictable set of files:

Component	Purpose	Typical Filename(s)
README	Background, technical explanation, and usage instructions	README.md
PoC Code	Minimal reproducible exploit or crash trigger	poc.py, poc.c, poc.js, run_demo.py
Execution Wrapper	Shell script or Python driver to automate setup	run.sh, run_demo.py
Supporting Data	Payloads, test vectors, or evidence logs	evidence/*, generated sample files
Version Control Exclusions	Keeps build artifacts and large binaries out of git	.gitignore

The README in each folder is the authoritative source for running that specific PoC. It specifies exact command lines, environment variables, and expected outputs.

---

Representative Vulnerability Structures

cURL SMTP EXPN CRLF Injection

Directory: curl-smtp-expn-recipient-crlf-injection/

cd curl-smtp-expn-recipient-crlf-injection
python run_demo.py                    # Uses system curl

python run_demo.py --curl /opt/curl/bin/curl   # Custom binary

The run_demo.py script spins up a local SMTP server, crafts a curl configuration that injects additional SMTP commands, and outputs a JSON-encoded evidence file. See the folder's README (lines 1-15) for the exact output format.

OpenSSH Forwarded-Agent Lock Bypass

Directory: openssh-agent-lock-provider-bypass/

cd openssh-agent-lock-provider-bypass
OPENSSH_PREFIX=/opt/openssh-10.4p1 bash run.sh

The run.sh wrapper builds a temporary OpenSSH environment, locks the agent via poc.py control lock, forwards the socket, unlocks the agent, then probes with poc.py probe. The README (lines 88-100) documents the successful replay confirmation.

VLC VP9 Resolution-Change Crash

Directory: vlc-vp9-reschange-crash-poc/

cd vlc-vp9-reschange-crash-poc
python poc.py                         # Generates IVF file

python poc.py --vlc "/c/Program Files/VideoLAN/VLC/vlc.exe"  # Replay against VLC

First invocation creates vp9_reschange_64x64_to_64x8192_tc0.ivf; the second replays it and reports process exit status. Usage details appear in README lines 49-67.

---

Repository Root Structure

/exploitarium
│   README.md                    ← Master index with vulnerability inventory
│   .gitignore
│   .gitattributes
│
├─ curl-smtp-expn-recipient-crlf-injection/
│   ├─ README.md
│   ├─ run_demo.py
│   └─ .gitignore
│
├─ openssh-agent-lock-provider-bypass/
│   ├─ README.md
│   ├─ poc.py
│   ├─ run.sh
│   └─ evidence/
│
├─ vlc-vp9-reschange-crash-poc/
│   ├─ README.md
│   ├─ poc.py
│   └─ .gitignore
│
├─ redis-vset-duplicate-hnsw-id-rce-poc/
│   ├─ README.md
│   └─ poc.py
│
├─ qemu-cxl-type3-mailbox-escape-poc/
│   ├─ README.md
│   └─ run.sh
│
├─ discord-activity-stock-client-rce-poc/
│   ├─ README.md
│   └─ server.js
│
⋮

Each <vuln-folder>/ operates as an independent unit. No cross-directory imports or shared build systems are required.

---

Why This Structure Improves Security Research

Isolation — Researchers fetch only the folder they need, eliminating dependency conflicts between PoCs targeting different software stacks.

Reproducibility — All artifacts required for demonstration (scripts, payloads, evidence logs) coexist in one location. A fresh checkout of any single folder should yield a working PoC.

Version Traceability — The top-level README preserves original commit hashes for migrated repositories. For example, 7zip-rar5-motw-chain-poc maps to commit bd9533f5…, ensuring the exact source version remains documented.

---

Key Source Files by Vulnerability Type

Vulnerability	Primary File	Function
cURL SMTP CRLF injection	run_demo.py	Orchestrates local SMTP server and curl execution
OpenSSH agent lock bypass	poc.py	Implements control lock, probe subcommands
VLC VP9 crash	poc.py	Generates malformed IVF samples
Redis VSET RCE	poc.py	Exploits duplicate HNSW ID vulnerability
QEMU CXL escape	run.sh	Builds and launches vulnerable QEMU instance
Discord activity RCE	server.js	Hosts malicious payload for Discord client

---

Summary

• Exploitarium uses per-vulnerability directories at the repository root, each acting as a standalone PoC project.
• Every folder contains a README.md with execution instructions, a minimal PoC script (Python, C, JavaScript, or shell), and supporting files as needed.
• The top-level README serves as a master index, tracking file counts and original source commits.
• No inter-folder dependencies exist; each PoC can be cloned and run independently.

---

Frequently Asked Questions

What file should I read first when exploring a new vulnerability?

Start with the README.md inside the vulnerability's folder. It contains the background explanation, exact commands to run, and expected outputs. The top-level README only provides the inventory and source attribution.

Can I run a PoC without cloning the entire repository?

Yes. Each vulnerability folder is self-contained. You can use GitHub's sparse-checkout feature, download a single directory as a ZIP, or copy just the files listed in that folder's entry. No build steps at the repository root are required.

How does Exploitarium track the original source of each PoC?

The top-level README.md documents either the original commit hash (for vulnerabilities migrated from standalone repositories) or marks them as "direct entry" (for contributions created directly in Exploitarium). This preserves version provenance for every entry.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}