Exploitarium Repository Publishes 204 Files Across 35 Vulnerability Projects

An anonymous security researcher using the GitHub handle “bikini” has published a growing collection of proof-of-concept exploits and vulnerability research without documenting advance notification to affected software vendors.

A LevelBlue SpiderLabs investigation counted 204 tracked files across 35 project folders. This total does not represent 204 separate zero-days because each folder can contain exploit scripts, documentation, test files, patches, and supporting code for one or more findings.

The public Exploitarium repository says its maintainer had not reported the findings when posting them. The README invites other researchers to report the vulnerabilities and claim CVE credit, reversing the normal coordinated disclosure process.

Exploitarium Archive at a Glance

Category	Observed figure
Tracked project folders	35
Total tracked files	204
Original consolidated repositories	12
Projects added directly after consolidation	23
Native code, kernel, or driver projects	19
Web application and authentication projects	13
Remote-access or impersonation projects	3

Early reports described roughly 130 proof-of-concept files affecting around 15 targets. The collection continued growing after that initial coverage, leading to the later count of 204 files across 35 folders.

LevelBlue found that the repository added about two or three project folders per week through at least July 4. Recent additions covered PostgreSQL, Redis, Nextcloud, Discourse, Next.js, Gogs, and other widely used projects.

The repository’s broad scope increases the work required from defenders. Security teams must separate credible, reachable vulnerabilities from crashes, low-impact fuzzing results, duplicates, unsupported claims, and issues that vendors have already fixed.

204 Files Do Not Mean 204 Zero-Day Vulnerabilities

A tracked file may contain a README, test harness, payload generator, patch proposal, screenshot, build instruction, or exploit script. Counting every file as a separate exploit creates an inaccurate picture of the archive.

The largest folder, objdump-dlx-calc-poc, contains 41 tracked files. The RustDesk folder contains 17, while one libssh2 public-key folder contains 10. The remaining 32 folders average fewer than five files each.

The 35-folder count provides a better estimate of the collection’s breadth, but it still does not prove that every folder contains a distinct, exploitable zero-day. Vendors and independent researchers need to reproduce each claim and examine the affected code.

Repository folder	Tracked files	Reported target
objdump-dlx-calc-poc	41	GNU objdump
rustdesk-session-permission-pocs	17	RustDesk
libssh2-publickey-list-calc-poc	10	libssh2
ghidra-12.1.2-rce-ace-calc-poc	9	Ghidra
openvpn-connect-echo-script-ace-poc	8	OpenVPN Connect
c-ares-tcp-uaf-calc-poc	7	c-ares
ffmpeg-rasc-dlta-calc-poc	7	FFmpeg

Uncoordinated Disclosure Removes the Vendor Preparation Window

Coordinated vulnerability disclosure normally gives a vendor time to confirm the problem, build a patch, test supported versions, assign a CVE, and prepare guidance before researchers publish technical details.

Exploitarium makes the research public first. Vendors, defenders, attackers, hosting providers, and security companies can therefore access the same information at roughly the same time.

Initial reporting on the repository noted that outside researchers had not verified every exploit claim. That distinction remains important because a public proof of concept can contain errors, require unusual conditions, or demonstrate a crash without establishing reliable code execution.

• Vendors receive less time to reproduce and patch reported flaws.
• Defenders may have no official affected-version information.
• Attackers can study the proof of concept while patches remain unavailable.
• Security teams must validate a large number of uneven findings.
• Automated scanners may produce false positives or incomplete results.
• Downstream projects may not know they include an affected dependency.

Targets Range From Libraries to Web Applications

The collection covers native C and C++ applications, Windows kernel drivers, web applications, authentication systems, remote-access software, command-line tools, and cloud-related services.

Nineteen of the 35 folders focus mainly on memory-safety problems in native applications, kernels, or drivers. These issues include out-of-bounds access, use-after-free conditions, integer errors, and other flaws that automated fuzzing can help uncover.

Another 13 folders cover web application or authentication logic. Their names reference API-key scoping, bearer tokens, cache collisions, privilege changes, cross-site request forgery, and pre-authentication access controls.

Area	Examples named in the archive
Libraries and utilities	libssh2, c-ares, curl, libarchive, ImageMagick, Pillow
Developer and analysis tools	Ghidra, Nmap, objdump, FFmpeg
Web applications	Discourse, Gitea, Gogs, MyBB, NodeBB, Nextcloud
Infrastructure	PostgreSQL, Redis, Docker, QEMU, nghttp2
Remote access	AnyDesk, RustDesk, OpenVPN Connect
Browsers and desktop software	Firefox, Ladybird, 7-Zip

libssh2 CVE-2026-55200 Shows the Potential Impact

One of the most serious confirmed findings connected to the archive affects libssh2, a client-side library that applications use to communicate over the SSH2 protocol.

The NVD entry for CVE-2026-55200 describes an out-of-bounds write in ssh2_transport_read(). Versions through libssh2 1.11.1 failed to enforce an upper limit on the packet_length value received in an SSH packet.

A malicious SSH server can send a crafted packet to a vulnerable client before authentication completes. Successful exploitation could corrupt heap memory and execute code inside the application that uses the affected library.

• Affected product: libssh2
• Affected versions: libssh2 1.11.1 and earlier
• Weakness: integer overflow leading to an out-of-bounds write
• Attack position: malicious or compromised SSH server
• Authentication: attack can occur before SSH authentication completes
• Potential impact: memory corruption and remote code execution

