AppsFlyer Web SDK compromise served crypto-stealing code in supply chain attack

AppsFlyer says unauthorized code was briefly delivered through its Web SDK after a domain registrar incident, exposing some websites that loaded the script to malicious JavaScript. The company says the mobile SDK was not affected, and its investigation so far has found no evidence that customer data on AppsFlyer systems was accessed.

The attack matters because the AppsFlyer Web SDK sits inside a large number of sites and apps that use it for attribution and analytics. Security researchers who analyzed the payload say the injected code monitored pages for cryptocurrency wallet activity, then swapped wallet addresses with attacker-controlled ones to divert funds.

AppsFlyer’s status page shows a domain availability incident began on March 10, 2026, at 04:09 UTC and was marked resolved on March 12, 2026, at 12:34 UTC. Separately, AppsFlyer’s developer documentation says all API V2 tokens generated before March 10, 2026, 19:00 UTC were revoked and needed regeneration, which suggests the company took broader containment steps beyond the public status note.

What happened

According to reporting that cites an AppsFlyer spokesperson, the company 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. AppsFlyer says the issue has been resolved and that it has been communicating directly with affected customers.

Independent researchers say the malicious code was served from the official websdk.appsflyer.com domain. Profero and Feroot both described the incident as a supply chain compromise, where downstream sites did not need to change their own code to expose visitors because the trusted third-party script itself had turned malicious.

What the malicious code did

Researchers say the injected JavaScript preserved normal SDK behavior so it would not break sites visibly. In the background, it loaded obfuscated strings, hooked browser network activity, watched for wallet address input, and replaced detected cryptocurrency addresses with attacker-controlled ones. Reported targets included Bitcoin, Ethereum, Solana, Ripple, and TRON wallet formats.

That behavior turns a normal analytics dependency into a transaction hijack tool. A user could believe they were sending funds to the intended recipient while the script silently rewrote the destination. This is an inference from the reported wallet replacement mechanism described by researchers.

Timeline and scope

Source: AppsFlyer status page, AppsFlyer developer documentation, and researcher reporting.

Researchers cited by media reports estimate the likely exposure window was narrower than the full status-page outage, but AppsFlyer has not publicly confirmed the exact malicious-serving interval in the materials I found. Because of that, the safest wording is that unauthorized code was temporarily served during the broader incident window, while the precise exposure duration remains under investigation.

Why this incident stands out

This is a textbook software supply chain problem. The websites using AppsFlyer may have done nothing wrong, but they still exposed visitors because they trusted a widely used third-party SDK. That is exactly why third-party script integrity and monitoring matter so much in payment and account workflows. This conclusion follows from the reported attack path and public incident details.

It also shows why organizations that rely on external JavaScript need controls that go beyond uptime monitoring. A script can stay available and still serve malicious content, which means availability alone does not prove safety. This is an inference based on the fact that the issue involved unauthorized code delivery through a trusted SDK.

What organizations should do now

• Review logs and client-side telemetry for requests involving websdk.appsflyer.com during the incident period. This follows from the reported delivery vector.
• Recheck any crypto-related workflows or transaction forms presented to end users during the exposure window.
• Regenerate relevant AppsFlyer API V2 tokens if they were created before March 10, 2026, 19:00 UTC, because AppsFlyer says those tokens were revoked.
• Confirm the currently loaded Web SDK is a known-good version and watch for further AppsFlyer customer guidance.
• Consider adding client-side monitoring and integrity controls for third-party scripts used in sensitive flows. This is a practical mitigation inference based on the attack method.

FAQ