This Morning We Missed ChocoPoC. This Afternoon We Built the Detector. This Evening It Found a Live Campaign Node GitHub Hadn't Taken Down.
- Patrick Duggan
- 17 hours ago
- 4 min read
Twelve hours ago we published an honest miss: the ChocoPoC campaign — fake proof-of-concept exploit repositories that pull one poisoned PyPI dependency to compromise the security researchers who run them — had slipped both our defenses, and we said so plainly. This post is what happened next, in one working day, and it ends with a live malicious account still serving payloads that our brand-new detector found and GitHub's takedown had missed.
What we built between the two posts
The reason ChocoPoC slipped us was structural, and naming it pointed straight at the fix. Our package guardrail was binary — a dependency was either on our known-malicious deny-list or it was waved through — so a fresh, low-volume, targeted package that no feed had named yet came back "allow." And our GitHub hunt scored repositories by their names and descriptions but never looked at what a repository actually pulls in. Two blind spots, one shape.
So we built a name-independent reputation primitive. It does not care what a package is called. It asks the registry three questions: does this package still exist, how old is it, and does anyone actually download it. A package that was removed from PyPI, or was published last week, or gets a handful of downloads a month, is suspicious no matter how innocent its name — and, critically, the download history survives even after the malicious package is pulled from the registry. We wired that into the guardrail so unknown packages now get scored instead of waved through, and into the GitHub hunt so it now inspects a repository's dependency manifests, not just its name. Held-out testing was clean: every ChocoPoC package flagged, every established package like requests or numpy passed at zero risk.
Then we pointed it at the campaign itself.
The live one
The ChocoPoC disclosure named three GitHub accounts running fake-PoC repositories. Two of them — bolubey and ogenich — have already been suspended. The third, lincemorado97, is still live. We ran its repositories through the new detector, and all three flagged:
Its CVE-2025-64446_CVE-2025-58034 repo and its CVE-2025-14847 repo both scored block — each pulls the malicious PyPI package slogsec, which our detector flags at risk 80 because it has been removed from the registry and shows only 188 downloads a month. Its CVE-2025-55182_CVE-2025-66478 repo scored review on the same dependency. One of the repos also references a package called zlib pulled from PyPI, which is a tell in itself — real zlib is built into Python and is not a PyPI package, so a requirements file that installs zlib from PyPI is fetching either a typosquat or something that should not be there.
We then ran the obvious follow-up: which repositories on all of GitHub reference the malicious slogsec package. The answer was exactly three, and all three belong to lincemorado97. The campaign's other nodes are down; this account is the last live delivery surface for this payload, and it has been sitting there, unremediated, serving fake exploits to any researcher who searched for those CVEs.
What we did about it, tonight
Two things, immediately. First, protection: the three repository URLs are now indicators in our feed, so any customer pulling our blocklist blocks them, and the slogsec package was already added to our deny-list this morning. Second, reporting: we filed an abuse report with GitHub's security and abuse teams naming lincemorado97, the three repositories, the slogsec dependency, and the YesWeHack and Sekoia disclosure it belongs to. The account was live at the time of writing; by the time you read this, we hope it is not.
The honest part, because there is always one
We want to be precise about what did and did not work, because a detector that only ever gets described in its wins is a sales sheet. The thing that caught lincemorado97 is the behavioral reputation signal — existence, age, downloads. We also spent real effort on a vector-similarity approach, betting that the embedding space would cluster these malicious research-bait packages together for free. We quantified it, and it failed: the malicious-package embedding space is one undifferentiated blob, and the apparent signal we thought we saw turned out to be an artifact of the descriptions we had written ourselves. We threw that approach out. The primitive that shipped, and that caught a live campaign node on its first afternoon, is the boring one: ask the registry whether anyone has ever actually used this thing.
The indicators
Malicious PyPI package: slogsec (removed from registry; SHA-256 5abd45d6f4a1705dca55d882f017d4768888dce9ad99cea40b3da35c23de5cae). Live fake-PoC repositories, account lincemorado97: CVE-2025-64446_CVE-2025-58034, CVE-2025-14847, and CVE-2025-55182_CVE-2025-66478. If any of these repository names or the slogsec package appear in a clone, a virtualenv, a requirements file, or a pip cache on a research machine, treat that machine as compromised and rotate its credentials — the ChocoPoC payload harvests browser data, SSH keys, and shell history.
We hold this at 95 percent as always. We were not ahead of ChocoPoC, and we said so this morning. But the gap that let it through is closed now, in two places, and the first thing the fix did was find a live node of the very campaign that exposed the gap. The best answer to a miss is not an apology. It is a working detector and a receipt with a still-live target on it.
Primary research and campaign attribution: YesWeHack vulnerability-intelligence team and Sekoia threat detection & research, "ChocoPoCs: vulnerability researchers targeted by trojanised exploits," 2026-07-01. Live-node detection, indicators, and abuse report: DugganUSA, 2026-07-13.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.