Content Delivery Networks

A CDN is not just optimization infrastructure. It is the entity the runtime trusts to deliver code, content, and configuration into the rendering surface. The runtime resolves a URL, the CDN responds, the runtime executes the response. Whoever controls the CDN controls what the runtime executes. The runtime has no independent way to verify that response against what the application owner intended. CDNs sit at the highest aggregation depth of any single provider category in the deployed landscape, and that depth is what makes a CDN compromise consequential.

CDN-delivered content reaches Client Runtimes across the full platform landscape. Browsers are the most visible consumers because the web has the largest installed base of runtimes that render content on the client. CDNs also deliver JavaScript libraries, fonts, media, manifests, configuration, and increasingly model files into mobile applications through WebViews and native HTTP clients, into desktop shells that wrap a web runtime (Electron, Tauri), into developer IDEs and code editors, into AI chatbot interfaces, into smart-television and digital-signage runtimes, into vehicle infotainment systems, into IoT and operational technology (industrial control) dashboards, into AR/VR runtimes, into productivity-tool extension hosts, and into game and user-generated-content interactive runtimes. The browser is where CDN compromise is most visible; it is not the boundary.

The real-world ATG event is a CDN case: the Funnull/Polyfill.io operation of 2024, in which a long-trusted CDN hosting polyfills, the small compatibility scripts a site loads so older browsers can run newer code, was acquired by Funnull, a China-linked CDN operator, and used to deliver selective malicious content to its dependent population. CDN compromise spans every provider route (account takeover, network-path hijack, ownership change, insider compromise, cyber exploitation), and the ownership-change route is most visible in the CDN class. The longer-arc adversarial lifecycle from acquisition to re-emergence has been most fully observed at the CDN level.

7.1: Why CDNs Sit Where They Sit

Client Runtimes fetch content from remote origin servers, the servers the application owner names as the source of that content, and cache it locally to save bandwidth. The origin server controls how long a cached copy may be reused, through response headers, and lifetimes of zero are common for content the application owner expects to update without forcing client redeployment; that setting requires the runtime to re-fetch on every load. Serving those repeated fetches quickly to users in every region means keeping copies of the content near them, which is what a CDN does. The entity that operates the CDN inherits the trust the application owner extends to the application's own infrastructure, because the CDN's URL is configured into the application as a delivery endpoint and the runtime treats responses from that endpoint as authentic.

Four conditions make that inheritance consequential.

• Origin-authority delegation: the CDN is granted authority to answer in place of the origin server, in the application owner's name. Domain configuration, contractual setup, and certificate issuance position the CDN as the entity the runtime resolves to when it calls the application's configured URL. The application owner does not deliver the content; the CDN does. The runtime cannot tell the difference and is not designed to.
• Implicit trust granting: the runtime treats CDN-delivered content as authoritative, with no verification mechanism in most cases. Subresource Integrity (SRI) exists in browsers for static script and style assets fetched from a known URL with a known hash, but most CDN content (dynamic responses, fonts, media, manifests, configuration, increasingly model files) sits outside SRI coverage even inside browsers. Outside browsers, SRI analogs are largely absent at scale across the non-browser Client Runtime landscape.
• Runtime delivery position: the CDN sits between the origin server and the rendering surface, in the network path the runtime traverses on every fetch. Whatever the CDN returns is what the runtime executes. There is no intermediate verification step that compares the response to what the application owner intended, and no economic alternative to that delivery position for content that has to reach the rendering surface at scale.
• Aggregation depth: a single CDN serves many Client Runtimes across many platforms simultaneously. Compromise at the CDN propagates to the full dependent population in one step. Aggregation depth is a multiplier; CDNs operate that multiplier at the highest end. Each condition exists at lower intensity in other provider categories. CDNs are where all four reach maximum intensity at once. Scale, trust, and position together are what make the class consequential, not the technology itself.

All four conditions operate cross-runtime, not only inside the browser. Origin-authority delegation works the same way wherever a runtime resolves a URL the application owner configured. Implicit trust granting becomes more pronounced outside the browser, where SRI and CSP analogs are largely absent. Runtime delivery position is a property of the network path; the consuming runtime does not change it. Aggregation depth is a property of the CDN's dependent population; it scales the same way regardless of which platforms that population spans. CDN compromise is therefore not browser-bound.

7.2: CDN Categories and the Trust Hierarchy

The CDN class is four trust models, not one. Application owners often collapse the relationship into a single idea, "we use a CDN", but the four CDN categories differ at the level of who is on the other end of the URL, what is contractually owed, and which routes in most apply.

