Attackers injected crypto-stealing JavaScript into the AppsFlyer Web SDK through a domain registrar compromise. The malicious payload was served from AppsFlyer's official domain, websdk.appsflyer.com, between approximately March 9 at 2040 UTC and March 10 at 1030 UTC, 2026. Any website loading the SDK during that roughly 14-hour window delivered the malware to visitors without any change to the site's own code.
AppsFlyer is a marketing analytics platform used by thousands of websites and apps. The Web SDK tracks user engagement and attribution data across e-commerce, fintech, healthcare, and SaaS sites. Because the script loads on every page (including checkout and login flows), the compromise gave attackers browser-level access to form fields, keystrokes, authentication tokens, and submitted data.
Profero, a cybersecurity firm, discovered the malicious payload on March 9. The injected code preserved normal SDK functionality while running a hidden interception framework in the background. It decoded obfuscated strings at runtime, hooked into browser network requests by replacing the native fetch and XMLHttpRequest functions, and monitored DOM input fields using a MutationObserver. When it detected a cryptocurrency wallet address, it swapped it with an attacker-controlled address and exfiltrated the original via an XOR-encrypted POST to a command-and-control server.
The full scope of the incident remains unverified, according to Profero. The firm's analysis emphasized that the attack demonstrates how threat actors can abuse trust in widely deployed third-party SDKs to affect downstream websites, applications, and end users without touching those systems directly.
Security researcher Daniel Smith deobfuscated two captured samples of the payload. Smith described it as a "professional-grade interception framework" with seven distinct modules, anti-detection capabilities, value-threshold targeting, and a polymorphic obfuscation pipeline using multi-layered base91 encoding with 17 distinct shuffled alphabets. The ~170 KB payload fetched runtime configuration from a C2 server, which provided attacker wallet addresses for five cryptocurrency formats (Ethereum, Bitcoin, Solana, Monero, and Ripple).
The crypto-clipping behavior is what's visible in the code, but the framework was capable of arbitrary data interception per C2 instruction. Only AppsFlyer or law enforcement with C2 server access can confirm the full operational scope.
— Daniel Smith, independent security researcher, wrote in his analysis published on March 11
Smith noted one protective factor. The browser's same-origin policy blocked the payload from reaching into cross-origin payment iframes used by processors like Stripe Elements, Braintree, and Adyen. Sites that collect card data inside their own DOM, however, had no such protection during the exposure window.
AppsFlyer confirmed the compromise to BleepingComputer on March 14. The company attributed the incident to a "domain registrar incident" and said it affected the Web SDK on "a segment of customer websites." The mobile SDK was not affected. AppsFlyer stated that its investigation has not found evidence of customer data on AppsFlyer systems being accessed.
AppsFlyer detected and contained a domain registrar incident on March 10 that temporarily exposed the AppsFlyer Web SDK running on a segment of customer websites to unauthorized code. We take this incident very seriously and have been actively communicating with customers.
— an AppsFlyer spokesperson told BleepingComputer
Reddit users spotted the attack in real time. DNS records for the AppsFlyer domain shifted from AWS to GCore CDN at the start of the malicious activity. One commenter noted that the hijacked fetch proxy was double-encoding payloads, which broke API access on multiple affected websites and made the compromise visible through site outages rather than just silent data theft.
AppsFlyer was implicated in a separate security incident earlier in 2026. In January, the threat group ShinyHunters claimed it used a compromised Okta SSO account to access Match Group's AppsFlyer marketing analytics instance, stealing over 10 million records from Hinge, Match.com, and OkCupid. AppsFlyer denied that its systems were breached in that incident. The March SDK compromise is a different attack vector (domain hijacking versus SSO credential theft), but the two incidents within three months put AppsFlyer's role as a trusted third-party script under renewed scrutiny.
Feroot Security flagged the compromise and reminded organizations that PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 mandate continuous inventory and integrity monitoring of scripts on payment pages specifically because of this type of supply chain attack. The compliance requirement exists because third-party scripts run with the same privileges as first-party code but sit outside the site operator's change management and security review processes.
Organizations loading the AppsFlyer Web SDK should review their exposure immediately. Check server and CDN logs for the March 9 to March 10 UTC window. Remove or block the script until AppsFlyer confirms a clean build. If the site collects payment or health data in its own DOM (not through a cross-origin iframe), notify compliance teams and evaluate breach notification obligations.
Have a story? Become a contributor.
We work with independent researchers and cybersecurity professionals. Send us a tip or submit your article for editorial review.