One GitHub Account Shipped a Dozen Mass-Exploitation Frameworks in a Week. Today's Wears a Fake CVE Number.
- Patrick Duggan
- 51 minutes ago
- 5 min read
Two weaponized exploit repositories landed on GitHub this morning. We caught both. One is an honest tool for a real bug. The other is a mass-exploitation framework wearing a CVE number that belongs to something else entirely — and it did not come from nowhere. It came off an assembly line.
The line
The account is shinthink. It has existed since June 10, and for the first three weeks it did almost nothing. Then, starting July 3, it began shipping — and it has not stopped. In eight days it published roughly a dozen repositories, and read the descriptions in order: a mass reconnaissance and exploitation framework for Apache Solr template injection. A mass exploitation framework for a Joomla Page Builder file-upload bug. A pre-auth RCE scanner for Langflow. A path-traversal-to-RCE exploit for the Avada WordPress builder. A blind SQL injection mass scanner for a Google Maps plugin with 100,000-plus installs. A SQLi-to-shell exploit for Control Web Panel. Every one of them targets a real, recent CVE. Several describe themselves, in their own words, as a "mass exploitation framework."
This is what the wasteland looks like when it industrializes. We have written for months about the space between a CVE disclosure and a patch deployment — the window where attackers stage tooling in public, under real names, while defenders are still reading the advisory. What is new here is the cadence. This is not one researcher publishing one proof-of-concept for one bug they studied. This is a pipeline: take whatever critical CVE dropped this week, wrap it in a multithreaded scanner with user-agent rotation and a self-cleaning payload, ship it, move to the next. The account even published a tool called pocfinder — an interactive terminal utility for searching GitHub's PoC repositories. They built the intake conveyor before they built the factory.
The exhibit: a real bug, a fake CVE
The repository that tripped our alert this morning is named [CVE-2025-20720](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2025-20720), and its description reads: "PolyShell: Magento 2 Unauthenticated Arbitrary File Upload RCE — GIF89a polyglot bypass — 79.5% stores targeted."
Every part of that is real except the CVE number.
PolyShell is genuine, and it is bad. Sansec disclosed it on March 17 as APSB25-94: an unauthenticated file-upload flaw in the Magento and Adobe Commerce guest-cart REST API that reaches remote code execution. Magento's image validator checks that an uploaded file looks like a valid image, but not that its extension matches its contents — so an attacker uploads a GIF89a polyglot, a file that is a valid image header stapled to executable PHP, and it lands in the media directory as a live webshell. Sansec observed exploitation from March 16 and reported that attacks touched 79.5 percent of all stores. The fix shipped in the 2.4.9 branch and was not backported, which means every production shop still on 2.4.8 or earlier is exposed today. The primary research is Sansec's, and it is excellent work.
What is not real is the identifier. CVE-2025-20720, the actual assigned vulnerability, is an out-of-bounds write in a MediaTek WLAN driver — a wireless privilege-escalation bug in chipsets, nothing to do with Magento, e-commerce, or file uploads. Someone took a working PolyShell mass-exploiter and stapled a recycled, unrelated CVE number onto it.
We are not going to pretend to know the motive with certainty. It could be sloppiness — grabbing a plausible-looking number without checking. But the effect is worth naming regardless: a falsified identifier launders a mass-exploitation tool into looking like a routine, legitimately-catalogued PoC, and it defeats the simplest form of tracking, which is to search for the correct CVE and find the tooling built against it. Whether by accident or design, the wrong number is a small act of camouflage.
The code itself is the real thing. It is a twenty-thread scanner that fingerprints Magento three different ways, discovers a valid product SKU, creates a guest cart, and uploads a token-gated PHP webshell that can delete itself on command. One honest note, because accuracy is the whole job here: that self-delete and the access token are the operator's own hygiene — they keep the planted shell private and let the attacker clean up after a hit. They are not a booby-trap aimed at a researcher who clones the repo. This is not the "your security team cloned a webshell and got backdoored" pattern we have documented before. It is a straightforward offensive weapon, pointed outward at unpatched stores, published in the open.
The honest twin
The other repo we caught this morning is the counterexample, and it is worth showing beside the first so the line stays clear. The account 0x77FSec published a single Python file exploiting CVE-2026-23744 — a genuine, correctly-numbered critical flaw in MCPJam Inspector, a tool many developers run locally to test Model Context Protocol servers. The bug is a 9.8: the inspector listens on all interfaces with no authentication and passes attacker-controlled input straight into a shell command, so a crafted HTTP request to its connect endpoint runs code on the developer's machine. The repo's exploit builds a base64-encoded reverse shell and fires it at that endpoint. That is weaponized code — but it is weaponized code for a real, disclosed, actively-exploited CVE, correctly labeled, from an account that otherwise looks like a working offensive-security researcher. Our harvester has been tracking this CVE since May 31; more than ten PoCs already exist for it. This one is a variant, and we logged it as one.
The difference between the two repos is the difference between the two halves of the game we play every morning. One is fast truth: a real bug, named correctly, out in the open where a defender can use the same code to build detection. The other is speed without honesty: a real bug, real exploit code, wrapped in a false label that makes it harder to track and easier to trust. We report the second kind. We index both.
What to do
If you run Magento or Adobe Commerce on any production release up to 2.4.8, PolyShell is your emergency, not a curiosity. There is no backported vendor patch for your line — you upgrade to 2.4.9, or you put a web application firewall rule in front of the guest-cart upload path and you hunt your media directory for PHP files that have no business existing. Sansec, Searchlight, and Akamai have all published WAF and detection guidance; use it tonight, because the mass-exploitation tooling is now public and packaged.
If you run MCPJam Inspector, update past 1.4.2 and bind it to localhost. It was never meant to face the network, and now there is a reverse-shell one-liner for it.
And if you are a security team about to grab an exploit off GitHub to test your own exposure: check the CVE number against the vulnerability. This morning proved the label and the code do not always agree. Held to about ninety-five percent, as always. Credit for PolyShell belongs to Sansec; credit for the MCPJam disclosure to its advisory chain. What we add is the thing a single advisory cannot show you — that the tooling is already on the assembly line, and this week the line is running fast.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.