On any given day, roughly three out of every four websites tracked by W3Techs load jQuery — a dependency footprint no other piece of JavaScript on the internet can match. A significant share of those sites don't bundle the library; they pull it live from a public content delivery network such as code.jquery.com, cdnjs, jsDelivr, or Google Hosted Libraries, often alongside a chain of companion scripts like polyfills, plugins, and analytics tags loaded from the same trust boundary. That architecture has been the quiet backbone of the web for close to two decades. It has also, in the last few years, become one of the most consequential blind spots in front-end supply chain security.
Two incidents did more than any advisory to prove the point. In 2021, a researcher disclosed a remote code execution vulnerability in cdnjs' update pipeline that could have let an attacker tamper with files served to an estimated 12.7% of all websites on the internet — a blast radius large enough to rival a browser vendor's. In June 2024, attackers who had quietly acquired the Polyfill.io domain months earlier flipped a switch and began injecting malicious redirects into more than 100,000 websites that referenced the service, many of them running jQuery-based front ends that had loaded the polyfill script as a companion dependency for years without incident. Neither attack touched a line of jQuery's own source code. Both attacks exploited the same structural weakness: the CDN layer sitting next to jQuery on most production websites is rarely inventoried, rarely pinned, and almost never monitored by the security tooling that scans everything else in the stack.
The Scale of the Exposure
jQuery's dominance is not a legacy artifact — it is current, active infrastructure. W3Techs and BuiltWith have both consistently placed jQuery usage in the 75-80% range of all websites for years, a figure that dwarfs every competing front-end framework combined. A large fraction of that usage flows through a small number of shared CDN endpoints: code.jquery.com (the official host), cdnjs (Cloudflare-operated), jsDelivr, and Google's now-deprecated but still widely referenced Hosted Libraries. Because these are free, high-availability, low-latency services, they became the default choice for millions of sites that never intended to think about them again after the initial <script src> tag was pasted in.
The problem is what didn't get pasted in alongside it. Subresource Integrity (SRI) hashes — the integrity attribute that lets a browser verify a fetched script matches an expected cryptographic digest before executing it — remain absent from a large majority of CDN-loaded script tags across the web, despite being a W3C standard since 2016 and supported in every modern browser. Version pinning is similarly inconsistent: many sites still reference "latest" or unversioned CDN paths, meaning the exact bytes executed in a visitor's browser can change without any commit, pull request, or deployment on the site owner's side. That combination — implicit trust in a third-party host, no integrity verification, and no guarantee of version stability — is precisely the failure mode both major incidents exploited.
Case Study: The cdnjs RCE (2021)
Security researcher RyotaK found that cdnjs' package update automation processed npm and git-based package metadata in a way that allowed a maliciously crafted package to achieve remote code execution on the server responsible for publishing files to the CDN. Because cdnjs served libraries to a double-digit percentage of the entire web at the time, a successful exploit chain could have allowed an attacker to modify the JavaScript delivered to millions of pages — including any using jQuery from that CDN — without touching a single one of those pages' own codebases. Cloudflare, which had taken over cdnjs infrastructure, patched the flaw after responsible disclosure, and no evidence of in-the-wild exploitation surfaced. But the disclosure made an uncomfortable point unavoidable: the security of a website's front end is only as strong as the CDN update pipeline it silently depends on, and that pipeline sits entirely outside most organizations' vulnerability management programs.
Case Study: Polyfill.io (2024)
The polyfill.io service existed to let older browsers execute modern JavaScript by serving missing browser-API shims on request — a natural companion to jQuery-based sites that needed to support a wide range of browser versions. In February 2024, the original maintainer's GitHub organization and the polyfill.io domain were acquired by a company, later publicly linked to infrastructure operated under the name "Funnull," with no prior relationship to the polyfill project. Within months, security researchers at Sansec documented the domain injecting redirects to sports betting and adult content sites, and in some cases to further malware, triggered conditionally based on request headers to evade casual detection. By the time the story broke publicly in late June 2024, an estimated 100,000-plus websites were affected. Cloudflare and Fastly moved quickly to stand up clean mirrors so downstream sites could swap the reference without waiting on the compromised operator, and cdnjs and jsDelivr both suspended or restricted proxying of the domain. The episode was not a jQuery vulnerability in any technical sense — but it played out on the exact same population of sites, through the exact same trust model, that jQuery's CDN-based distribution relies on, and it demonstrated how fast a benign dependency can flip to hostile with zero changes on the victim's end.
An Earlier Warning: Browsealoud (2018)
The pattern predates 2024. In February 2018, attackers compromised Texthelp's Browsealoud accessibility widget — a third-party script embedded on more than 4,000 websites, including UK and US government portals, the UK's Information Commissioner's Office, and US federal court sites — and used it to silently deploy a Coinhive cryptomining script to every visitor's browser. The compromise lasted only a few hours before Texthelp pulled the script, but it hit an unusually sensitive population of government sites simultaneously, illustrating that a single compromised third-party include can produce simultaneous, cross-organizational incidents that no individual security team can detect from inside their own perimeter.
Why the Trust Model Keeps Failing
Three structural issues recur across all of these cases. First, CDN-loaded scripts are executed in the browser, outside the reach of most traditional software composition analysis (SCA) tools, which are built to scan package manifests and lockfiles rather than runtime <script> tags. Second, SBOMs generated from build-time dependency graphs frequently omit CDN-referenced front-end assets entirely, because nothing in package.json or a container manifest points to them — the reference exists only in HTML or a templating layer. Third, the absence of SRI and version pinning means that even organizations that do inventory their CDN dependencies have no cryptographic guarantee that the code executing today matches what was reviewed or approved yesterday. Put together, a security team can have a clean SBOM, a passing SCA scan, and a fully patched application layer while still shipping a live, unmonitored, unauthenticated third-party script to every visitor.
The Blast Radius Problem
What distinguishes CDN supply chain incidents from typical application vulnerabilities is simultaneity. A vulnerability in a self-hosted dependency requires an attacker to find and exploit it site by site. A compromised shared CDN endpoint reaches every dependent site the moment the malicious update propagates — no reconnaissance, no per-target exploitation, no detectable scanning traffic. That changes incident response math entirely: by the time a security team notices anomalous behavior, the compromise has typically already reached its full population of victims, and remediation depends on the CDN operator's response time rather than the victim organization's own patch cycle. For regulated industries, that also raises hard questions about breach notification timelines when the "vulnerable component" was never listed in an internal asset inventory to begin with.
How Safeguard Helps
Safeguard is built for exactly this blind spot. Reachability analysis identifies which CDN-loaded scripts, jQuery versions, and companion polyfills are actually executed on live, in-scope pages — rather than flagging every reference regardless of whether the vulnerable code path is ever reached by a real user session — so teams can triage by genuine exposure instead of raw dependency count. Griffin AI continuously monitors CDN-hosted dependencies for behavioral and provenance changes, surfacing incidents like a domain ownership transfer or an unexpected new redirect pattern before they reach production traffic at scale. Safeguard's SBOM generation and ingest pipeline extends coverage into front-end assets referenced via HTML and templating layers, closing the gap that leaves CDN-loaded scripts absent from manifest-based SBOMs entirely. And where remediation is needed — adding SRI hashes, pinning a floating CDN reference to an immutable version, or migrating a script to self-hosted infrastructure — Safeguard's auto-fix PRs deliver the change as a reviewable pull request instead of a manual ticket, shrinking the gap between detection and a shipped fix.