Your Security Team Probably Cloned a Webshell Last Week
- Patrick Duggan
- Mar 23
- 4 min read
Updated: Apr 25
The Scene
A critical vulnerability drops. CVSS 10.0. Your firewall vendor. CISA adds it to KEV. Slack lights up. The senior analyst on your team does what every senior analyst does: opens GitHub, searches for the CVE, finds a proof-of-concept repo, clones it into the lab.
The repo has a Python exploit script. A README. And two files the analyst didn't notice: cmd.jsp and cmd.war.
Those are webshells. Ready to deploy. Sitting in a directory on your analyst's workstation.
This isn't hypothetical. We found this today.
How It Works
When Cisco disclosed CVE-2026-20131 — a critical flaw in their Firewall Management Center — POC repos appeared on GitHub within 48 hours. That's normal. Security researchers publish proof-of-concept code so defenders can test and understand vulnerabilities.
What's not normal is an account created four days before the CVE was even public, publishing a "POC" that includes a packaged Java webshell alongside the exploit code.
The Python script is the lure. The README explains how to use it. Everything looks legitimate. But bundled in the same repo are files that have nothing to do with the exploit — files designed to give an attacker persistent access to whatever machine they end up on.
The account that published this has seven repositories. Every one is a CVE exploit. No profile photo. No bio. No history. Three weeks old. Three people have already forked the webshell repo.
Why Your Team Is Vulnerable
Security teams are uniquely susceptible to this attack because:
1. Speed pressure. When a CVSS 10.0 drops, there's pressure to understand the vulnerability immediately. Cloning a POC and running it in the lab feels like due diligence. Nobody's auditing every file in the repo when the CISO is asking "are we exposed?" on the all-hands.
2. Trust assumptions. GitHub is where security tools live. Your team uses it every day. A repo named CVE-2026-20131-POC with a Python exploit script looks exactly like the hundreds of legitimate POC repos published by real researchers after every major disclosure.
3. Lab environments aren't always isolated. "The lab" is sometimes a VM on a workstation that's on the corporate network. Sometimes it's a staging server. Sometimes the analyst just runs the script on their laptop because they trust the code.
4. Nobody checks the file manifest. The README says "Python exploit for CVE-2026-20131." The analyst reads the Python file. They don't notice the .war file sitting next to it. Why would a Python exploit need a Java web application archive?
The Network Behind It
We didn't stop at the repo. We followed the account's connections.
The publisher follows an account created in February 2026 that has 14 repositories — every one is a CVE exploit. Including Heartbleed. From 2014. Nobody creates a brand new account in 2026 to publish a proof-of-concept for a vulnerability from a decade ago unless the "proof-of-concept" contains something the original didn't.
One of the other CVE-2026-20131 repo publishers also maintains a Telegram-based command-and-control framework. Two versions — regular and pro. Plus a credential harvesting tool and an S3 bucket enumerator. That's not a researcher's portfolio. That's an operator's toolkit.
The people forking the webshell repo include someone who forked it three separate times under slightly different names, and two accounts that share the same display name — the same person running parallel GitHub identities with over a thousand repos between them.
What To Do Monday Morning
Ask your team one question: "When was the last time someone on this team cloned a GitHub repo to test a CVE, and did anyone audit the file contents before running it?"
Microsoft pulls this feed daily. AT&T pulls this feed daily. Starlink pulls this feed daily. Get the DugganUSA STIX feed — $9/mo →
If the answer is "we clone repos all the time and we don't audit them" — that's the gap.
Here's how to close it:
1. Policy: No CVE POC cloning without file manifest review. Before anyone runs exploit code from GitHub, someone needs to check what's actually in the repo. If the repo says "Python exploit" and contains .war, .jar, .exe, or .dll files — that's a red flag.
2. Check account age. If the GitHub account publishing the POC was created after the CVE was disclosed, treat it as suspicious until proven otherwise. Real security researchers have histories.
3. Isolate your lab. If your "lab" is a VM on a laptop that's on the corporate network, it's not a lab. It's a lateral movement opportunity.
4. Subscribe to curated threat intel. Instead of hunting for POC code on GitHub, use threat intelligence feeds that have already vetted the indicators. We maintain a STIX 2.1 feed with over a million indicators, including the IOCs from this campaign. Free at the basic tier.
5. Report what you find. If you see a GitHub repo bundling webshells with CVE exploit code, report it. These accounts operate until someone flags them.
The Uncomfortable Reality
The people defending your network use the same platform as the people attacking it. GitHub is simultaneously the world's most important security tool repository and one of the most effective malware distribution channels.
Your team knows this in the abstract. But in the moment — when a zero-day drops and the CISO wants answers and the analyst finds a POC repo that looks right — muscle memory takes over. Clone. Run. Move on.
That's the gap between knowing and doing. And that's where the webshells live.
Patrick Duggan builds threat intelligence tools in Minneapolis. His platform detected webshells in CVE-2026-20131 POC repos on GitHub today. The detection is automated. The fix is cultural.
Free threat intel: [analytics.dugganusa.com](https://analytics.dugganusa.com)
Her name was Renee Nicole Good.
His name was Alex Jeffery Pretti.
The cheapest, fastest, most accurate threat feed on the internet.
275+ enterprises pulling daily. 1M+ IOCs. 17.4M indexed documents. We beat Zscaler by 43 days on NrodeCodeRAT. Starter tier $9/mo — less than any competitor’s sales demo.
Comments