Coordinated Research Also Found the libssh2 Flaw

The libssh2 case complicates claims that every confirmed vulnerability originated exclusively from the anonymous archive. Exploitarium published a proof of concept, but another researcher followed a coordinated reporting path for the same underlying flaw.

VulnCheck’s advisory credits researcher Tristan Madani with reporting CVE-2026-55200. VulnCheck assigned the vulnerability a CVSS 4.0 score of 9.2 and identifies libssh2 1.11.1 and earlier as affected.

Maintainers corrected the bounds-checking problem in libssh2 commit 97acf3df. This overlap shows why vulnerability counts need careful attribution: separate researchers can discover the same defect through different disclosure processes.

The Repository Now Accepts Outside Contributions

Exploitarium began as a consolidation of the maintainer’s earlier standalone repositories. It later expanded with findings published directly inside the archive and contributions from other researchers.

LevelBlue highlighted a contribution from the GitHub user “Unrealisedd,” who submitted Windows kernel driver findings affecting OpenVPN’s ovpn-dco-win component. The contribution included use-after-free and information-disclosure issues with suggested code changes.

The repository history and README also identify research linked to external contributors. This makes the project less like one researcher’s static archive and more like a lightly moderated collection of offensive security work.

Not Every Repository Entry Carries the Same Risk

Security teams should not rank vulnerabilities only by the presence of exploit code. A proof of concept may demonstrate a local crash, require elevated privileges, depend on an uncommon configuration, or target code that production builds rarely reach.

Other findings may expose unauthenticated network services, browser processes, remote-access tools, or libraries embedded inside many applications. These issues deserve higher priority because they combine broad distribution with reachable attack surfaces.

The LevelBlue assessment recommends evaluating practical reachability and blast radius. Organizations should consider where a component runs, what data it handles, whether attackers can access the vulnerable code path, and what privileges the affected process holds.

Priority factor	Question for defenders
Network exposure	Can an external or untrusted system reach the vulnerable function?
Authentication	Does exploitation require a valid account or elevated privileges?
Deployment scale	How many systems, images, applications, or devices include the component?
Process privilege	What access would code execution provide?
Exploit reliability	Does the proof of concept demonstrate repeatable impact?
Patch availability	Has the vendor released a tested fix or supported version?
Compensating controls	Can segmentation or feature restrictions block the attack path?

Open-Source Dependencies Expand the Exposure

Many organizations may not install the named projects directly. They can still inherit vulnerable code through operating-system packages, application bundles, containers, firmware, developer tools, or statically linked libraries.

libssh2 provides a clear example. Backup software, Git clients, network management products, PHP applications, embedded devices, and file-transfer tools can include the library without displaying its name to users.

This transitive exposure turns the repository into a software supply chain issue. A security team may patch its operating systems while overlooking a vendor application that bundles an older library inside its own installation directory.

How Organizations Should Respond to Exploitarium

Organizations should begin with software composition analysis across source repositories, build pipelines, container images, endpoints, servers, and firmware inventories. Package names alone may not reveal statically linked or vendored dependencies.

For libssh2, teams should compare installed or embedded builds against the CVE-2026-55200 affected-version information. They should move to a vendor-provided fixed release or a supported build that includes the upstream correction.

When no release package exists, developers should review the upstream libssh2 patch and obtain guidance from their software supplier. Organizations should avoid applying an isolated source change to production without testing compatibility and support implications.

1. Inventory the 35 named projects and their embedded dependencies.
2. Map each project to installed applications, containers, and devices.
3. Check vendor advisories and upstream issue trackers for confirmation.
4. Prioritize remotely reachable and pre-authentication vulnerabilities.
5. Test available patches in representative environments.
6. Use network restrictions or feature controls when patches remain unavailable.
7. Monitor for exploit attempts against internet-facing services.
8. Rebuild container images and statically linked applications after updating libraries.
9. Document false positives and unsupported claims without removing them from monitoring.
10. Repeat the assessment as the repository adds new folders.

Exploit Claims Still Require Independent Validation

The repository’s public availability does not guarantee that every script works as described. Some proof-of-concept files may only reproduce a crash or depend on a narrow build configuration.

The initial independent coverage stressed that reporters had not verified all the researcher’s claims. Security teams should avoid running untrusted exploit code on production systems or developer workstations.

Analysts should reproduce findings inside isolated test environments, review every script before execution, and block network access that the test does not require. Repository popularity, file count, or exploit naming should not replace technical validation.

Exploitarium Remains an Ongoing Triage Problem

The archive continued growing after its first wave of publicity. New project folders, outside contributions, and revisions mean that a one-time scan cannot provide lasting coverage.

The second LevelBlue assessment of Exploitarium describes it as ongoing infrastructure rather than an incident with a clear end date. It combines credible findings, unverified claims, supporting research, and detection challenges in one public location.

Defenders should track confirmed upstream fixes and affected versions instead of treating every repository file as an equally dangerous zero-day. That approach reduces unnecessary alarm while keeping attention on vulnerabilities with broad, reachable, and high-impact exposure.

The coordinated libssh2 advisory shows the value of this process. It provides a clear affected range, severity score, researcher attribution, weakness classification, and patch reference that organizations can use for remediation.

FAQ