Commercial CDNs. Cloudflare, Akamai, Fastly, AWS CloudFront, Google Cloud CDN, and Microsoft Azure Front Door operate on contractual relationships with the dependent applications, anchored by signed enterprise service-level agreements, identifiable corporate ownership, and named operational personnel. All five routes apply: account takeover, network-path hijack, ownership change through subsidiary acquisition, insider compromise, and cyber exploitation. Contractual structure constrains some routes more than others; it does not close any of them.

Open-source and community CDN services. cdnjs, jsDelivr, and unpkg deliver content without contractual relationship to the dependent applications that consume it; trust is inherited from the open-source library, the maintainer, or the operator's reputation, and ownership models vary. The routes that most apply are account takeover, insider compromise, ownership change (the Funnull/Polyfill.io pathway), and cyber exploitation. The lack of contractual structure does not predict less reliable operation; cdnjs, jsDelivr, and unpkg have served the ecosystem for more than a decade. It does change the recourse path after compromise.

Embedded script and asset hosts. Google Hosted Libraries, Google Fonts, Bunny Fonts, and Adobe Fonts operate as ecosystem services run by major platform companies. Trust is implicit in the platform brand: the dependent application owner trusts Google, Adobe, or Bunny by extension when consuming hosted libraries, fonts, or icons. Contractual structure varies, but the operative trust mechanism is brand reputation, not contract. The routes apply much as they do for commercial CDNs; the consequence is broader because a single compromise reaches every property that embeds the host's URL, regardless of whether the embedding owner has a direct relationship with the host.

Specialized CDN-like infrastructure. Image and media CDNs, video streaming networks, edge compute platforms, networks that deliver mobile over-the-air bundles, code updates an installed app pulls straight from a server without going back through the app store (CodePush, Capgo, Expo, vehicle infotainment OTA services), AI model and adapter distribution networks (Hugging Face, model and prompt registries for inference services), and AR/VR asset distribution platforms each operate variations on the CDN pattern with different content types. The trust models split along content-type lines: media CDNs lean closer to commercial-CDN structure; over-the-air services can replace application code on the next launch, which CDNs serving script assets cannot; AI model distribution ships model weights and adapter files, content types that traditional CDNs never carried. The reach is into Client Runtime platforms beyond the browser: mobile applications consuming OTA bundles, AR/VR runtimes loading scenes, smart-TV systems pulling apps and media, vehicle infotainment systems updating maps and software, AI runtime hosts pulling model files.

Commercial CDNs have contractual structure and named ownership, which constrains some routes without closing others. An acquirer can buy a subsidiary that holds a delivery position. A certificate authority can issue for a domain it should not. An operator's publishing credentials can be stolen. Contractual formality decides who answers afterward; it does not decide whether a route is open. Open-source community CDNs have less formal trust structure; they have served the ecosystem for more than a decade and have been compromised when ownership of a long-trusted domain changed hands. Embedded script and asset hosts carry major-platform brand trust; brand trust does not narrow the routes in the way contractual structure does. Specialized CDN-like infrastructure delivers into Client Runtime platforms with less developed defensive primitives than browsers; the consuming runtime matters as much as the delivery operator.

The trust hierarchy is not a clean ranking. The CDN dependency an application carries is a different security problem in each of the four categories.

7.3: The CDN Acquisition Attack Model

Acquire, establish trust, weaponize, activate: each step is the precondition for the next. Acquisition without subsequent establishment of trust risks early detection; weaponization without prior trust-building exposes the operation; activation requires weaponization already in place. The trust that activation exploits is the trust the establishment phase built. The pattern is not a description of how a CDN attack might unfold; it is the description of how a CDN attack has to unfold to remain undetected long enough to matter.

