AppsFlyer SDK Exploited in New Supply Chain Crypto Attack

Between March 9 and March 11, 2026, attackers had a 48-hour window inside one of the most widely embedded JavaScript libraries on the internet. The AppsFlyer Web SDK — present in over 100,000 web and mobile applications — was quietly rewritten on AppsFlyer’s own CDN to steal cryptocurrency. No perimeter defense would have caught it. No WAF, no firewall, no endpoint agent. The attack lived entirely inside trusted third-party code running in your users’ browsers.

If you operate in fintech, e-commerce, crypto, or any vertical where users enter payment or wallet data, this one is worth your full attention.

AppsFlyer SDK Supply Chain Attack – What Happened?

Attackers injected malicious JavaScript into the AppsFlyer Web SDK hosted on AppsFlyer’s CDN — notably, not the mobile SDK. The compromised code intercepted cryptocurrency wallet addresses entered by end users, silently replacing them with attacker-controlled addresses while exfiltrating metadata: page URLs, timestamps, and user agents. The script continued to perform its legitimate analytics functions throughout, making it exceptionally difficult to detect through conventional means.

As of this writing, no stolen funds have been confirmed. But that’s not the point. The point is that for 48 hours, any business running this SDK was potentially serving malware to its own customers — and most had no way of knowing.

Why This Attack Is So Hard to Stop

This attack didn’t exploit a vulnerability in your code. It exploited your trust in someone else’s.

Developers embed the AppsFlyer SDK directly into their applications. Once integrated, it runs in the background with broad access to user activity and data flows — tracking installs, sign-ups, purchases, and campaign events. That access is what makes it valuable for analytics. It’s also what makes it a high-value target.

Traditional security controls failed here for a simple reason: the script source was already trusted. The malicious logic was heavily obfuscated within code your systems had been told was safe. Signature-based detection, SRI checks on a hash that was never flagged, allowlists — none of these catch an attack that originates from within the trusted source itself.

How Reflectiz Would Have Detected This

Reflectiz doesn’t ask “is this script allowed?” It asks: “Is this script behaving the way it should?”

Behavioral drift in a trusted SDK

The compromised AppsFlyer SDK kept doing its job while running additional malicious logic underneath. Reflectiz monitors runtime behavior continuously, so even when a script comes from a trusted source, it flags anomalies like:

• New or unusual outbound network connections
• External domains appearing for the first time
• Scripts executing logic outside their established behavioral baseline

Here’s what that looks like in practice: a Reflectiz customer running AppsFlyer would have seen an alert that the SDK had initiated connections to an unrecognized domain — something like analytics-appsflyr[.]com or a similarly disguised endpoint — within hours of the compromise. That alert would have been the earliest signal of something wrong, long before any vendor advisory.

Suspicious data flows on sensitive inputs

The injected code was designed specifically to intercept wallet addresses — a form of input that should never leave the page through a marketing SDK. Reflectiz maps data flows in real time and flags when sensitive user inputs are accessed or transmitted by scripts that have no business touching them. This shifts the detection model from access control to behavioral validation.

Hidden third-party dependencies

Supply-chain attacks routinely introduce secondary infrastructure — additional scripts, callbacks, or exfiltration endpoints — that weren’t part of the original integration. Reflectiz surfaces these by revealing which third parties an SDK is calling, whether new entities have appeared in the execution chain, and how far trust is being extended beyond your direct control. In this attack, that visibility would have exposed the malicious backend infrastructure operating behind AppsFlyer’s legitimate facade.

Script integrity monitoring

The simplest signal of all: the script changed. Reflectiz alerts on modifications to third-party scripts, behavioral differences between versions, and unexpected increases in code complexity or obfuscation. In a two-day attack window, real-time detection of a script change is often the difference between catching an incident and reading about it afterward.

The Broader Shift

The AppsFlyer incident follows a now-familiar pattern: Polyfill.io, Magecart, Ticketmaster/Inbenta. In each case, the attack vector wasn’t a misconfiguration or an unpatched CVE — it was trust. A trusted vendor, a trusted CDN, a trusted script.

The security perimeter has moved. It now extends to every third-party component running in your users’ browsers, and the only way to defend it is continuous monitoring of what those components actually do.

That’s what Reflectiz is built for.

If you’re unsure whether AppsFlyer or similar SDKs are running on your properties — and what they’re doing when they get there — request a free website scan.