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

> Explore the Exploitarium repository structure for each vulnerability. Learn about its PoC architecture, featuring self-contained sub-directories, READMEs, and minimal PoC code for easy reproduction.

- Repository: [bikini/exploitarium](https://github.com/bikini/exploitarium)
- Tags: architecture
- Published: 2026-09-06

---

**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`](https://github.com/bikini/exploitarium/blob/main/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`](https://github.com/bikini/exploitarium/blob/main/README.md) |
| **PoC Code** | Minimal reproducible exploit or crash trigger | [`poc.py`](https://github.com/bikini/exploitarium/blob/main/poc.py), [`poc.c`](https://github.com/bikini/exploitarium/blob/main/poc.c), [`poc.js`](https://github.com/bikini/exploitarium/blob/main/poc.js), [`run_demo.py`](https://github.com/bikini/exploitarium/blob/main/run_demo.py) |
| **Execution Wrapper** | Shell script or Python driver to automate setup | [`run.sh`](https://github.com/bikini/exploitarium/blob/main/run.sh), [`run_demo.py`](https://github.com/bikini/exploitarium/blob/main/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/`

```bash
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`](https://github.com/bikini/exploitarium/blob/main/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/`

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

```

The [`run.sh`](https://github.com/bikini/exploitarium/blob/main/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/`

```bash
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`](https://github.com/bikini/exploitarium/blob/main/run_demo.py) | Orchestrates local SMTP server and curl execution |
| OpenSSH agent lock bypass | [`poc.py`](https://github.com/bikini/exploitarium/blob/main/poc.py) | Implements `control lock`, `probe` subcommands |
| VLC VP9 crash | [`poc.py`](https://github.com/bikini/exploitarium/blob/main/poc.py) | Generates malformed IVF samples |
| Redis VSET RCE | [`poc.py`](https://github.com/bikini/exploitarium/blob/main/poc.py) | Exploits duplicate HNSW ID vulnerability |
| QEMU CXL escape | [`run.sh`](https://github.com/bikini/exploitarium/blob/main/run.sh) | Builds and launches vulnerable QEMU instance |
| Discord activity RCE | [`server.js`](https://github.com/bikini/exploitarium/blob/main/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`](https://github.com/bikini/exploitarium/blob/main/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`](https://github.com/bikini/exploitarium/blob/main/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.