Binance Lost $6.3 Billion. The Same Day, One Hijacked Script Drained Polymarket. What Runs on Your Site Before Consent?

Two hacks, one day

Binance. The exchange put the loss at $6.3 billion and said it has allocated $6.34 billion of its own funds to cover it (The Block). Co-CEO Richard Teng pointed to “a compromised DevOps engineer’s laptop” that gave the attacker access to a service that submitted unauthorised withdrawals; Binance says it found no evidence that wallet private keys leaked. About $3 billion has been frozen. The blockchain analytics firm TRM attributes the attack with “high confidence” to North Korea’s TraderTraitor unit; Binance has not confirmed that (Al Jazeera, TechCrunch). These are first-day figures and may change.

Polymarket. The prediction market halted trading on its international site for about an hour after users reported unauthorised withdrawals. Researchers at Hudson Rock traced it to a JavaScript file served from DebugBear’s CDN, part of DebugBear’s Real User Monitoring product, a script sites add to measure how fast pages load for real visitors (BleepingComputer). The altered script checked whether the visitor was logged in, valued their holdings, and then tried to sell positions or move tokens to an attacker’s wallet. Hudson Rock’s summary: “Its central approach is to reuse authority already available in the authenticated application” (SecurityWeek). Estimates of the loss range from about $2.2 to $2.7 million. Polymarket said “one of our third party providers was compromised” and that affected users “will be made whole”. DebugBear confirmed a security incident and told customers: “If you use our RUM product, please remove the embed code from your website.” How the script was altered has not been established. It was Polymarket’s second third-party script incident this year, after one in June.

Why this is a consent story

A script you load from another company runs in your page with your page’s authority. It can read what the page shows, act as the logged-in user, and send data wherever it is told. You do not control its next version; the vendor does, and so does anyone who compromises the vendor. Polymarket did not write the malicious code. It just loaded the script.

That is the same list of scripts a consent setup is built around. Under EU rules, JavaScript that makes a visitor’s browser send information back “clearly falls within the scope” of Article 5(3) of the ePrivacy Directive, according to the EDPB’s guidelines (para. 33), whether it is an ad pixel or a monitoring tool. Whether a given script is exempt from consent is a separate question the guidelines leave open. The practical effect is that a properly run consent setup forces three habits that also happen to be good security:

1. An inventory. You cannot classify a script you do not know about. A CMP’s scan and category list is, in practice, a list of every third party that runs code on your site.
2. Nothing optional before a choice. Scripts outside the strictly necessary category do not load until the visitor agrees. For everyone who declines or ignores the banner, that code never runs. A tag that never loads cannot be turned against that visitor.
3. One place to switch it off. When DebugBear said “remove the embed code”, sites that load every vendor through one consent-aware tag manager could pause one tag. Sites with the snippet pasted into theme files had to find it first.

Be clear about the limits. Consent does not make a script safe: a visitor who clicked “Accept” still runs whatever the vendor serves. A logged-in trading page may treat performance monitoring as necessary and load it for everyone. And none of this would have stopped the Binance breach, which happened inside the company, not in a visitor’s browser.

The Consent Mode trap: it does not block scripts

This is the part many teams get wrong. Google Consent Mode does not stop scripts from loading. It tells Google’s own tags how to behave: with analytics_storage or ad_storage set to denied, they stop setting cookies and send cookieless pings instead. In “advanced” Consent Mode, Google’s tags load before any choice by design. And Consent Mode says nothing at all about non-Google scripts: a monitoring tool, a chat widget or a pixel from another company runs regardless of your Consent Mode state unless your CMP or tag manager holds it back.

So you need both:

• A correct Consent Mode default, set to denied before any Google tag runs, so Google’s tags behave properly until there is a choice. We showed earlier this month that without a default, GA4 writes cookies and sends no consent state at all.
• Real blocking for everything else, so non-essential third-party scripts wait for consent. That is the CMP’s job, or your tag manager’s consent checks, not Consent Mode’s.

Tools that help

To manage consent and block scripts

• A CMP that blocks before consent, not just records clicks. Commercial options include Cookiebot, OneTrust, Usercentrics and, for WordPress, Complianz; open-source options include CookieConsent and Klaro. Our CMP comparison covers features and prices. Whichever you choose, check that it is Google-certified if you serve ads in the EEA, and that it actually holds scripts back. Some only show a banner.
• Google Tag Manager consent settings. Give every tag a consent requirement under Advanced Settings → Consent Settings, so non-Google tags fire only after the right category is granted. It also gives you one switch per vendor: pause the tag and it is gone from every page.

To check what actually happens

• Your browser’s Network panel. Load the site in a clean profile, do not touch the banner, and list every third-party domain that appears. Our network-tab guide shows how to read the gcs parameter that tells you which consent state Google’s tags sent.
• Google Tag Assistant. Its Consent tab shows the default and update states as Google’s tags saw them, in order.
• A scanner, for a baseline. Running a scan now and again after any change gives you a list to compare against. A new domain on the list is the earliest visible sign that a script has changed.

To limit the damage when a vendor is compromised

• Content Security Policy. A script-src allow-list limits which hosts can serve code to your pages, and connect-src limits where scripts can send data. It would not stop a trusted host from serving bad code, but it can stop a script from talking to an unexpected server.
• Subresource Integrity for scripts with fixed versions: the browser refuses a file whose hash changed. Most vendor snippets change without notice, so this only works where the vendor publishes versioned files.
• Fewer scripts on sensitive pages. Login, checkout and account pages are where a script can do the most damage. Ask whether every vendor there needs to be there.

What to do this week

1. List every third-party script on your site and who runs it. If you use DebugBear’s RUM product, follow their instruction and remove the embed code until they say otherwise.
2. Confirm that your Consent Mode default is denied and runs before any Google tag.
3. Confirm that non-Google scripts wait for consent, by looking at the Network panel before you click anything.
4. Make sure every vendor can be switched off in one place, and that someone knows how.

Nothing here is legal or security advice for your specific site.

The fastest way to see every third party your pages load before consent is to look. Scan your site with CookieInspector and keep the result as your baseline. (CookieInspector is built by the team behind ConsentModeHQ.)