Death By 20,000 PoCs | Blog

Exploits are at the heart of everything the Initial Access Intelligence team does at VulnCheck. We write them, run them on targets we’ve built ourselves, create detections from them, and then try to bypass those detections, just for fun. No matter how many other artifacts we deliver, all our work starts with an exploit, which means we’re particularly interested in new proof-of-concept exploits (PoCs).

We collect and generate a lot of data here, and none of it is wasted. The Initial Access Intelligence team reviews proof-of-concept exploit code on public Git forges and code sharing platforms for inclusion in VulnCheck Exploit & Vulnerability Intelligence data. Accepted exploits also get included in XDB, the VulnCheck Exploit Database. The team reviewed and curated roughly 20,000 exploits in 2025; we’re not yet two thirds of the way through 2026, and already the exploit corpus our team has evaluated this year is close to 18,000. This blog examines exploit volume and validity for 2026 YTD, and then analyzes the “why” behind all the rejected exploits that never made it into our data.

Every day, dozens of exploit repositories are added to GitHub, with larger spikes during emerging threats or for particularly high-profile CVEs. The exploit dev team at VulnCheck goes through each of these repositories to determine the legitimacy of the exploit(s) therein. If the exploits are found to be invalid or bad (for whatever reason), then the repository is omitted from our data. After the initial AI slop boom in 2025, the team decided to enrich our rejected GitHub PoC data by recording the reason for the rejection, which allows us to tease out patterns over time.

While GitHub-hosted repositories are just one source of PoC data in the VulnCheck universe, they’re an important one, comprising 14-20% of the exploit code we track in any given year and representing thousands of team exploit reviews annually. Acceptance rate for GitHub exploits has hovered around 51% over the past couple of years; in 2026 so far, acceptance of new PoCs has dropped to about 45%, which is definitely both notable and noticeable.

The team rejects bad or invalid GitHub exploits for various reasons, including:

• Not an exploit (most common): Placeholder repos, non-code-containing summaries, checker scripts, etc. AI is driving volume up on these types of repos.
• Fake / AI-generated: Looks like it could be real exploit code (but isn’t)
• Malicious: Fake, but worse
• Pay link: Someone’s trying to get you to buy their “exploit” (wouldn’t advise it)
• Obfuscated: If you can’t read it, it’s because the author didn’t want you to read it
• Fork: Forked repo, not original work

Failing to actually contain any type of exploit code is the most common reason for the team to disqualify GitHub repos from VulnCheck data. Many of these repos are AI-generated summaries, heavy with emojis and stylization. Fake, AI-generated “exploit” PoCs that don’t do what they claim to do are the second most common category of rejections. Below, we walk through what some of these rejection categories look like using real examples.

As the name suggests, “Not an Exploit” repositories are repos that do not actually contain an exploit but that also do not fall into another category. The repository could be an empty placeholder for an exploit that may never come (translation: very likely will never come). The repository may contain code, but solely for the purposes of a check and not actual exploitation. The repository may discuss the exploit but not actually contain any code or usable data, representing something more akin to a collection of research notes.

The above repo was assessed as a potential “exploit” for CVE-2026-0265, an authentication bypass vulnerability in Palo Alto Networks’s PAN-OS. As you can see based on the name of the repository, it contains code that checks for the vulnerability but does not exploit it.

Here is another “not an exploit” example, though this one is a little different. Looking at the contents list at the top of the screenshot, this repository contains only a YAML file and a README file, and no code.

The stylization and emojis are also obvious indicators of AI-generated content. Many of the repos the team rejects as “not an exploit” are AI-generated, meaning a significant part of AI-driven “PoC” volume is represented across these two rejection categories.

And now for our favorite category: fake and AI-generated, which usually means GitHub repos that contain what appears to be exploit code, but upon closer inspection has hallmarks of AI generation (and is totally bogus). The code in these repositories does not in fact work, though it’s also not deemed outright malicious. We’ve seen a clear trend in fake AI GitHub PoCs this year, as the chart below shows.

Compare that to fake (but not AI-generated) below:

Fake, AI-generated PoCs are often created to spread disinformation, generate “clout”, or bolster a resume in hopes that nobody looks too deeply (though I would suggest that anyone these repositories might possibly convince is likely not worth convincing).

Judging by GitHub stars, which are basically akin to Facebook likes for code repositories, not that many users are outright fooled by AI slop PoCs, but that may not hold for commercial solutions, many of which ingest GitHub PoCs as risk indicators wholesale without any validation or filtering. The chart below shows how many GitHub stars are on repositories that our team has classified as fake and AI. Quite a few repositories in this category have been taken down since we first analyzed them.

As another example, the screenshot below depicts a GitHub repo for CVE-2026-55200, an out-of-bounds write vulnerability in libssh2 that received a bit of public fanfare when a PoC was published the day after disclosure.

Public attention plus a valid PoC pretty much always means the team will see an influx of AI-generated content for that CVE. This repository does actually contain some code, which we will look at in a moment. But it’s clearly AI-generated.

In the README, we see very high level information and a couple of emojis, which are ubiquitous across almost all of these AI-generated repositories. If we cross-reference the VulnCheck CNA’s description of this CVE with the contents of the README displayed above, it is essentially the same information, only “stretched out” to take up as much space as possible:

The same tactic is employed by almost all of the AI-generated exploit repositories on GitHub, the giveaway being that very little is said but always takes a great number of words to say. If you’re looking at a 200-word README file that could have been 20 words, it is likely AI-generated.

Now we’ll look at the “exploit” code in this repository, which I think makes for a good example. For AI slop which likely involved little effort, the code can look pretty convincing at a (very) quick glance, especially if you are not very familiar with the underlying vulnerability.

We know from the advisory on CVE-2026-55200 that this exploit is supposed to be for a memory corruption vulnerability; based on that, we would expect to see some setup of offsets, gadgets, or even some shellcode in the repo’s “exploit” code. Even if these are lacking, it’s still possible that the exploit is a DoS PoC, whose goal might be to prove the vulnerability’s legitimacy by crashing the program (rather than getting a shell). But if we go down and look at the main function, we can see that this program waits for a connection back: That implies that this “exploit” should result in a reverse shell back to the attacker:

When we look at public research on the vulnerability, we can see the PoC has even more red flags, such as the fact that to hit the vulnerable sink, the attacker has to send the data using the chacha20-poly1305 cipher. This PoC employs no encryption whatsoever. Admittedly, digging deep into a vulnerability’s root cause is seldom required to diagnose AI PoCs, since this is about as convincing as AI-generated “SloPoCs” get.

Outright malicious PoCs do not make up a very large portion of the repos the VulnCheck team reviews, but we do see them regularly. Gentle reminder to readers: Don’t run unvetted research artifacts. If you can’t understand the code, it’s because you weren’t meant to.

One malicious PoC we reviewed a while back hit close to home for us: Someone had taken VulnCheck’s scanner for CVE-2023-36845, added a small bit of malicious code that downloads and executes a payload from a remote location, and then re-uploaded the scanner to GitHub.

Towards the end of the code you can see what was added:

A function was inserted. A string array within the inserted function contains various letters, and then the final malicious shell command is formed by concatenating indexes to this array. Towards the start of runtime, this mvpCAMf global variable is initialized with the output of the malicious function, jEffeKR. In doing so, it runs the function and executes a wget command locally to download and execute the malicious payload from vanartest[.]website. A quick search for this domain brings up a few articles, including this LinuxSecurity blog that describes a Golang-based campaign that executed disk-wiping payloads. Not exactly nation state-level effort, but likely effective enough to snare a few victims running malicious research artifacts.

Another common trope the team sees in malicious PoC code is base64 blobs. This malicious PoC claimed to be an exploit for CVE-2026-41940, an auth bypass vulnerability in cPanel and WHM’s login workflow.

At a glance, this is probably one of the most obvious backdoors ever…but in order for that fact to be obvious, the user has to take a glance. Hey, read the code!

