Stop Running GitHub PoCs on Your Workstation. You’re Being Hunted.

When a new critical CVE drops, we race to be the first to verify it. Fueled by caffeine and the pressure of a ticking clock, we scour GitHub for a Proof of Concept (PoC) to see how the exploit works. We find a repo with a few stars, skim the Python script, see nothing "obvious," and hit run.

In 2026, that speed is exactly what is going to get your entire enterprise compromised.

The recent "ChocoPoC" campaign isn't just another malware report; it is a professional wake-up call. It proves that attackers have stopped targeting the software—they are now targeting the defender’s process.

The Death of the "Quick Code Review"

The old-school way of staying safe was to "read the code before you run it." But the ChocoPoC campaign has officially made the "eye-ball test" obsolete.

Researchers from YesWeHack and Sekoia recently deconstructed a series of repositories claiming to exploit fresh CVEs. To the naked eye, the exploit script looked perfectly legitimate.

The malware wasn't in the script. It was in the dependencies.
By hiding malicious code (nicknamed ChocoPoC) inside a Python package listed in the requirements.txt, the attackers bypassed the human reviewer. The moment you ran the script, the dependency executed quietly in the background, exfiltrating your saved passwords, browser cookies, and session tokens before handing the attacker a shell on your machine.

If you are only reviewing the .py file and not the entire supply chain of the repository, you aren't doing a security review. You’re just gambling.

Why Researchers are the "Golden Ticket"

Why would an attacker spend time building fake exploits instead of just phishing a CEO? Because a security researcher's laptop is a Golden Ticket.

A single infected workstation in a SOC or DevSecOps team provides:

1. Privileged Access: You likely have active session cookies for cloud consoles (AWS/Azure) or internal GitLab instances.
2. Source Code: Access to the "crown jewels" of your organization.
3. The Ultimate Cloak: Traffic coming from a security pro’s machine is rarely questioned by automated alerts.

Attackers aren't looking for random victims anymore. They are looking for the keys to the castle, and we are handing them over in our rush to be "first."

The Professional Standard: Building a "Zero-Trust" Workflow

If you are still running untrusted code on your bare-metal workstation because you "don't have time" to spin up a VM, you are a liability to your team.

Here is the 2026 baseline for running any community PoC:

1. Containment is the only Control: Assume "eyeballing" code will fail. Use a disposable, air-gapped Virtual Machine or a strictly isolated sandbox (like Tenzir or a dedicated lab VPC).
2. Audit the Supply Chain: Before running pip install -r requirements.txt, verify every package on PyPI. Look for typosquatted names (e.g., requests-auth-lib vs request-auth-lib).
3. The 72-Hour Rule: The window immediately following a CVE disclosure is the "Danger Zone." This is when fake PoCs are seeded. If a repo is less than 3 days old and has 100+ stars, it’s a red flag. Stars are cheap; reputation is earned.

The Hard Truth

This campaign is a neat illustration of a trend that will define this decade: attackers weaponizing the "defender's rush."

We need to stop rewarding "fast and loud" research and start rewarding "contained and verified" research. The fix isn't paranoia—it’s building a workflow where running malicious code is cheap and inconsequential because it’s trapped in a sandbox.

The Question for the Community:

How many of you can honestly say you haven't run a PoC on your host machine in the last 30 days? Are we actually sandboxing our research, or are we just hoping the "Star" count on GitHub means the code is safe?

Let’s be honest in the comments—how does your team handle the "rush" of a new CVE?