Was the AppsFlyer mobile SDK affected by the March 2026 compromise?

AppsFlyer says no. Only the Web SDK served from websdk.appsflyer.com was affected, and the company said the mobile SDK stayed safe to use throughout.

How did the malicious AppsFlyer script steal cryptocurrency?

It watched the page and clipboard for wallet addresses and replaced them with attacker-controlled ones, which it fetched from the compromised domain so they could be rotated. It also sent the original addresses and page details back to the attacker.

How can I protect my site from compromised third-party JavaScript?

Pin and self-host critical scripts or use Subresource Integrity hashes, keep third-party tags off sensitive pages, and use a Content-Security-Policy with reporting. Allowlisting the vendor's domain alone won't stop an attack served from that same domain.

AppsFlyer Web SDK Hijack: Crypto Stealer Supply Chain

For several hours on 9–10 March 2026, websites loading AppsFlyer's Web SDK from websdk.appsflyer.com served attacker-controlled JavaScript that swapped cryptocurrency wallet addresses. AppsFlyer attributed it to a "domain registrar incident." The case is a clear reminder that every <script src> pointing at a third-party domain gives that domain, and whoever controls its DNS, full control of your page.

What happened

Incident response firm Profero began investigating on 9 March after customer reports. It confirmed obfuscated malicious code being served from AppsFlyer's official Web SDK domain alongside the legitimate SDK. Profero put the start of the window at about 22:45 UTC on 9 March and said it could not confirm when it ended (possibly as late as 11 March). A Cloud Security Alliance research note, drawing on community analysis, estimated a shorter window of roughly 14 hours ending around 10:30 UTC on 10 March.

AppsFlyer said it "detected and contained a domain registrar incident on March 10" that exposed the Web SDK "running on a segment of customer websites to unauthorized code." It said the mobile SDK was not affected and that it had found no evidence that customer data on AppsFlyer systems was accessed. According to CSA, AppsFlyer also revoked API V2 tokens issued before 19:00 UTC on 10 March. AppsFlyer says about 15,000 businesses use its platform across more than 100,000 apps.

Researchers described the payload as follows:

It kept the SDK's analytics working so nothing looked broken.
It decoded obfuscated strings at runtime and wrapped fetch and XMLHttpRequest to inspect and rewrite traffic.
It used a MutationObserver and clipboard hooks to find wallet addresses for Bitcoin, Ethereum, Solana, XRP and TRON and replace them with attacker addresses.
It fetched current attacker addresses from /v1/api/plugin and sent the original address, page URL, timestamp and user agent to /v1/api/process, both on the compromised domain.

Who is affected

Websites and web apps that load the AppsFlyer Web SDK dynamically from websdk.appsflyer.com during the window. Self-hosted or bundled copies weren't affected.
Their end users, especially anyone who typed, pasted or was shown a crypto wallet address on those pages.
AppsFlyer API V2 token holders, who needed to regenerate tokens.

No company has publicly confirmed financial losses.

What it means for developers and engineering teams

Most supply-chain defences, such as lockfiles, signed packages and SBOMs, protect code you build. A runtime-loaded script skips all of them. If the vendor's DNS, registrar account, CDN or TLS certificate is compromised, the attacker serves new code straight to your users, and your build pipeline never sees it. The 2024 polyfill.io incident followed the same pattern.

The payload also shows why a strict Content-Security-Policy that only allowlists the vendor's domain isn't enough here. Exfiltration and command-and-control went through the same trusted domain, so connect-src allowlisting didn't help. What does help is pinning the exact code (Subresource Integrity or self-hosting), and keeping marketing and analytics tags off sensitive pages entirely.

The incident also exposes a practical gap in monitoring. A third-party script that keeps working normally while adding hidden behaviour won't trip error-rate alerts or synthetic uptime checks. Detecting it needs either integrity checks (compare the served file hash against a known-good baseline on a schedule) or behavioural monitoring in the browser, such as watching for new network destinations or for scripts wrapping fetch. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 already ask payment pages to inventory scripts and detect unauthorised changes, and that is a sensible baseline for any page that handles money or credentials.

What to do now

Inventory third-party scripts on every page, and find out which load from a vendor domain at runtime.
Pin versions and add SRI where the vendor publishes versioned files: <script src="…/sdk-1.2.3.js" integrity="sha384-…" crossorigin="anonymous">. Generate the hash with openssl dgst -sha384 -binary sdk.js | openssl base64 -A.
Self-host or proxy critical SDKs through your own build, so updates go through code review.
Keep analytics and marketing tags off checkout, wallet, login and settings pages.
Use CSP with reporting (report-to) to catch unexpected script sources and eval use. Consider require-trusted-types-for 'script'.
If you used AppsFlyer's Web SDK, search logs and RUM data for /v1/api/plugin and /v1/api/process requests on 9–11 March, regenerate API tokens, and check with counsel whether users who handled wallet addresses need to be notified.

AppsFlyer Web SDK served crypto-stealing JavaScript after a domain registrar incident

What happened

Who is affected

What it means for developers and engineering teams

What to do now

Related on TechLogHub

Sources

Get the next deep dive in your inbox

See what launched this week

The weekly digest