Exploitarium Dropped 204 Live Exploits for curl libssh2 and Nmap With No Warning

Someone published 204 exploit files on GitHub for software you almost certainly use, and told the vendors nothing. The makers found out the same way the attackers did, by reading the page. 🧐

The account goes by bikini. The project is called exploitarium, a single archive of ready-to-run exploit code for software that sits underneath much of what you use. The first dated entries go back to June 23, and by June 27 the page was pulling in stars and hundreds of comments, which meant defenders and attackers were reading the same exploits at the same moment.

Normally a serious bug follows a quiet path. You tell the maker first, they get a set window to fix it, and the public only hears about it once there is a patch to install. That order exists for one reason: it gives the people running the software a head start over the people who want to break in.

The README on exploitarium throws that out. It says none of the findings were reported to any vendor before posting, and it invites readers to go report them and take the credit themselves. So the head start is gone. For most of what is in there, no fix existed on the day it went public.

The first number going around was about 130 files. It was already out of date. LevelBlue’s SpiderLabs team went through the repository this week and counted 204 tracked files across 35 exploit projects, and it kept adding two or three folders a week through at least July 4.

Fresh entries in the first week of July alone:

• → PostgreSQL
• → Redis
• → Nextcloud
• → Discourse

The targets are the tools modern software is built on:

• → AnyDesk and RustDesk, for remote access
• → Nmap, the network scanner
• → curl, the download tool
• → FFmpeg, PHP, OpenVPN, Ghidra, 7-Zip

One folder alone, for the objdump tool, holds 41 separate files. That is the biggest single entry in the archive, and a sign of how much work is going into this.

Not everything in the pile is equally dangerous, and that is part of the problem. Some folders look like low-value output from automated testing. Others are serious. One stands out above the rest, a bug in libssh2 tracked as CVE-2026-55200, and it was there from day one, in the very first batch on June 23.

libssh2 is a small library that lets programs speak SSH, the protocol machines use to talk to each other securely. You probably never install it on purpose. It comes bundled inside tools you already use, like curl, Git, and many PHP builds, and when one of those makes a secure connection, libssh2 is often the piece doing the actual talking.

The bug sits in the part of the code that reads an incoming packet.

An SSH packet starts by announcing its own length. libssh2 read that number but never checked whether it was absurdly large. Send it a packet that claims a huge size, and the math the library uses to reserve memory overflows and wraps around to a small number. The library sets aside a buffer that is too small, and the next step writes straight past the end of it.

That is an out-of-bounds write on the heap. It is the kind of memory corruption that ends in an attacker running code that was never meant to run.

Two things make it worse. It happens while reading the packet, before any login or key check, so there is no password and no account in the way. And this is the client side of SSH, so the danger runs in the direction you would not expect: a malicious server can attack a machine that connects out to it.

That pulls in more than you would think:

• → anything making outbound SSH connections through curl or Git
• → automated build systems and CI pipelines that end up carrying libssh2 by accident

It scores 9.2 out of 10 on the CVSS 4.0 scale, and it affects libssh2 up to and including version 1.11.1.

The fix is one added check that rejects any packet claiming a length over the allowed maximum, before that number can touch the memory calculation. It landed in commit 97acf3d. There is a catch, though. When this was written, the fix lived in that commit and not yet in a tagged release, so grabbing the latest labeled version was not enough on its own.

There is no sign of it being used in the wild yet. It is not on CISA’s list of actively exploited bugs. But a working proof-of-concept is public, and this one does not need mass scanning. It needs a machine that connects out to the wrong address: a hijacked mirror, a poisoned DNS answer, a build pipeline pointed at a server that changed hands.

There is a twist in how the same bug reached the world. The proper route ran first. The flaw was reported through VulnCheck, the fix was merged into libssh2’s mainline, and the CVE was published on June 17 with credit to researcher Tristan Madani. Only on June 23 did the proof-of-concept land in exploitarium, in a folder named after the CVE number it already had.

So the archive’s flagship finding was not an unreported zero-day at all. It was a working exploit for a bug that was already fixed and already public. The most talked-about entry in the pile is the one that followed the rules on its way in.

The hunting behind exploitarium was done with help from an AI. In the README and in an interview, bikini describes using an OpenAI model to fuzz the code. That means throwing malformed input at it to find the spots where it breaks, then checking which ones were genuine by hand. The name kept shifting, first written as GPT-5.5-3-Codex-Spark, later corrected to GPT-5.3.

The detail that matters: the exploits themselves were not written by the AI. bikini typed those. The model did the searching, the person did the weaponizing. LevelBlue noted the AI was leaned on hardest for the RustDesk research, because bikini did not know the language that project was written in.

The sharpest thing about exploitarium is a contradiction sitting right in the repository. The same person who skipped the steps meant to protect the users of this software applied careful, byte-level checking to prove their own archive was intact. Before folding twelve older exploit repositories into the main one, they compared each file’s cryptographic fingerprint, its permissions, and its exact place in the tree, then published the result: 96 files, zero mismatches.

Rigorous about their own work. Indifferent to the people downstream of it.

The mix of targets tells its own story. LevelBlue sorted the 35 folders and found 19 are memory bugs in C and C++ code and drivers, which is what automated fuzzing is good at finding. But 13 go after web and login logic: API keys with the wrong scope, shared-folder tokens, permission checks that can be tricked. Fuzzing alone does not stumble onto those. Someone has to understand the target and aim. The last three go after desktop remote-access and impersonation, in AnyDesk, RustDesk, and Firefox’s Smart Window feature.

So this is not a machine left running on its own. It is a person using a machine to move faster, then picking the valuable targets by hand.

This is the second time in 2026 that an anonymous account has done a mass dump like this, after an earlier campaign called Nightmare-Eclipse. The difference is that this one did not stop. It kept growing after the news moved on, and it started taking in work from other people. One outside contributor, using the name Unrealisedd, added a fresh set of Windows kernel driver bugs in OpenVPN through a pull request. What started as one person’s archive is turning into a place where unvetted exploit code from other people gets collected and handed out.

If you run anything that might carry libssh2, and that is a wider net than it sounds, two moves matter:

• → Update to a build that includes commit 97acf3d
• → Go looking for where the library is hiding, with a scan of your build artifacts, container images and bundled dependencies, because it rides along inside other tools

The wider advice from LevelBlue’s SpiderLabs team, who mapped all this, is to patch by how reachable and how damaging a bug is, not by waiting for proof that someone is already using it. There is even a community project, Exploitarium-Detections, publishing detection rules for Microsoft Sentinel and Defender to spot activity tied to these bugs.

What exploitarium shows is how short the distance is between a proof-of-concept sitting in a public repo and a working attack in someone’s hands. A raw exploit is rarely plug-and-play, and most need reading, understanding, and fixing before they land.

That gap, taking a published exploit for a known CVE, working out why it fails, and editing it until it runs, is exactly the hands-on work I teach in my ethical hacking course. Alongside the recon and scanning skills that show you where these weaknesses live in the first place:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

LevelBlue SpiderLabs | VulnCheck Advisory | libssh2 fix, commit 97acf3d