Skimmers served from domains registered one character away from a CDN you already trust, so the host survives the glance that a review gives it.
Published 4 June 2026
Updated 24 August 2026
Most skimmer domains look like nothing in particular. They are registered a week before the campaign, serve the payload for a few days, and mean nothing to anybody reading them. That is fine for the attacker, because nobody usually reads them.
This family is built for the case where somebody does. Every host in it is registered a character or a word away from something a developer already trusts: a CDN, a package registry, a JavaScript library. If the domain appears in a script inventory, an allowlist, or a CSP violation report, it reads as infrastructure that belongs.
The largest group targets jsDelivr, the public CDN that serves npm and GitHub packages. The real
service is on jsdelivr.net. We track skimmer hosts on three other endings, each with both the apex
and a cdn. label registered, because at the time they were added our matching was exact-hostname
and an attacker who moved between the two would otherwise have slipped one past us.
Alongside those sit a package-registry lookalike and a library lookalike. packages.npm.org reads
like an official npm host, and is not one. static5-jquery.com borrows the name of the most widely
deployed JavaScript library there has ever been, on a domain jQuery has nothing to do with.
An allowlist review is somebody scanning a list for something that looks wrong. That works when the attacker's domain is random, and it fails completely here, because the whole point of the name is to survive exactly that scan.
It gets worse when a policy is built the common way. If you run a CSP in report-only mode, collect what the browser reports, and allow what you see, then a skimmer already running on the page is reported like everything else. Somebody reviews the list, sees what looks like a CDN, and allows it. The policy that was supposed to stop the skimmer now permits it, in writing, with a review behind it.
The question that works is not whether a host looks legitimate but whether anybody chose it. You know which CDNs you decided to use. Everything else on the page arrived some other way, and that is true whether or not the name is convincing.
That is why a script inventory with a reason attached to each entry is worth more than an allowlist
on its own. jsdelivr.net has a reason: somebody picked it, for a library, on a date. jsdelivr.info
has no reason behind it, and the absence is the finding.
Compare the hosts in your reports against the CDNs you actually chose, character by character rather than at a glance. The differences are small on purpose: a different top-level domain, an extra word, a digit in the middle of a library name.
Two patterns are worth flagging immediately. A CDN host you cannot trace to a decision is one to investigate whatever it is called. And a host that appears alongside a CDN you do use, serving something similar, is the shape this family takes: the real one keeps working, so nothing breaks, and the extra one is easy to miss.
These are the entries in our threat intelligence feed for this campaign, shown exactly as we match them. An entry starting *. covers that domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do that when the attacker registered the domain themselves.
The feed changes as we go. We add hosts when they show up and pull them out when the evidence no longer holds, so this is what we're matching today rather than a permanent record.
*.static5-jquery.comcdn.jsdelivr.bizcdn.jsdelivr.infocnd-lin-2026.comjsdelivr.atjsdelivr.bizjsdelivr.infopackages.npm.orgObserved in Report URI report telemetry. We classify these on what we saw them doing, not on any claim about who runs them.
We flag these hosts in your own reports automatically, so you hear about it from us instead of from your customers.
← All threat intelligence research · Read this page as Markdown