Skip to content
Supply ChainVulnerability ResearchCVEopen-source-security

Don't clone the exploit: how ChocoPoC turned security researchers into targets

3 min read
Share

Security researchers are trained to verify claims with proof. When a new CVE drops, the natural next step is to find a proof-of-concept exploit, clone it, and run it against a test environment. That workflow is now a documented attack surface.

Sekoia and YesWeHack published joint research on July 1, 2026, documenting ChocoPoC: a Python-based remote access trojan distributed through GitHub repositories designed to look like legitimate proof-of-concept exploit code. Seven repositories were confirmed active. The infrastructure was still live when the report published.

How ChocoPoC gets onto your machine

ChocoPoC does not hide the malware directly inside the exploit file. That is where most people check. Instead, the attack lives in the dependency tree.

When you clone one of the malicious repositories and install its dependencies, a trojanized package named 'frint' gets pulled automatically. During installation, 'frint' fetches a second package called 'skytext', which contains a compiled native Python extension. When the PoC executes, the extension runs and decrypts additional embedded Python code. That code downloads the final payload, ChocoPoC, from a dataset hosted on Mapbox, a legitimate mapping service.

The C2 channel is designed to blend in. ChocoPoC resolves its command-and-control address over DNS-over-HTTPS and uses domain fronting so all traffic looks like normal Mapbox API calls. There is no obvious malicious domain to block at the firewall level.

What the malware does

Once running, ChocoPoC pulls saved passwords, cookies, autofill data, and browsing history from Chrome, Brave, Edge, and Firefox. It exfiltrates text files, local databases, shell history, network configuration, and the list of running processes. It accepts and executes arbitrary commands from the operator. This is exactly the data profile that allows an attacker to pivot from a researcher's workstation into the research targets, internal network resources, and any accounts the researcher has credentials for.

The seven confirmed repositories

Sekoia confirmed trojanized repositories presenting exploits for CVE-2025-64446 (FortiWeb), CVE-2025-55182 (React2Shell), CVE-2025-14847 (MongoBleed), CVE-2026-0257 (PAN-OS GlobalProtect), CVE-2026-10520 (Ivanti Sentry), CVE-2026-50751 (Check Point VPN), and CVE-2026-48908 (Joomla SP Page Builder).

That last one, CVE-2026-48908, was added to the CISA Known Exploited Vulnerabilities catalog on July 7, 2026. ChocoPoC was already using it as bait before CISA confirmed active exploitation.

What this means for your PoC hygiene

The ChocoPoC campaign targets a behavior that is otherwise rational and professional. Using public PoC code to verify vulnerability claims is standard practice. Making it safer requires treating public PoCs the same way you would treat any unreviewed third-party code:

  • Read the dependency list before you run anything. Look for packages you did not expect.
  • Check whether unexpected packages exist on PyPI under names that sound legitimate but have low download counts or recent registration dates.
  • Run PoC code in an isolated VM with no credentials, no browser profiles, and no network access beyond what the test actually requires.
  • Never run PoC code on a machine with access to internal resources, stored credentials, or any account that matters.

The fact that an attack specifically targets security researchers means the technical sophistication of the target is not a reliable defense. Awareness and process discipline are.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you want to discuss PoC hygiene practices or threat-research workflows for your team.