You might say that this particular malicious PoC author did go the extra mile. After deciding that base64 encoding their payload was too obvious, they did the next best thing: They base64 encoded it again. So this “exploit” contains a base64+base64’d blob of Python code that gets run in exec, a Python function that dynamically executes Python code from a given string. This is what it looks like when we decode it:

When we base64 decode the first blob we see another Python script. This second script contains two branches depending on your operating system, each with yet another exec call with yet another double base64 blob as its argument. Double decoding one of these blobs finally gets us to the bottom of this matryoshka doll to see what the author intends to do…which is apparently to download and execute some badness on your host.

The takeaway is that unexplained base64-encoded blobs should be treated with extreme suspicion. Once again, if the code isn’t understandable, it’s often because the author doesn’t want the observer to understand it. We encourage others in the research space to report malicious PoCs on GitHub when they encounter them; it only takes seconds and GitHub usually does take action. GitHub support has removed almost every repository that our team has reported, usually within a week of the report.

Obfuscated PoC repos don’t fall into the outright malicious category, but most of them are probably malicious in the end. If, dear reader, you stumble upon a PoC, attempt to read the code, and cannot read the code, that is because the author does not want you to read the code. Consider why someone might be giving code away for free but also telling you that you are not allowed to read it. This is a giant red flag and should be assumed to be malware (and potentially reported to GitHub for good measure). Don’t run obfuscated code, friends, free or otherwise.

This particular example uses Pyarmor, a tool used for obfuscating Python code. Not being able to read the code on a site made for reading and sharing code = something’s up. Do not trust.

We’ll also run into paid link repos every once in a while, which contain a link to a third-party website in lieu of an exploit (or any code at all). These sites frequently have “Satoshi” in the name, and they would very much like you to send them cryptocurrency. These repositories offer the golden opportunity to pay someone so that you can almost definitely not get the exploit you coveted. I doubt most people would fall for these, but I have been disappointed before. Here’s what these look like in the wild:

Terminal output: Check. Sales description: Check. Educational disclaimer: Check. Actual exploit? Href, bro.

And finally, the point: a tinyurl link that goes to satoshidisk[.]com. Pay link confirmed!

We would suggest reporting any pay link repositories to GitHub, even if they’re not outright malicious. Getting rid of these makes a site many of us use a better place, and it will be one less repository we have to review when it 404s after its takedown.

AI is finding real vulnerabilities, but it’s also generating a whole lot of slop code and stylized noise with no real value. The VulnCheck team has seen substantial growth in both exploit volume generally and GitHub exploits specifically, with a markedly higher rate of invalid or fake exploit repos in 2026 vs. 2025.

A cynical person might read this blog and conclude that most exploit code on the public internet these days doesn’t actually work. But plenty of it works just fine for what it was designed for – namely AI clout farming, malware installation, and clickbait crypto scams – it’s just that it often isn’t designed to exploit actual vulnerabilities in any realistic manner. We hope this blog also answered that one guy asking, “Why did my disk get erased, I just wanted to scan Juniper systems!” Well, now you know, Jerry. Read the code next time. Expect us back with more PoC data!

VulnCheck empowers organizations to transcend the challenges of vulnerability prioritization. Our suite of solutions provides product managers, PSIRT teams, and threat hunters with the tools required for accelerated, high-precision operations and infinite efficiency.

Recognizing the industry-wide necessity for superior data velocity and accuracy, we deliver high-fidelity insights to the market. We remain committed to surfacing critical intelligence on vulnerability exploitation and emerging trends, leveraging our unique dataset to support the practitioner community.

For more research like this, see FileRun: When Your File Manager Runs Your Files, VulnCheck State of Exploitation: 1H 2026, and ENDLESSDOORS Is Phoning Home. Pick Up.

Sign up for the VulnCheck community today to get free access to our VulnCheck KEV, enjoy our comprehensive vulnerability data, and request a trial of our Canary Intelligence, Target Intelligence, and Exploit & Vulnerability Intelligence products. Weekly Initial Access Intelligence exploits and detections can be found here.