An anonymous GitHub account using the handle bikini has turned a cluster of vulnerability proof-of-concept repositories into Exploitarium, a public archive that frames the work as open-disclosure research and says some of the findings were produced with an AI-automated fuzzing workflow.
The archive is less important as a single exploit dump than as a preview of the queue open-source maintainers are about to face: machine-assisted vulnerability discovery is moving faster than human validation, and the output is messy. Exploitarium currently lists 23 folders covering projects and products including FFmpeg, c-ares, libssh2, Ghidra, Gitea, Nmap, VLC, Firefox, OpenVPN Connect, RustDesk and PHP. The repository says direct entries were added between June 23 and June 26, 2026, with some older standalone PoC repositories consolidated into the archive after a June 23 clone-and-tree comparison.
The author does not disclose a real name. In the repository statement, the author says the first publication was incomplete and concedes that some findings are weak, explicitly calling out Ghidra, while saying future drops will focus only on Floci, libssh2, FFmpeg and c-ares. The same note says the fuzzing workflow was automated by AI with a strict harness, that the author used a model described as "GPT-5.5-3-Codex-Spark" for all fuzzing, and that the actual PoCs were hand-typed except for RustDesk assistance. None of those claims can be independently verified from the repository alone, and the model name is not tied in the repo to a public product page or release note.
The libssh2 item is the clearest example of the split between theater and substance. The folder for CVE-2026-55200 describes an unchecked SSH packet-length condition in libssh2's transport parser and links to an upstream fix. The NVD entry says libssh2 through 1.11.1 had an out-of-bounds write in ssh2_transport_read()
that could allow remote attackers to corrupt heap memory and achieve remote code execution, and lists a critical CVSS 3.1 score from NIST. The upstream libssh2 commit adds packet-length bounds checking and credits TristanInSec.
That makes at least part of the archive more than noise. It also undercuts the blanket "undisclosed zero-day" framing around the whole collection: one of the most prominent entries now maps to a published CVE, an NVD record, and an upstream patch. The repository's own libssh2 README calls its malicious-server component a trigger scaffold and says its local RCE harness is not a universal exploit for every deployment. That distinction matters because a proof that a code path can be driven in a lab is not the same as a reliable field exploit against a default configuration.
The c-ares and FFmpeg entries make the same point from the other direction. The c-ares folder claims an unpatched use-after-free in the ares_getaddrinfo()
path and says the PoC reached a local calculator proof against both upstream main
and release v1.34.6
. The README also narrows the claim: it calls the work a local proof harness, not a universal exploit for every application that links c-ares, and says the effect depends on the affected path, response sequence, allocator shaping and cleanup path being present.
The FFmpeg folder claims a heap out-of-bounds write in the RASC decoder, verified against an upstream master commit dated June 26, 2026. Its README says the proof uses the public libavcodec API and a custom buffer callback to place an adjacent callback pointer where the overwrite can redirect it. That is a useful exploitability signal, but the README's structure also shows the work remains highly harness-dependent. For operators, the question is not whether a calculator launched in the author's environment. The question is which real applications expose that decoder path, with what memory layout, sandboxing and input controls.
The weaker entries are just as instructive. The Ghidra folder is careful in places to call its claims conditional: local arbitrary code execution when a restored or configured Swift tool directory is used by the Swift demangler analyzer, conditional TraceRMI execution when an untrusted peer can drive an already-created debugger-agent channel, and native parser reachability evidence for SevenZipJBinding. That is not nothing, but it is also far from a turnkey remote compromise of Ghidra.
This is the disclosure problem compressed into one repository. AI-assisted security research can generate real leads, but it can also generate large volumes of half-validated findings that read like finished advisories. Anthropic's own coordinated vulnerability disclosure dashboard shows the scale: as of May 22, 2026, Anthropic said Claude Mythos Preview had produced 23,019 candidate findings, 1,900 were manually reviewed, 1,726 were confirmed valid by external security firms, and 1,596 vulnerabilities had been disclosed across 281 open-source projects. Anthropic also said only 97 of those disclosed findings had been patched by that date.
That is the responsible version of the pipeline: model output, human triage, private reporting and disclosure windows. Exploitarium is the public-drop version. It collapses discovery, validation, disclosure and distribution into a GitHub repository. The author includes an anti-abuse warning and says the work is meant to get more people interested in cybersecurity, but a warning is not a mitigation strategy.
The open-source ecosystem has been preparing for exactly this failure mode. The OpenSSF vulnerability disclosures working group opened an AI-SLOP issue in February 2026 to develop practices for maintainers dealing with high volumes of low-quality, AI-generated vulnerability reports. The issue explicitly tries to balance two facts that Exploitarium puts side by side: AI tools can find valid vulnerabilities, and AI-generated reports can create a DDoS-like triage burden when they arrive without enough human review.
OpenSSF's May 2026 guide, Securing Open Source in the Age of AI, gives the cleaner process: respect project reporting guidelines, privately provide a proof of concept or proof of vulnerability, provide patches and regression tests where possible, and be clear about how AI tools were used. Exploitarium follows one of those norms, disclosing AI assistance at least in broad terms, while ignoring the central one: coordinated private disclosure before public release.
The practical consequence is that maintainers now have to treat the archive as both signal and spam. libssh2 shows there are real vulnerabilities in the pile. Ghidra shows there are also conditional or overstated findings that can consume triage time. c-ares and FFmpeg show the hardest middle category: plausible, technically detailed reports that require project expertise to separate a local harness from production risk.
That is the new normal, at least for the next phase of AI security tooling. The limiting factor is no longer whether a motivated researcher can point a model, harness and fuzzer at open-source code. It is whether maintainers, security teams and downstream vendors can process the results quickly enough to patch real bugs without treating every AI-amplified claim as a crisis.