• Acquire: the adversary takes ownership or operational control of the CDN. Commercial acquisition purchases the entity outright, often through layered ownership that obscures the buyer's identity. Influence operates through board placement, controlling-stake investment, or partnership arrangements that give the adversary effective decision authority without title transfer. Coercion targets the operator personally through financial pressure, regulatory exposure, family threats, or extortion. Cyber exploitation compromises the CDN's infrastructure or administrative credentials and operates the position covertly without an ownership event.
• Establish trust: the CDN operates legitimately under the new ownership. The same content serves the dependent applications. Performance, reliability, and content fidelity all hold. Existing dependents detect no change; new dependents onboard normally because the CDN looks indistinguishable from a legitimate operator. The phase often runs months to years; the longer it runs, the larger the dependent population grows and the deeper the trust extends, both of which the adversary harvests at activation.
• Weaponize: adversarial capability enters the delivery pipeline. The implementation is often selective: only requests from particular geographic regions, only requests from particular user-agents, only requests during particular hours, only specific content types, only specific dependent applications. Selectivity delays detection because the malicious content does not appear in most normal observation samples. Standard CDN telemetry, security testing, and content-integrity checks miss content that activates conditionally.
• Activate: activation delivers the malicious content. Triggers can be specific events (a known target visiting a specific URL), target conditions (an application loading on a specific platform or in a specific geographic region), or simply a scheduled time. Activation is the first step that produces detectable adversarial behavior; everything before it has been routine CDN operation. The detection window opens at activation; by that point the dependent population may include applications, properties, and devices that onboarded entirely under adversarial ownership. Funnull/Polyfill.io of 2024 walks the model end to end. A long-trusted polyfill-hosting CDN was acquired outright from its original operator. The new ownership operated the CDN under the existing domain and against existing dependent expectations for an extended period. Selective adversarial capability entered the delivery pipeline, targeting particular dependent properties and particular conditions. Activation redirected visitors and delivered malicious code to a subset of dependent applications, surfacing through researcher detection rather than CDN-side observation. By detection, the dependent population had reportedly grown to more than one hundred thousand sites.

The four-step pattern has the shape the Two-Stage Attack has at the resource level: the CDN's delivery URL operates legitimately for the period the adversary needs to build position, then delivers compromised content to the runtime that has already extended trust. Aggregation depth scales what activation reaches. A compromised analytics script reaches the sites and apps that embed that script. A compromised CDN reaches every dependent application at once.

7.4: CDN as Risk Multiplier

The reach a CDN compromise produces varies by CDN across orders of magnitude. Aggregation depth is uniformly high across the CDN class, but dependent populations vary by category. Reading any specific compromise requires reading which profile applies.

• Major commercial CDNs: each serves hundreds of thousands to millions of dependent sites. Cloudflare and Akamai together front large fractions of the public web; Fastly, AWS CloudFront, Google Cloud CDN, and Microsoft Azure Front Door each serve significant portions of the high-traffic enterprise application population.
• Open-source and community CDN services: cdnjs, jsDelivr, and unpkg each deliver to dependent populations measured in the millions of sites. Together they serve a meaningful share of the JavaScript ecosystem at runtime.
• Embedded script and asset hosts: Google Hosted Libraries, Google Fonts, Bunny Fonts, and Adobe Fonts reach billions of page loads daily, embedded across a population of properties that includes most of the consumer-facing web.
• Specialized CDN-like infrastructure: delivers into deployment populations measured in devices, not sites. Mobile OTA bundle services reach the installed bases of dependent mobile applications; AI model distribution networks reach the applications that load model files in order to run them; AR/VR asset distribution reaches the runtimes and devices that render scenes from those assets; smart-TV, vehicle, and IoT delivery networks reach their respective device populations. Every figure is a count of what a single compromise reaches in one step. Cross-platform reach compounds the per-CDN counts. The same CDN often serves into multiple Client Runtime platforms simultaneously: a CDN that delivers JavaScript libraries to web properties also delivers them to mobile applications consuming them through WebViews, to Electron and Tauri shells that embed them as dependencies, to smart-TV runtimes loading them as app framework code, and to AI chatbot interfaces and developer IDEs that pull them at runtime. A single compromise reaches every dependent application that consumes the compromised content, across every Client Runtime platform that consumes it, in one step. The risk multiplier is not browser-bound; the multiplier compounds wherever the CDN's content is consumed.

A sophisticated adversary with CDN-level position chooses how to activate. Targeted activation runs against a narrow population (a specific dependent application, a specific geographic region, a specific user-agent or device type, a specific time window) and preserves stealth at the cost of impact. Broad activation runs against the full dependent population at once and maximizes impact at the cost of detection time. The choice depends on the operation's goal: targeted activation suits influence-and-control operations against specific entities; broad activation suits campaigns where reach itself is the objective.

The risk multiplier and the operational discretion together make the CDN class consequential. Reach is the technical property; discretion is the operational choice. CDN-class compromises can be precise enough to evade detection through the dormancy phase and broad enough to determine outcomes for an entire dependent population. Other supply-chain compromises trade stealth for scale. CDN compromise does not.

7.5: Lying in Wait

Mature adversarial CDN operations sit inside a longer lifecycle: pre-positioning, dormancy, activation, persistence tradecraft, re-emergence. The lifecycle pattern is familiar from the broader supply-chain adversary literature. What is ATG-distinctive is concentrated in the dormancy phase, Lying in Wait.

