Every security team has a version of this workflow: a new CVE drops, and before a patch is even tested, someone pulls a public proof-of-concept from GitHub to confirm whether the organisation is actually exploitable. That workflow is now a supply chain attack surface in its own right. Researchers at Sekoia and YesWeHack have identified a campaign distributing a remote access trojan called ChocoPoC through trojanized exploit repositories aimed squarely at the people running that exact workflow.

Hidden in the dependency, not the exploit

ChocoPoC’s distinguishing trick is where the malicious code actually lives. Rather than embedding a payload directly in the PoC script, where a security-conscious reviewer might spot it during a quick read-through, the attackers add a malicious Python package to the proof-of-concept’s dependency list. When the researcher installs requirements and runs the exploit as intended, the package executes automatically, decrypts embedded code, and triggers a downloader that retrieves the final ChocoPoC payload from a Mapbox dataset being abused as command-and-control infrastructure. The exploit code itself can look entirely legitimate, because the compromise happens one layer removed from where anyone is looking.

Real CVEs, real targets, deliberately chosen

Sekoia has counted at least seven repositories in this campaign, each impersonating a working exploit for a genuine, recently disclosed vulnerability: FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Check Point VPN, and a Joomla page builder component are among the products named. These are not obscure targets. They are exactly the kind of edge and perimeter infrastructure that European security teams have spent much of 2026 racing to patch, which means the audience most motivated to grab a PoC and test it is also the audience this campaign is built for. Once installed, ChocoPoC operates as a persistent Python-based RAT capable of harvesting browser credentials, exfiltrating files, and executing arbitrary commands on the researcher’s machine.

The trust assumption this breaks

Security research has always run on a baseline assumption that a PoC repository from a known contributor, with a plausible commit history and a working demonstration, is safe enough to run in an isolated environment. ChocoPoC does not need that assumption to be false everywhere, only true often enough that a busy engineer skips the sandbox on a Friday afternoon because the CVE is urgent and the fix needs verifying before the weekend. The same institutional pressure that makes rapid PoC testing valuable, speed, is precisely what this campaign is built to exploit.

What we recommend

• Never run a public proof-of-concept exploit, however credible the source, outside an isolated, disposable environment with no access to credentials or internal networks
• Review the full dependency tree of any PoC before execution, not just the top-level script, since this campaign specifically hides its payload in a secondary package
• Pin and audit PyPI and npm dependencies pulled in by internal tooling and research scripts, applying the same supply chain scrutiny your organisation already applies to production code
• Maintain a dedicated, network-isolated research sandbox for vulnerability verification so testing urgency never becomes a reason to skip containment
• Brief your security and DevOps teams specifically on this campaign, since the targets and delivery method are new enough that standard phishing awareness training will not cover it

If your organisation needs a safe, isolated environment for vulnerability testing, a review of how your team handles third-party proof-of-concept code, or a broader audit of dependency supply chain risk, contact Excello Digital. We help European engineering and security teams verify exposure without becoming the next victim of the research process itself.