TL;DR: cdnjs .tgz path traversal into GITHUB_REPO_API_KEY environment exposure
- Trusted because Cloudflare: Everyone trusts cdnjs because Cloudflare runs it, but RyotaK's 2021 finding turned a crafted .tgz filename into path traversal that overwrote a regularly executed script and exposed GITHUB_REPO_API_KEY and WORKERS_KV_API_TOKEN from /proc/self/environ.
- Behavior over source: cside does not whitelist sources, its browser agent observes each script's runtime behavior 100% of the sessions, monitors over 60 attributes with AI, and factors historical context, which is exactly what would have caught arbitrary command execution flowing through the CDN more than 12% of the internet trusts.
- Verify, not trust: Cloudflare's post-mortem is a study in transparency, but the exploit would have executed directly in the browser and bypassed the WAF, so the decision is whether trusting sources is still the client-side model or whether verifying what they deliver is the only defensible one.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
Verifying that your 3rd party script sources are reputable is important. But that alone may not be enough.
That's what the world learned in 2021, when a massive vulnerability in Cloudlfare's cdnjs was flagged. Here's the rundown of what, and how, it happened.
Cdnjs is one of the most commonly used JavaScript Content Delivery Networks (CDNs) of today. Over 12% of all websites on the internet inject at least one script through cdnjs. A researcher with the screen name 'RyotaK' shared a supply chain vulnerability in cdnjs, allowing anyone on the internet to commit changes to cdnjs libraries when following a sequence of specific steps. Here are his full findings.
The vulnerability existed within the cdnjs library update server. This specific module aids developers in safely integrating popular packages into their sites.
The vulnerability in some detail
By publishing a .tgz file to the npm registry with a crafted filename designed to exploit this path traversal flaw, an attacker could trigger the cdnjs library update server to process the malicious file. This would overwrite a regularly executed script file, leading to arbitrary command execution on Cloudflare's servers.
To prove the exploitability, a demonstration was planned. It involved creating a .tgz file that, upon processing by the cdnjs update mechanism, would overwrite an innocuous script with malicious code. However, before executing this plan, the researcher discovered another potent attack vector through Git repository updates, involving symlinks that could read arbitrary files from the update server.
A mistake during the demonstration process exposed something worse. A symbolic link intended to point to a harmless file was mistakenly directed to /proc/self/environ, exposing sensitive environment variables, including GITHUB_REPO_API_KEY and WORKERS_KV_API_TOKEN. This showed how an attacker could gain access to most of the cdnjs infrastructure.
The potential issues
This could have resulted in remote code execution on Cloudflare's servers and the potential to run malicious code on the scripts, which are used by all end users. This bypasses Web Application Firewalls (WAFs) and any other filtering mechanisms since it runs directly on the browser itself.
As previously mentioned, this would've exposed more than 12% of websites and all their visitors to immediate danger if exploited (once caches were expired).
Cloudflare was quick to respond and took appropriate action before anyone was able to leverage the exploit. They are known for their detailed and very transparent post-mortums and incident disclosures. The full details of which can be read here.
The better way to do it
All of this goes to show that you can not just trust sources.
Even the best in the world are prone to mistakes. A safer and more secure way is to verify what those sources deliver.
Which is why cside exists. We offer a tiny script to add to a webpage, which does 2 things:
- Rewrite sources of scripts so cside fetches and analyses them. Making cside sit in the flow of the request between the user and the 3rd party script, allowing full insight into the scripts served. cside inspects every script in depth, across 100% of sessions, instead of only whitelisting sources. In some cases, optimizations can even be made through caching static scripts.
- Perform some browser-side behavior checks.
cside also monitors over 60 attributes and uses AI to flag any indicators of malicious intent in real-time. Our solution also factors in historical context, so changes over time are easier to spot as potential hijacks. cside also uses AI to parse through the code of the 3rd party script. The combination of our detection mechanisms means we can spot the attempt in milliseconds and can shut it down before any malicious operations and or alert if dangerous behavior arises.