Lying in Wait, dormancy as detection-defeat: this is the most important phase of the CDN lifecycle. A dormant adversarial capability sits pre-positioned within a genuinely legitimate, trusted dependency. The adversary acquires the position, then operates the CDN legitimately for months or years, serving exactly the content the dependent applications expect. The dwell phase produces no detectable adversarial signature; standard CDN telemetry, security testing, content-integrity verification, and behavioral monitoring all return normal results because the CDN is in fact operating normally, which is why nothing fires (during the dwell there is no malicious file to find). The capability lies in wait, and what conceals it is not a hidden piece of code but the working dependency around it. The only detectable event is activation, and by then the dependent population has often grown materially under the new ownership. Defensive postures built around active-attack signatures miss the dwell window entirely. The threat is present but inert. There is no event to detect, often not even the strike itself. This is why CDN-class compromises are difficult to prevent and are frequently discovered weeks or months after activation begins.

The host of a Lying-in-Wait capability is not faking legitimacy. It is legitimate: a real business, with real revenue and a real market, adversarial-controlled at the ownership layer and weaponized only in the rare instance. That genuine legitimacy is why nothing fires during the dwell. Three related terms are worth keeping apart: a shell exists only to obscure ownership; a front is a fake business or facade; a cover is a genuine business that is weaponized only rarely. A Lying-in-Wait capability is hosted by a cover. Separately, the persistence phase routes CDN infrastructure through hosting providers and jurisdictions that do not cooperate with takedown requests, law enforcement inquiries, or content-moderation demands. The mechanism is where the infrastructure is placed: the chosen hosting providers sit in jurisdictions that decline to honor cross-border enforcement actions, or that hold legal positions making compelled cooperation slow or unreliable. This routing is familiar from the broader supply-chain adversary literature. The ATG-relevant consequence is direct: detection of the malicious CDN does not necessarily lead to its removal, and compromised content can continue to deliver to the dependent population for an extended period after detection, sometimes indefinitely, while takedown procedures wind through unwilling intermediaries.

Re-emergence closes the lifecycle. After detection or takedown, the adversary cycles the asset through new hosting infrastructure, often under a new domain or rebranded operator identity, and resumes operation. The pattern is the CDN-level expression of Adversarial Asset Cycling, the broader ownership-opacity pattern. The dependent population the new asset acquires may overlap meaningfully with the population the original asset served, particularly when the cycling re-uses code patterns, naming conventions, or recognizable operator behavior.

Lying in Wait is what hides the operation. Non-cooperative hosting is what keeps the operation running after detection. Re-emergence is what brings the operation back under a new identity. The four-step model captures one event; the lifecycle captures the operator. Defenders who detect events without recognizing the operator will keep finding the same operator behind new events.

7.6: Typosquatted and Impersonating CDN Domains

The typosquatting and impersonation surface differs from the acquisition attack model. The acquisition attack uses the legitimate CDN: the same domain, the same publishing channel, the same trust relationship that has worked for the dependent population for years. Typosquatting and impersonation both substitute a different entity, and they arrive by different routes. Typosquatting registers the misspellings a developer might type or paste: cdnjs.cloudflare.com becomes cdnjs.cloudfare.com with a letter dropped, cdn.jsdelivr.net becomes cdn.jsdeliver.net with a letter inserted. Impersonation constructs a domain no one reaches by error, reusing the brand's own words (jsdelivr-cdn.example, googlefonts.example) or replacing a dot with a hyphen so the legitimate name still reads correctly at the front of the address (cdnjs.cloudflare-com.example). The substituted entity has no relationship to the legitimate CDN; the attack succeeds when the developer or the build pipeline references the wrong domain and the runtime fetches from it.

Defense is largely organizational. Developer awareness, code-review discipline, dependency declaration audits, and pre-deployment scanning of CDN domain references catch most typosquatting before the misreference reaches production. CSP allowlisting constrains which CDN domains the runtime is permitted to fetch from in browsers; this defense is browser-specific and covers static script and style sub-resources where SRI is not in use. Outside browsers, the equivalent defense is largely absent: most non-browser Client Runtimes lack CSP analogs, and the typosquatted domain reaches the runtime if the application owner has referenced it.

The pattern is well-documented in the broader phishing and supply-chain literature. What matters for ATG is not the pattern itself but that typosquatted domains enter the Client Runtime trust graph alongside legitimate CDN domains. The CDN domain trust graph carries two distinct attack surfaces: legitimate CDNs the application owner has chosen to depend on, and impersonating entities that have entered the graph through error or deception. The runtime treats both the same way at fetch time.