That Analytics SDK on Your Favorite Website Was Secretly Swapping Crypto Wallets for Two Days

15,000 Businesses, One Compromised Script

When you visit a website that uses a third party analytics service, your browser quietly loads JavaScript code from that provider's servers. You never see it happen. The website operator trusts the provider, and you trust the website. That chain of trust is what makes supply chain attacks so dangerous, and so effective.

AppsFlyer is one of the largest mobile attribution and analytics platforms in the world. Its Web SDK is embedded in websites operated by roughly 15,000 businesses, powering analytics across more than 100,000 applications. Between March 9 and March 11, 2026, that SDK was hijacked. Every website loading the script from websdk.appsflyer.com was unknowingly serving malicious JavaScript designed to steal cryptocurrency by swapping wallet addresses in real time.

How the Attack Worked

The attackers did not breach AppsFlyer's internal systems directly. Instead, they compromised the domain registrar account associated with AppsFlyer's SDK distribution infrastructure. By gaining control at the DNS level, they were able to redirect requests for the legitimate SDK to a server they controlled, one that served a modified version of the JavaScript file.

The malicious code was carefully designed. It preserved all of the SDK's normal analytics functionality, so website operators would not notice anything unusual in their dashboards or browser consoles. Underneath that legitimate behavior, the injected code performed a single, targeted function: it scanned every page the user visited for cryptocurrency wallet addresses.

When the script detected a wallet address on a page, whether displayed in a payment form, a donation widget, or a transaction confirmation screen, it silently replaced it with a wallet address controlled by the attacker. The replacement happened in the browser's rendered page, meaning the user would see the attacker's address when they copied it, while the original address remained unchanged in the site's backend database.

The attack targeted five major cryptocurrencies: Bitcoin, Ethereum, Solana, Ripple, and TRON. Each has a distinct address format, and the malicious code contained regex patterns to identify and replace all five types. Anyone who copied a wallet address from an affected page and pasted it into their own wallet or exchange would have sent funds directly to the attacker.

Why Supply Chain Attacks Are So Difficult to Detect

This attack illustrates a fundamental problem with how the modern web works. Websites routinely load dozens of third party scripts for analytics, advertising, chat widgets, payment processing, and more. Each of those scripts runs with the full privileges of the host page. If any single script is compromised, it can read form inputs, modify page content, redirect users, or exfiltrate data, all without the website operator knowing.

The AppsFlyer attackers understood this dynamic and exploited it deliberately. By keeping the SDK's legitimate functions intact, they ensured that no alarms would fire. Analytics data kept flowing. Page load times remained normal. The only change was invisible to anyone not specifically inspecting the rendered DOM for altered wallet addresses.

Subresource Integrity (SRI) is a browser feature designed to prevent exactly this kind of attack. When a website includes an SRI hash with a script tag, the browser verifies that the loaded file matches the expected hash before executing it. If the file has been tampered with, the browser refuses to run it. However, SRI adoption remains low because it requires website operators to update the hash every time the third party updates their script, which creates a maintenance burden most teams avoid.

The Scale of Exposure

AppsFlyer's customer base spans ecommerce platforms, financial services, gaming companies, and major consumer brands. The company reports that its platform is used by 15,000 businesses for over 100,000 apps. While not every customer uses the Web SDK specifically, the number of websites potentially serving the compromised script during the two day window was substantial.

AppsFlyer stated that it detected the compromise on March 10 and contained the incident, restoring the legitimate SDK. The full window of exposure ran from approximately March 9 through March 11. The company has not disclosed how many end users may have been affected or whether any cryptocurrency theft has been confirmed.

What makes this particularly concerning is the attack vector. Domain registrar compromises are relatively rare but extremely powerful. When an attacker controls DNS, they can intercept or redirect traffic for any service hosted under that domain. Traditional security measures like Web Application Firewalls, endpoint detection, and even code review processes are useless against an attack that happens at the infrastructure layer before the code ever reaches the application server.

What Developers and Website Operators Should Do

If your website loaded the AppsFlyer Web SDK between March 9 and 11, you should assume the compromised script was served to your users. Review your site's pages that display cryptocurrency addresses and notify affected users if applicable.

Beyond this specific incident, the attack reinforces several defensive practices that engineering teams should adopt for any third party script dependency:

• Implement Subresource Integrity (SRI) for all externally loaded scripts. Yes, it requires updating hashes when vendors push new versions, but it is the single most effective defense against tampered scripts.
• Use Content Security Policy (CSP) headers to restrict which domains can serve executable scripts on your pages. A well configured CSP would not have prevented this specific attack since the script came from the legitimate domain, but it limits the blast radius of other supply chain compromises.
• Self host critical third party scripts when possible. Loading a local copy of an SDK eliminates the risk of DNS level hijacking entirely, at the cost of missing automatic updates.
• Monitor script behavior using tools that detect unexpected DOM modifications or network requests from third party code. Runtime monitoring can catch address swapping behavior even when the script's source domain appears legitimate.
• Secure your own domain registrar accounts with strong multifactor authentication. If attackers can compromise a registrar, they can compromise everything downstream.

The Bigger Picture

The AppsFlyer incident is not an isolated event. Supply chain attacks targeting JavaScript dependencies have been accelerating. The 2024 Polyfill.io compromise affected over 100,000 websites after a Chinese company acquired the domain and injected malicious redirects. The 2021 ua-parser-js npm attack embedded cryptominers in a package downloaded millions of times per week. Each incident follows the same pattern: compromise a widely trusted dependency, inject malicious code, and let the internet's trust model do the distribution for you.

For end users, these attacks are nearly impossible to detect. The malicious behavior happens inside a legitimate website you already trust. Your browser has no way to distinguish between the real SDK and the tampered version. There is no warning, no popup, no certificate error.

The AppsFlyer attack lasted roughly two days before it was caught. The next one might not be detected as quickly. As long as the web relies on a sprawling network of third party scripts loaded at runtime, supply chain attacks will remain one of the most potent and underappreciated threats in cybersecurity.