bikini/exploitarium: a consolidated archive of public exploit PoCs and writeups
A single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.
At a glance
- What is it?
- Exploitarium gathers one author's public proof-of-concept code and vulnerability writeups into a single folder-per-target repository. It is a research archive, not a scanner or a disclosure pipeline, and the README says it was already incomplete when published.
- Who is it for?
- Adopt it only if you want a reference corpus of public PoC folders with their original READMEs and tracked files, and you are prepared to read each entry's own notes before running anything. Do not use it as a detection tool, a patch-status source, or a substitute for vendor advisories: the README states none of the issues had been reported when the author published them, and the repo was incomplete at publication.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Exploitarium is, and who it is actually for
Exploitarium is described in its README as "a consolidated archive of my public proof-of-concept and vulnerability research writeups." The repository is a single Git tree whose top level is a list of target-named folders: 7zip-rar5-motw-chain-poc, curl-smtp-expn-recipient-crlf-injection, ffmpeg-rasc-dlta-calc-poc, qemu-cxl-type3-mailbox-escape-poc, redis-vset-duplicate-hnsw-id-rce-poc, and roughly thirty more. Each folder is meant to be self-contained, carrying its own README and tracked files.
The intended audience is narrow. The README states the author publishes these "so to allure people into the field," meaning people who want to learn how memory-safety and logic bugs are found and demonstrated. That is a different audience from a security team looking for something to run in CI. There is no scanner, no rule set, no service, and no library. The primary language is Python, which reflects the tooling around the PoCs rather than a single installable package.
The archive also carries a long disclosure caveat: "At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz." Read that literally. The folders are research artifacts, and the responsibility for reporting anything to a vendor sits with whoever picks them up.
The folder-per-target layout and how entries are tracked
The README's contents table is the map of the repository. It has three columns: folder name, source, and a count of tracked entries. The source column is the interesting part, because it distinguishes two origins.
Some folders carry a commit hash, for example `objdump-dlx-calc-poc` with `7df01e4e20c7375a89e8ccf760526c52eb6ad582` and 41 tracked entries, or `docker-cp-copyout-destination-escape` with `d1367b1381736d7f961ac808ce88d4e24a633adc` and 5 entries. These are former standalone repositories that were folded into this one. Others are marked "direct entry" with a date, such as `c-ares-tcp-uaf-calc-poc` (June 24, 2026, 7 entries) or `rustdesk-session-permission-pocs` (June 25, 2026, 17 entries). Those were written into this repository from the start.
The README explains how the consolidation was verified: "from fresh GitHub clones on June 23, 2026 before the old standalone repos were removed," comparing each former repo's HEAD tree against the matching folder using Git tree data. The stated criteria are the same relative path, the same Git object type, the same tree mode including executable bits, and the same Git blob ID. The README claims the check covered 12 repos and 96 tracked entries with zero mismatches.
That is a stronger claim than a filesystem diff, because matching blob IDs means the tracked file bytes are identical. It is also the kind of claim you can re-verify yourself against the tree data, which matters if you are citing one of these PoCs in your own writeup. What the consolidation does not preserve, per the README, is repository-level metadata: stars, issues, pull requests, releases, and separate Git history stayed behind in the original repositories.
Cloning the archive and reading your first PoC
There is no package to install. The README gives no install steps and no released artifacts, and the repository has no releases. The way in is to obtain the repository, then read the folder you care about. The README states that former standalone repos were removed after consolidation, so the folder here is the current location for that material.
The README's contents table is the index: it lists every folder name, its source, and its tracked entry count. Start there and pick a target. Then open that folder and read its own README before touching any code, since the top-level README does not document per-folder usage:
cd curl-smtp-expn-recipient-crlf-injection
ls -la
cat README.mdThe per-folder README is where a given PoC's own instructions live. The top-level README does not describe how to run any individual entry, does not state supported platforms per folder, and does not document a rollback or cleanup step. Treat the folder README as the only usage documentation you have, and expect it to vary in quality: the author states the README files are "very clearly entirely AI" in origin, reviewed for accuracy by hand.
If you want to confirm that a folder matches the former standalone repository it came from, the README's consolidation section describes the check: the same relative path, the same Git object type, the same tree mode including executable bits, and the same Git blob ID, compared using Git tree data rather than a loose filesystem diff. You can repeat that comparison against the commit hash listed for the folder in the contents table.
Where the archive stops being useful
The first limitation is stated by the author: "This repo was incomplete when published." That is not a disclaimer about polish. It means the contents table is the authoritative list of what exists, and anything you remember from a former standalone repository that is not in that table is not here.
The second is that the archive has no advisory layer. There is no per-folder statement of affected versions, no patch status, no vendor response, and no CVE assignment, because the README says none of the issues had been reported at publication time. If your question is "is my deployment affected and is there a fix," this repository cannot answer it. A folder named `firefox-152.0.6-stock-page-native-calc-poc` tells you the target and the bug class; it does not tell you which builds shipped the fix.
The third is scope. The folders are proof-of-concept code for specific targets, written by one author, with heavy AI involvement in the workflow. The README is explicit that fuzzing was automated with GPT-5.3 under a fixed workflow, that the PoCs themselves were hand-typed except for RustDesk where the author used AI assistance because of unfamiliarity with the language, and that the README files are AI-written. None of that makes the findings wrong, but it does mean the per-folder documentation should be read as generated text that a human reviewed, not as a careful research narrative.
Finally, there is no licence file in the repository listing and no licence identifier in the README. Do not assume you can reuse the code in a product.
How this differs from a CVE database or an exploit framework
The obvious comparison is with a maintained vulnerability database such as the NVD or a vendor advisory feed. Those are organized around identifiers, affected version ranges, and remediation status. Exploitarium is organized around targets and PoC folders, and the README states plainly that the issues had not been reported when published. The two answer different questions: a database tells you what to patch, this archive shows you how someone demonstrated a bug.
The second comparison is with an exploit framework, which packages modules behind a common interface, a launcher, and a session model. Exploitarium has none of that. There is no runner, no module registry, and no shared dependency set; the folders are independent and the top-level README does not document a way to execute them together. If you want a single command that loads a target and fires a payload, this is the wrong repository.
The third comparison is with a curated CTF or training set, which is designed to be safe to run and comes with setup instructions. Exploitarium is real-target research code with an explicit abuse warning: "Do NOT, under any circumstances, use any material in this repository maliciously." The repository's value is as a reference corpus, and its risk profile is that of running research code against software you may actually depend on.
Maintenance, licensing and what changes over time
The repository is not archived, and the last push was on 2026-09-16. New research is added as self-contained folders rather than by rewriting existing ones, which keeps the upgrade cost low in one direction: pulling the latest commits does not invalidate a folder you already read. The cost is that the top-level README's contents table is the only index, and it is maintained by hand alongside the folders.
There are no releases, so there is no versioned artifact to pin. If you vendor a folder into your own notes, record the commit you took it from. The README's own consolidation section is a model for that practice: it records commit hashes for the former standalone repositories and states that repository-level metadata such as stars, issues, pull requests, releases, and separate Git history remained in the original repository histories. If you need that metadata, it is not here.
On licensing, the README gives no licence identifier and there is no licence file at the top level. That is a real constraint rather than a formality: absent a licence, the default position under most copyright regimes is that no reuse rights are granted, and the README's abuse section is a conduct request, not a licence. Anyone intending to redistribute a folder, or to build it into a product or a training corpus, needs to resolve that with the author first. This is a description of the repository state, not legal advice.
Editorial conclusion
Adopt it only if you want a reference corpus of public PoC folders with their original READMEs and tracked files, and you are prepared to read each entry's own notes before running anything. Do not use it as a detection tool, a patch-status source, or a substitute for vendor advisories: the README states none of the issues had been reported when the author published them, and the repo was incomplete at publication. Before relying on any folder, verify its tracked entries against the consolidation claims in the README and check the matching upstream project's own advisory channel.
Frequently asked questions
What does exploitability mean?
The README does not define the term. Exploitarium is a collection of proof-of-concept code and writeups for specific targets, so the folders demonstrate that a bug can be triggered rather than providing a general definition of exploitability.
What are the top 5 CVE vulnerabilities?
The repository does not rank vulnerabilities. Its README states that none of the issues had been reported when the author published them, and the folders are named by target and bug class rather than by CVE. One folder, libssh2-cve-2026-55200-poc, carries a CVE identifier in its name.
What does exploit vulnerability mean?
The README does not define the phrase. What it shows is the concrete form: folders such as redis-vset-duplicate-hnsw-id-rce-poc and qemu-cxl-type3-mailbox-escape-poc each hold proof-of-concept code and a README for one target.
What are known exploited vulnerabilities?
Exploitarium does not track exploitation in the wild. The README says the issues had not been reported at publication time and asks readers not to use the material maliciously, so the archive documents proof-of-concept work rather than observed attacks.
Community notes