Exploitarium is a consolidated archive of public exploit proof-of-concept code and vulnerability research writeups, gathered into a single repository by one researcher. It is aimed at people trying to break into offensive security — readers who have read about memory-safety bugs but never watched one fire — and at working researchers who want a supply of unclaimed findings to verify for themselves. The code is mostly Python, the repository was created in June 2026, and it has collected roughly 4,400 stars and 1,200 forks. The author's stated motive is recruitment: he publishes because he believes this is the most efficient way to pull people into the field.
What it does
Most proof-of-concept exploit code lives in one-off repositories that stop being touched the day after they are published, which makes the work hard to find and harder to learn from. Exploitarium collects that output in one place. Most folders contain one of the author's former standalone PoC repositories, preserved with its original README and tracked files; newer research is added directly as self-contained folders. A contents table at the top of the README indexes the folders by source and tracked files.
The video walks that table and counts 39 real targets, among them Firefox, Ghidra, Docker and OpenSSH, and notes that one entry alone tracks 41 separate exploit variations. The unusual part is the disclosure posture: at the time of posting, the author says, none of these had been reported to the affected projects. He invites readers to report them and take the CVE credit if one is handed out, and asks plainly that they not be abused.
How it works
The README is unusually direct about method, including the role of AI. The author says his fuzzing workflow is automated and that he used GPT-5.3 for all of the fuzzing, on the argument that very little "thought" is required once an efficient workflow exists. He claims a degree in the subject and published papers on fuzzing methodology, and says his data shows that a state-of-the-art model is only marginally better than a cheaper one when paired with decent human oversight and a good workflow.
The split he draws is worth reading carefully:
- The fuzzing that surfaces candidate crashes: AI-driven.
- The proofs of concept themselves: hand-typed, with RustDesk called out as the exception, where he used AI assistance because he is less familiar with the language.
- The per-folder README files: written by AI and then reviewed by him for accuracy.
He also notes that the repository was incomplete when it was published, and credits another researcher for the objdump finding — 4D4J, whose separate repository got there first with what the author calls a better PoC.
Getting started
There is nothing to install and no build step. Start at the contents table in the root README, pick a target whose internals you already understand, and read that folder's README alongside its code before running anything.
Expect to do work. The author notes that a surprising number of people could not adapt the PoCs to their own environments, and says he will broaden them for those cases. Treat every proof of concept as environment-specific: versions, build flags and operating system will differ from his. Run them in a disposable virtual machine or container, against software you control. For collaboration or discussion the author lists a Telegram handle, @ashdfrkl.
When to use it / when not
Use it if you want to see what a real crash reproducer looks like in full rather than as a paragraph in an advisory; if you are a researcher willing to validate a finding and file it properly; or if you are studying how an AI-assisted fuzzing workflow is actually assembled by someone who does it seriously.
Do not reach for it as a tool. It is an archive, not a scanner, not a framework and not something to wire into a pipeline. The fact that the findings are unreported cuts both ways: vendors have had no chance to ship patches, so pointing any of this at systems you do not own is a legal problem rather than an experiment. And because the author himself flags the repository as incomplete and the writeups as AI-generated, verify anything before you cite or report it.
Alternatives
The alternative is the situation the repository was built against: dozens of scattered single-PoC repositories, most of them abandoned. The author points to one directly, 4D4J's objdump out-of-bounds write repository, which he credits over his own. Nothing in the material compares Exploitarium to a curated advisory database or to a fuzzing framework, and it should not be mistaken for one — this is one person's output, not a catalogue of the field.
Take this repository seriously if you work in vulnerability research or want to. For newcomers it is a rare thing: a large body of working exploit code with the reasoning attached, published to teach rather than to sell. For experienced researchers it is a queue of live, unclaimed findings with an explicit invitation to report them and keep the credit. And for anyone arguing about whether AI-assisted bug hunting produces real results, it is a concrete data point with the workflow spelled out. Everyone else should read it and leave the code where it is.