A GitHub account has assembled a public archive of vulnerability research and working proof-of-concept exploits, including entries the maintainer says had not been reported to affected projects when posted. The repository, named Exploitarium, presents the releases as educational, good-faith research but explicitly invites others to report issues and seek vulnerability identifiers.
The collection lists demonstrations involving software including c-ares, curl, Discord, Discourse, FFmpeg, Firefox, Gogs, Ladybird, libarchive, libssh2, Nextcloud, Next.js, NodeBB, Nmap, OpenSSH, PHP, Pillow, PostgreSQL, QEMU, Redis, RustDesk and System Informer. A repository name or proof of concept alone does not establish that every claimed bug is exploitable in supported software, and the packet contains no vendor advisories or independent reproduction.
The maintainer said 12 previously separate repositories were consolidated after a fresh-clone comparison on June 23, 2026. The check covered 96 tracked entries and compared Git blob identifiers, with no mismatches reported. That verification establishes the author’s claimed preservation process, not the validity or severity of the underlying vulnerabilities. Repository-level history, issues, stars and releases remained with the earlier projects rather than moving into the archive.
The accompanying note gives unusual detail about the research workflow. The author said GPT-5.3 automated all fuzzing under a strict process, while the exploit programs themselves were typed by hand, apart from AI assistance on RustDesk code. The README files were generated by AI and reviewed for accuracy. The author argued that a strong workflow and human oversight mattered more than using the most advanced model, based on their own experience.
Publishing an exploit before coordinated vendor notification is a contentious disclosure practice. Public code can help maintainers reproduce problems and enables defenders to create detection or mitigation, but it can also shorten the time available to patch before abuse. The maintainer’s request not to use the material maliciously does not technically prevent misuse.
One listed objdump finding was credited to another researcher after the maintainer discovered that person had published earlier and had a stronger demonstration. The archive also says it will broaden some proofs of concept for people unable to reproduce them in their environments.
For users and vendors, the responsible response is verification rather than assuming either safety or compromise. The evidence confirms the repository’s claims and inventory; it does not confirm CVE assignments, affected versions or exploitation in the wild. Those questions require review by the relevant maintainers and independent security researchers. Maintainers receiving credible reports should preserve evidence, reproduce them in isolated environments and coordinate fixes before public conclusions. Users should rely on authenticated vendor guidance for affected-version and mitigation decisions rather than running untrusted demonstrations on operational systems.
