Threat actors compromised the domain registrar for AppsFlyer’s websdk.appsflyer.com, enabling injection of obfuscated crypto-stealing JavaScript into the widely deployed AppsFlyer Web SDK during a multi-day window between March 9-11, 2026. Any application loading the SDK during that window may have exposed end users to cryptocurrency address-replacement attacks. AppsFlyer has confirmed unauthorized code delivery but has not disclosed the root cause, full affected scope, or specific indicators of compromise.
The attack vector here is the domain registrar layer, not the SDK codebase itself, not the CDN, not a developer credential compromise. Attackers gained enough control over the DNS or hosting configuration for websdk.appsflyer.com to substitute or modify the JavaScript payload served to downstream applications. This is a high-leverage vector: a single domain-level compromise propagates malicious code to every application that dynamically loads the SDK, without requiring any action by the application developers themselves. Organizations that pinned or cached specific SDK versions may have had partial protection, but those relying on live CDN delivery were exposed by default.
The payload behavior described, cryptocurrency address replacement, is a well-documented web skimming technique adapted for crypto targets. Rather than exfiltrating payment card data, this variant intercepts clipboard or form-field values containing wallet addresses and substitutes attacker-controlled addresses at the moment of transaction. The obfuscation layer reported in the injected code is consistent with standard skimmer evasion techniques designed to survive automated scanning and delay human detection. The three-day exposure window (March 9-11) is significant: any user who initiated a cryptocurrency transaction through an affected application during that period should treat the transaction as potentially compromised.
The downstream impact surface is unusually wide. AppsFlyer is a major mobile and web analytics provider with deep integration across thousands of commercial applications. Supply chain attacks targeting SDK or analytics providers are particularly effective because application owners rarely inspect third-party JavaScript for integrity on an ongoing basis. Unless Content Security Policy (CSP) headers were configured to restrict script sources, or Subresource Integrity (SRI) hashes were enforced for the SDK load, affected applications had no technical barrier to receiving the malicious payload.
A critical gap in the current disclosure is the absence of specific indicators of compromise from AppsFlyer. No malicious JavaScript hashes, no modified domain resolution records, no wallet addresses associated with the attacker have been publicly confirmed as of the time of reporting (per the primary source). This forces security teams into a reactive posture: they must reconstruct exposure from their own logs rather than matching against known IOCs. Organizations should pull CDN and DNS resolution logs for websdk.appsflyer.com covering March 9-11, 2026, and compare delivered script hashes against any pre-compromise baseline they can establish.
From a GRC standpoint, this event should trigger third-party risk reviews for any organization with AppsFlyer Web SDK in scope for applications handling financial transactions or cryptocurrency. The lack of disclosed root cause means vendor assurance statements cannot yet be validated. Until AppsFlyer provides a full post-incident disclosure, including how registrar access was obtained, what controls failed, and what remediation was applied, downstream organizations should treat the SDK’s integrity as unverified and consider whether contractual or regulatory notification obligations apply to their own users who may have been exposed.
- Audit exposure immediately: Pull CDN delivery and DNS resolution logs for websdk.appsflyer.com for March 9-11, 2026. Hash any cached copies of the SDK against known-good baselines to determine whether your applications received the malicious payload.
- Apply SRI enforcement going forward: Subresource Integrity hashes on third-party JavaScript loads would have blocked this attack at delivery. Any application loading external SDK or analytics scripts should enforce SRI and restrict script sources via Content Security Policy headers.
- Do not wait for vendor IOCs: AppsFlyer has not released specific indicators. Build detection from your own telemetry, look for unexpected clipboard manipulation, unusual outbound connections from browser sessions, or anomalous wallet address substitution patterns in transaction logs during the exposure window.
- Notify affected users proactively: Any application that handled cryptocurrency transactions during March 9-11 and loaded the AppsFlyer Web SDK dynamically should assess whether user notification obligations apply under applicable data protection or financial regulation frameworks.
- Escalate third-party risk review: Domain registrar compromise as an attack vector is underweighted in most third-party risk assessments. Review whether your SDK and analytics vendors have domain registrar account security controls (MFA, registrar lock, change alert monitoring) as part of vendor due diligence.
