ChocoPoC: The Fake Exploit Repos Turning Bug Hunters Into Victims
A Python-based infostealer is hiding inside GitHub proof-of-concept code marketed to vulnerability researchers, siphoning credentials, cookies, and files before dropping a remote shell.
Key points
- ChocoPoC hides inside fake GitHub proof-of-concept repositories timed to fresh CVE disclosures.
- The malware lifts saved browser credentials, session cookies, and local files, then opens a reverse shell.
- Researchers are targeted precisely because their workstations hold client data, cloud tokens, and private tooling.
- No breach notification has been filed; regulatory obligations fall to employers if client data was on the compromised host.
- Any researcher who ran an untrusted PoC recently should rotate credentials and reissue SSH keys from a clean device.
What is ChocoPoC and how does it spread?
ChocoPoC is a Python-based remote-access trojan circulating inside GitHub repositories that pose as working exploits for recently disclosed CVEs. We first covered it on 1 July 2026, when a cluster of trojanized PoC repos was already pushing the payload to the researchers who went looking for them. The operators stage repositories timed to fresh vulnerability disclosures, banking on urgency to short-circuit code review.
Run the Python file and the payload sweeps saved browser credentials, session cookies, and local files, then opens a reverse shell to the attacker. At that point the operator is inside a workstation that often holds client engagement data, cloud tokens, and SSH keys.
Why researchers are the target
PoC repos have long been a soft target because the audience self-selects for high value. A researcher chasing a hot CVE will clone first and audit second. ChocoPoC's operators understand that workflow.
The practical exposure on a compromised host is broad: browser-stored logins for GitHub, cloud consoles, and email; authenticated session cookies that bypass MFA; SSH keys and .env files in a projects directory; credentials cached by CLI tools like gh, aws, or az. If the machine is also used for client work, that's a downstream incident for the employer, not just a personal one. It's a two-for-one: the researcher's credentials, and a foothold into whoever pays them.
Should you worry about regulatory consequences?
No breach notification has been filed, and the victim pool is individual researchers rather than custodians of consumer data. If a compromised workstation held client data covered by GDPR, HIPAA, or state breach-notification statutes, the obligations flow to the employer, not to GitHub.
What affected researchers should do
Assume any host that executed an untrusted PoC in recent weeks is compromised. Rotate browser-stored passwords, revoke active sessions, and reissue SSH keys and cloud tokens from a clean device.
Move PoC triage into disposable VMs or containers with no host filesystem mounts, no shared clipboard, and no logged-in browser profiles. Snapshot, detonate, revert. Pin PoC testing to a dedicated GitHub account with no access to real work, use a browser profile that has never authenticated to anything, and read the Python before you run it.
