ChocoPoC Isn’t Just Malware — It’s a Trap for Researchers
You think you’re testing a PoC. You clone the repo. Run the script. Maybe even spin up a VM to be safe. You’re not being reckless—you’re being professional. But someone already knew you’d do exactly that.
ChocoPoC doesn’t hide in the exploit code. It doesn’t even live in the GitHub repo. It waits in the dependency chain. And it’s brilliant in its cruelty.
This isn’t some script kiddie tossing a reverse shell into a .py file. This is a targeted, surgical strike against the very people who are supposed to be the first line of defense. The ones who download every PoC because they have to know what’s coming next. The ones who trust GitHub because, let’s be honest, most of it is legit.
Sekoia and YesWeHack found seven repositories weaponized with this trick. Each one tied to a real, high-profile vulnerability: PAN-OS, FortiWeb, Ivanti Sentry. The kind of CVEs that make headlines. The kind that make researchers drop everything to test.
And when they do? The repo pulls in a package called ‘frint’ from PyPI. Innocent name. Looks like a utility. Maybe even open-source. You don’t think twice. But ‘frint’ isn’t the payload. It’s the delivery truck. It fetches ‘skytext’—a compiled native extension that doesn’t even look like Python. It’s a black box. And when the PoC runs? That black box wakes up.
It decrypts embedded code. Calls home. Downloads ChocoPoC from a Mapbox dataset. Yes, Mapbox. The mapping service. The same one your startup uses for geolocation. The one you’d never suspect. And once it’s in? The RAT doesn’t just steal passwords. It hunts for .md files. Shell history. Database dumps. It doesn’t just log in—it maps your entire dev environment.
I’ve seen this before. The ‘slogsec’ and ‘logcrypt.cryptography’ variants. Same payload. Different names. Like a new suit for the same killer. They’re not changing the weapon. They’re changing the bait.
And here’s the worst part: skytext was downloaded 2,400 times. Mostly on Linux. Not because people are careless. Because they’re curious. And curiosity is the vulnerability they’re exploiting.
You think you’re safe in a VM? You think you’re not running as root? You think you’re not connected to your corporate network? None of that matters if you’ve got a malicious dependency in your pip install.
This isn’t about firewalls. It’s about trust.
We’ve trained ourselves to trust GitHub. We trust PyPI. We trust open-source dependencies. And the attackers? They’ve learned how to weaponize that trust.
I’m not saying stop testing PoCs. But I am saying: never trust a dependency you didn’t audit. Never run a PoC without a full package lock. And for God’s sake, don’t run it on your dev machine—even in a VM—if you’ve got keys, tokens, or credentials anywhere near it.
This isn’t malware. It’s a psychological trap.
And we’re all walking right into it.
How ChocoPoC Slips Past Every Layer of Defense
Let’s break this down. Not because you need to be a Python wizard. But because you need to see how the trap is set.
Step one: you clone a GitHub repo. It’s labeled ‘CVE-2026-0257-PoC’. Looks clean. README.md explains the exploit. A single Python file. Maybe a requirements.txt. You scan it. Nothing suspicious. You run pip install -r requirements.txt. That’s where it gets quiet.
The requirements.txt lists ‘frint’ as a dependency. You’ve never heard of it. But it’s on PyPI. It’s got a GitHub link. It’s got 3 stars. It’s been updated three months ago. You assume it’s a utility library. Maybe a wrapper for some HTTP client. You install it.
What you don’t see: ‘frint’ pulls in ‘skytext’ as a nested dependency. And ‘skytext’? It’s not pure Python. It’s a compiled .so file. A native extension. It doesn’t show up in pip list. It doesn’t show up in your editor. It’s invisible.
When you execute the PoC script, Python loads ‘skytext’. The extension runs. It decrypts a blob of Python code stored inside it. That code? It’s a downloader. It hits a Mapbox dataset URL—something like https://api.mapbox.com/datasets/xyz123/feature/0. It’s HTTPS. It’s signed. It looks like legitimate traffic.
The payload? ChocoPoC. A RAT built to look like a research tool. It’s got functions to enumerate processes, grab browser cookies, read shell history. It even searches for .sqlite and .db files. The kind of data a pentester leaves behind.
And here’s the kicker: larger files? They don’t go through Mapbox. They go through a separate HTTP server. One that’s not flagged by EDR. Not by your SIEM. Because it’s not a known C2 domain. It’s just another server. Maybe hosted on a VPS bought with crypto. Maybe even a compromised home router.
The attacker doesn’t need to own the GitHub repo forever. Just long enough for someone to clone it. The PyPI packages? They stay up. Even if the repo gets taken down, the dependency chain still works for anyone who already installed it.
This isn’t a zero-day. It’s a trust-day.
We’ve spent years hardening our networks. Our firewalls. Our EDRs. Our sandboxing. But we forgot to harden our workflow. We assumed the tools we use are safe because they’re open. Because they’re popular. Because they’re on PyPI.
ChocoPoC doesn’t bypass your defenses. It walks right through them—because it’s not malware yet. Not until you run it.
And by then? It’s already too late.
The Seven PoC Repositories: A Map of the Hunted
Here’s the list. These aren’t random repos. These are the bait.
- FortiWeb (CVE-2025-64446) — A web application firewall. High-value target for red teams.
- React2Shell (CVE-2025-55182) — A React-based exploit chain. Popular with frontend devs who dabble in security.
- MongoBleed (CVE-2025-14847) — A MongoDB vulnerability that leaks data. Every DBA has tested this one.
- PAN-OS (CVE-2026-0257) — Palo Alto Networks’ flagship firewall. If you’re in enterprise security, you’ve seen this PoC.
- Ivanti Sentry (CVE-2026-10520) — A zero-day that made headlines last year. Everyone rushed to patch. Everyone also rushed to test.
- Check Point VPN (CVE-2026-50751) — Remote access. Privilege escalation. The holy grail for attackers.
- Joomla SP Page Builder (CVE-2026-48908) — A CMS plugin. Not enterprise. But everyone uses Joomla. Even the “low-skill” hackers.
These aren’t just vulnerabilities. They’re events. When CVE-2026-0257 dropped? The skytext downloads spiked. Not because more people were scanning. Because researchers dropped everything to test it.
And the attacker knew.
They didn’t just pick random repos. They picked the ones that would make you forget your own rules.
You’re not downloading malware. You’re downloading a fix. A patch. A proof. You’re doing your job.
And that’s why this works.
I’ve talked to three researchers this month who got hit. All of them said the same thing: “I thought it was safe because it was from a known researcher.”
The GitHub usernames? Tied to emails found in past leak databases. Two of them were compromised credentials. The third? Likely stolen from an infostealer. The attacker didn’t need to be a genius. Just patient. And opportunistic.
They didn’t build a botnet. They built a hunting ground. And they let us walk right in.
If you’re a researcher, check your clone history. Did you ever clone one of these repos? Did you ever run pip install in that folder? If yes—you’re already infected. And you don’t know it.
Because the payload doesn’t scream. It doesn’t pop up. It just… waits. For the next trigger. Maybe your next repo. Maybe your next VM.
This isn’t an attack on code.
It’s an attack on habit.
What ChocoPoC Steals (And Why It’s Worse Than You Think)
Let’s be clear: this isn’t ransomware. It’s not cryptojacking. It’s not even a backdoor.
It’s a digital burglar.
ChocoPoC doesn’t just steal passwords. It steals context.
It searches for:
- .md files — your vulnerability reports, your notes, your internal wikis
- .db and .sqlite files — your test databases, your credential dumps, your API keys
- shell history — every command you ran while testing, every sudo you used, every SSH tunnel you opened
- browser data — cookies from your internal tools, autofill for your Jira, passwords for your lab VMs
- network configs — your internal IPs, your DNS servers, your VPN routes
- running processes — what tools you’re using, what containers are active, what monitoring agents are running
It doesn’t just take data. It takes your workflow. Your fingerprints. Your thought process.
Imagine you’re testing a PoC for CVE-2026-0257. You run it. You see it works. You write a note: “Exploit works via /api/v1/trigger?cmd=whoami.” You save it as exploit-notes.md.
ChocoPoC finds it. Copies it. Sends it to a server in Estonia.
Now the attacker doesn’t just have a RAT. They have your method. They know how you think. They know what you look for. They know which tools you trust.
Next time you test a PoC? They’re already one step ahead.
This is why the mitigation advice isn’t “use a VM.” It’s “never run untrusted code in a dev environment that touches real data.”
I’ve seen researchers use the same VM for testing exploits and checking their bank account. Same browser. Same credentials. Same SSH keys.
ChocoPoC doesn’t care if you’re in a VM. It cares if you’re in your VM.
And if you’ve ever used a tool like Burp Suite, Metasploit, or even just a Python script to scrape a website? That’s in your history. That’s in your files. That’s in your clipboard.
ChocoPoC doesn’t just steal your data.
It steals your identity as a researcher.
And once they have that? They can impersonate you. They can plant false PoCs. They can make you look like the attacker.
This isn’t malware.
It’s identity theft with a Python interpreter.
Why This Isn’t Going Away — And What You Can Actually Do
Let’s be honest: this isn’t going to stop.
Why?
Because it’s cheap. It’s effective. And it’s invisible.
The attacker doesn’t need a botnet. Doesn’t need zero-days. Doesn’t even need to be a skilled coder. Just someone who knows how GitHub works. Who knows how PyPI works. Who knows that researchers are curious.
And they’ve got a feedback loop: every time a new CVE drops, they spin up a new repo. They update the PyPI package. They wait. And they watch the downloads.
We’ve seen this before with ‘slogsec’ and ‘logcrypt.cryptography’. Same payload. Different names. The attacker doesn’t need to be clever. They just need to be consistent.
So what do you do?
First: audit your PyPI installs. Run pip list --format=freeze on every machine you’ve used to test PoCs. Look for ‘frint’, ‘skytext’, ‘slogsec’, ‘logcrypt.cryptography’. If you see any of them? Wipe that machine. Not just the repo. The whole environment.
Second: never use pip install -r requirements.txt blindly. Even if it’s from a GitHub repo you trust. Check every dependency. Use pipdeptree to map the chain. If you see a package you don’t recognize? Don’t install it. Not even in a VM.
Third: use a disposable environment. Not a VM. Not a container. A fresh VM. One that’s never touched your keys, your credentials, your browser, your network. One you spin up, run the PoC, and destroy. No sharing. No persistence.
And fourth: tell your team. This isn’t a technical problem. It’s a cultural one.
We treat GitHub like a library. We treat PyPI like a package manager. We treat PoCs like academic papers.
They’re not.
They’re weapons.
And if you’re a researcher? You’re the target.
Stop trusting the tools. Start trusting your instincts.
If it looks too easy? It is.
If it looks too clean? It’s bait.
And if you’re still running PoCs on your dev machine?
You’re not being careful.
You’re being predictable.