Supply Chain Security

When the Tracker Becomes the Threat: The AppsFlyer SDK Supply Chain Attack

NH
NoHackie
March 18, 2026 10 min read

For roughly 14 hours in early March 2026, thousands of websites unknowingly served malicious JavaScript to their users. Not because anyone broke into those sites. Because attackers broke into the company supplying one of the scripts those sites trusted.

The AppsFlyer Web SDK compromise is a textbook supply chain attack — and one of the more consequential ones in recent memory. Attackers did not need to find a vulnerability in any of the tens of thousands of websites that loaded the SDK. They needed to find a vulnerability in one place: the domain registrar controlling websdk.appsflyer.com. Once they had that, every downstream site became a delivery vehicle for crypto-stealing JavaScript, and none of those site operators changed a single line of their own code.

What AppsFlyer Is — and Why It Matters Here

AppsFlyer is a mobile attribution and marketing analytics platform. Developers integrate its SDK into mobile apps and websites to track where users come from — which ad campaigns drove installs, what actions users take after arriving, and how those actions map to marketing spend. It is one of the leading "mobile measurement partner" (MMP) platforms in the industry.

The scale of its deployment is what made this incident significant. According to AppsFlyer, its SDK platform is used by 15,000 businesses worldwide across more than 100,000 mobile and web applications. Named clients include TikTok, Netflix, Ubisoft, Carrefour, Burger King, Lululemon, and Pepsi — a cross-section of industries ranging from entertainment and retail to food service and consumer goods. The Web SDK specifically loads on user-facing pages to capture session data, meaning it runs inside the browser on every page visit, including checkout flows, account dashboards, and transaction confirmation screens.

That is precisely why the Web SDK was the right target. A script that sits inside a checkout page has browser-level access to everything on that page: form fields, keystrokes, submitted data, and network requests. An attacker who controls what that script does controls what the browser does with user input — including cryptocurrency wallet addresses.

How the Attack Worked

The attack vector was a domain registrar compromise. According to AppsFlyer, attackers gained unauthorized access to the registrar account controlling websdk.appsflyer.com and used that access to replace the legitimate SDK content served from that domain with a malicious payload. AppsFlyer's status page recorded a domain availability incident beginning on March 10, 2026, at 04:09 UTC, marked resolved on March 12 at 12:34 UTC. Independent researchers, including Profero and Feroot, estimated the window during which malicious code was actively served as narrower — approximately from March 9 at 20:40 UTC to March 10 at 10:30 UTC, a span of roughly 14 hours.

"While the full scope, duration, and root cause of the incident remain unverified, the activity highlights how threat actors can abuse trust in widely deployed third-party SDKs to impact downstream websites, applications, and end users." — Profero Incident Response Team, March 11, 2026

The key structural feature of this attack is that affected websites did not need to be compromised individually. They had configured their pages to load the AppsFlyer Web SDK from AppsFlyer's domain, which is the standard integration method. When the attackers poisoned the content at that domain, the malicious script propagated automatically to every site that called it — no further action required on the attacker's part, and no visible change on the victim sites. As Feroot noted in its disclosure, the affected script was distributed through AppsFlyer's content delivery path rather than through changes made directly on customer websites.

Attack Chain — AppsFlyer SDK Supply Chain Compromise
STAGE 1 Registrar Hijack STAGE 2 Malicious SDK Injected STAGE 3 Browser-Side Execution STAGE 4 Wallet Address Replaced STAGE 5 Funds Exfiltrated websdk.appsflyer.com ~170 KB obfuscated JS DOM hooks / XHR intercept BTC / ETH / SOL / XRP / TRX /v1/api/process?rd=
Five-stage kill chain: from domain registrar compromise through attacker-controlled wallet exfiltration. The attack required no changes to any downstream website's own code.

AppsFlyer confirmed the nature of the incident to BleepingComputer. A company spokesperson stated that the mobile SDK was unaffected throughout, that no customer data on AppsFlyer systems was accessed, and that the issue had been resolved. AppsFlyer also noted it was working with external forensic experts and would share further findings after completing the investigation. As a containment step beyond the public status note, the company revoked all API V2 tokens generated before March 10, 2026, at 19:00 UTC, requiring customers to regenerate them.

Inside the Payload: A Professional-Grade Interception Framework

Initial community analysis described the malicious code as a crypto clipper — a script that swaps wallet addresses. Independent researcher Daniel Smith, who performed his own deobfuscation of two separate captures of the payload, confirmed the address-swapping behavior but found the full picture considerably more concerning.

"This is a professional-grade interception framework with seven distinct modules, anti-detection capabilities, value-threshold targeting, and a polymorphic obfuscation pipeline that defeats signature-based detection." — Daniel Smith, independent security researcher, March 11, 2026

The payload was a roughly 170 KB minified JavaScript file using multi-layered base91 string encoding with 17 distinct shuffled alphabets. Profero's Incident Response Team confirmed the technical behavior through direct analysis of the recovered payload, including archived copies. Here is what the script did, step by step:

  1. Loaded and decoded obfuscated strings at runtime, making static signature-based detection ineffective.
  2. Installed hooks into browser network requests, giving it visibility into all XHR and fetch activity on the page.
  3. Monitored the DOM for user input fields associated with cryptocurrency wallet addresses, including clipboard activity during copy-and-paste actions.
  4. Checked for cryptocurrency address patterns covering Bitcoin, Ethereum, Solana, Ripple, and TRON.
  5. Replaced any detected wallet address with an attacker-controlled address before the transaction was submitted.
  6. Exfiltrated the original wallet address and associated metadata to the attacker's infrastructure using XOR-obfuscated data in the rd query parameter.

The payload also contacted two C2 endpoints: websdk.appsflyer.com/v1/api/plugin to fetch updated attacker wallet addresses, and websdk.appsflyer.com/v1/api/process to receive exfiltrated data. This dual-endpoint design gave the attacker an important operational advantage: even if the hardcoded fallback wallets were blocklisted, the script could pull fresh wallet addresses from the plugin endpoint, allowing rotation over time to evade tracking.

One Protective Limit

The browser's same-origin policy partially constrained the payload. Sites using cross-origin payment iframes — such as Stripe Elements, Braintree, or Adyen — retained protection for card data within those iframes, because the malicious script could not reach across origin boundaries. However, any site collecting payment or wallet data directly in its own DOM, submitting it via first-party JavaScript, had no such protection during the exposure window.

Indicators of Compromise

Organizations that loaded the AppsFlyer Web SDK during the March 9–11 exposure window should query proxy logs, SIEM telemetry, and CDN records for the following indicators. The MITRE ATT&CK mapping for this attack covers T1195.002 (Supply Chain Compromise), T1059.007 (JavaScript execution), T1565.001 (Stored Data Manipulation), and T1568 (Adversary-in-the-Middle).

Type Indicator Context
Domain websdk[.]appsflyer[.]com SDK delivery origin; compromised during incident window
URL /v1/api/plugin C2 endpoint used to fetch updated attacker wallet addresses
URL /v1/api/process?rd= Exfiltration endpoint; rd parameter carries XOR-obfuscated stolen data
BTC Wallet bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt Attacker-controlled Bitcoin address (hardcoded fallback)
ETH Wallet 0x1C069d0c73087D0Bae687a6f74a807350dCe1829 Attacker-controlled Ethereum address (hardcoded fallback)
SOL Wallet 4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK Attacker-controlled Solana address (hardcoded fallback)
XRP Wallet rntqwheGbZihkabxf6xqZkUKGfTVyRhT14 Attacker-controlled Ripple address (hardcoded fallback)
TRX Wallet TV6WtAkS4aAMJb3Rt2bfs8LxggF8Kmqbd9 Attacker-controlled TRON address (hardcoded fallback)

Source: Profero IRT payload analysis, March 11, 2026 (profero.io). Note that the attacker's wallet rotation capability means these hardcoded addresses represent only confirmed fallback values, not the complete set of wallets used during the active window.

The Compliance Connection: PCI DSS 4.0.1

The AppsFlyer incident is a direct illustration of why the PCI Security Standards Council added requirements 6.4.3 and 11.6.1 to PCI DSS 4.0.1. These requirements specifically address client-side script integrity on payment pages — and the AppsFlyer attack is the scenario they were written for.

Requirement 6.4.3 mandates that organizations maintain an authorized inventory of all scripts on payment pages, assign a business justification to each, and implement mechanisms to verify script integrity. A marketing attribution script loaded on a checkout page would need to be documented, justified, and verified against a known-good baseline. The moment the AppsFlyer SDK was tampered with at the source, an integrity check against that baseline would have failed, alerting the organization before users were exposed.

Requirement 11.6.1 mandates continuous tamper detection and alerting for scripts and HTTP headers on payment pages. Even if an organization had not implemented integrity hashing, behavioral monitoring under 11.6.1 would have flagged the SDK's new behavior — specifically its network requests to previously unobserved endpoints and its interaction with wallet input fields.

"For anyone who's been wondering why PCI DSS 4.0.1 added requirements 6.4.3 and 11.6.1, this is your answer." — Juan Carlos Munera, cybersecurity analyst, March 2026

Feroot Security similarly pointed to this compliance connection in its disclosure, noting that requirements 6.4.3 and 11.6.1 exist precisely because of this class of attack. KENSAI's analysis drew a direct parallel to the EU's Cyber Resilience Act, which requires manufacturers and software integrators to exercise due diligence over third-party components embedded in their products — a standard that websites embedding third-party SDKs would need to meet.

Context: AppsFlyer's Second Incident of 2026

The March SDK compromise is not AppsFlyer's first security-related headline this year. In January 2026, the threat group ShinyHunters claimed it had used a compromised Okta SSO account to access Match Group's AppsFlyer marketing analytics instance, and in doing so obtained more than 10 million records from Hinge, Match.com, and OkCupid users — including user IDs, transaction data, IP addresses, and dating profiles. Match Group confirmed a security incident and acknowledged that user data was likely accessed. AppsFlyer denied that its systems were breached in that case.

The two incidents involve different attack vectors. January's alleged breach centered on SSO credential theft targeting a customer's AppsFlyer instance. March's attack was a domain registrar compromise affecting the SDK itself, upstream of all customers simultaneously. They are structurally distinct, but the proximity of two high-profile incidents within three months has intensified scrutiny of AppsFlyer's role as a trusted component in global web infrastructure.

Analysts have also noted the pattern relative to other high-profile JavaScript supply chain events. The attack methodology — poisoning a widely trusted CDN-distributed script — follows the same general approach as the Polyfill.io compromise in 2024 and the event-stream npm attack. What distinguishes the AppsFlyer incident is the target profile: Polyfill.io served general-purpose browser compatibility shims, while AppsFlyer is an enterprise analytics platform whose clients are major brands with significant transaction volumes.

What Organizations Should Do Now

If your organization embedded the AppsFlyer Web SDK during the March 9–11 window, the following steps apply.

Immediate investigation: Query web server logs, CDN logs, and SIEM telemetry for outbound connections to websdk[.]appsflyer[.]com/v1/api/plugin or /v1/api/process between March 9 and March 11. Review any cryptocurrency-related transaction flows or user reports of failed or misdirected transfers from that period. Regenerate any AppsFlyer API V2 tokens created before March 10 at 19:00 UTC, as AppsFlyer revoked these during containment.

User notification assessment: Evaluate whether users who conducted cryptocurrency transactions through your platform during the exposure window require notification under applicable breach notification obligations. Independent researcher Daniel Smith noted in his payload analysis that the network interception framework had broad data visibility beyond cryptocurrency, meaning organizations should not limit their assessment to crypto-specific use cases.

Longer-term controls: The single most effective prevention against this class of attack is Subresource Integrity (SRI). Adding an integrity attribute to script tags causes the browser to verify a cryptographic hash of the loaded file before executing it. If the file has been modified at the source — as in this incident — the hash check fails and the browser refuses to run the script. SRI does carry a maintenance overhead: every time the vendor updates the script, the hash changes and must be updated on your end. This overhead is a useful forcing function, requiring explicit review of any script change before it reaches production payment pages.

Beyond SRI, a strict Content Security Policy restricting script-src to known-good origins limits the blast radius of a compromised external script. Behavioral monitoring tools — which flag runtime behaviors such as unexpected fetch activity, DOM manipulation of form fields, or network calls to previously unobserved endpoints — are the only effective defense against dynamically obfuscated payloads that defeat hash-based detection.

Key Takeaways

  1. The trust chain is the attack surface. Downstream websites did nothing wrong operationally. They configured their pages to load a trusted script from a trusted domain. When the domain was compromised, the attack propagated automatically to every one of them. The attack surface in a supply chain compromise is not the victim's code — it is the trust they have placed in a third party.
  2. Availability monitoring is not integrity monitoring. The AppsFlyer domain remained reachable throughout the incident. A script can be available and still serve malicious content. Uptime checks, synthetic monitoring, and error rate tracking would not have caught this. Only integrity verification — either via SRI or behavioral runtime monitoring — would have detected the tampered payload.
  3. The payload's scope may exceed the visible behavior. The crypto-clipping behavior was what was visible in static analysis. The framework's C2 instruction capability means it could have been configured to intercept any data the browser could see. Organizations should treat the exposure window as a general data interception risk, not only a cryptocurrency risk.
  4. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 exist for this exact scenario. Organizations that have not yet implemented script inventory, integrity verification, and tamper detection on payment pages now have a concrete, recent example of the consequences. These are not theoretical compliance checkboxes.
  5. Attribution remains unconfirmed. No APT group has claimed responsibility. The methodology is consistent with financially motivated groups specializing in JavaScript web skimming, but the domain registrar access vector and the sophistication of the payload indicate a high level of operational planning. Root cause has not been publicly released by AppsFlyer as of this writing.

The AppsFlyer SDK incident demonstrates a structural problem with how the web consumes third-party JavaScript. Thousands of organizations placed unconditional trust in a script they did not control, loaded from a domain they did not operate. That trust was exploited through a single point of failure — a domain registrar account — and the consequences cascaded to every downstream user who entered a cryptocurrency wallet address during a 14-hour window. The defenses exist. SRI, behavioral monitoring, and strict Content Security Policy are all deployable today. The question after this incident is whether organizations will treat the lesson as a reason to implement them, or file it alongside the others and wait for the next one.

Sources

← all articles