What Happened
Between March 9 and March 11, 2025, attackers compromised the AppsFlyer Web SDK, injecting malicious JavaScript to steal cryptocurrency. The code targeted cryptocurrency wallet addresses, replacing legitimate ones with attacker-controlled addresses during transactions. AppsFlyer confirmed the unauthorized code delivery on March 10.
The impact was significant: AppsFlyer's SDK is integrated into over 100,000 applications used by 15,000 businesses worldwide. Security researchers at Profero discovered the compromise, which followed previous targeting of AppsFlyer by the threat group ShinyHunters.
Timeline
March 9, 22:45 UTC: Likely start of the exposure window. Malicious code begins delivery through the compromised SDK.
March 10: AppsFlyer confirms unauthorized code delivery and begins incident response.
March 11: Estimated end of exposure window.
Your team should review application logs and user transaction data from this 38-hour window if you integrated the AppsFlyer Web SDK.
Which Controls Failed or Were Missing
Insufficient Build Pipeline Integrity
The attackers injected code into the SDK distribution channel, indicating missing or failed controls around:
- Code signing verification for SDK artifacts
- Build pipeline access controls
- Deployment authorization gates
- Artifact integrity validation
Absent Subresource Integrity Checks
Applications loading the SDK from AppsFlyer's CDN had no mechanism to verify the integrity of the JavaScript before execution. The malicious code ran with full privileges in the user's browser context.
Missing Runtime Behavior Monitoring
The injected code performed cryptocurrency-specific operations—scanning for wallet addresses and modifying clipboard content. No runtime controls detected this anomalous behavior, which differed significantly from legitimate marketing analytics functions.
Inadequate Third-Party Risk Assessment
Organizations integrating the SDK lacked visibility into AppsFlyer's security posture and had no contractual requirements for security controls or breach notification timelines.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.4.3
If your application processes payment card data and loads third-party scripts, Requirement 6.4.3 mandates that you "manage all payment page scripts that are loaded and executed in the consumer's browser."
Specifically, you must:
- Maintain an inventory of all scripts (including version identifiers)
- Verify scripts are authorized
- Implement integrity validation using Subresource Integrity (SRI) attributes or Content Security Policy (CSP) with hash validation
- Review scripts before deployment
The AppsFlyer incident demonstrates why this requirement exists. Without SRI validation, your payment pages will execute whatever code the SDK provider delivers—even if that provider is compromised.
OWASP ASVS v4.0.3 Section 14.2
Verification requirement 14.2.3 states: "Verify that if the application uses client-side JavaScript, that the JavaScript does not contain any secrets or keys, and that it is protected from unauthorized modification."
The cryptocurrency theft relied on JavaScript modification. Your CSP headers should include:
Content-Security-Policy: script-src 'self' 'sha256-[hash]';
This prevents execution of any script that doesn't match your approved hash values.
ISO/IEC 27001:2022 Control 5.19 and 5.20
Control 5.19 addresses information security in supplier relationships. You need documented security requirements in your vendor contracts, including:
- Security incident notification timelines
- Right to audit security controls
- Minimum security baseline requirements
- Breach liability terms
Control 5.20 covers addressing information security within supplier agreements. Your AppsFlyer integration agreement should specify SDK integrity verification methods and your right to validate their build pipeline security.
NIST 800-53 Rev 5 SR-3 and SR-4
SR-3 (Supply Chain Controls and Processes) requires you to "employ security safeguards to protect against supply chain threats." For third-party SDKs, this means:
- Maintaining a software bill of materials (SBOM)
- Implementing integrity verification
- Monitoring for unauthorized changes
SR-4 (Provenance) requires you to "document, monitor, and maintain valid provenance of software components." When AppsFlyer's SDK changed, you had no automated way to detect that the provenance was now malicious.
Lessons and Action Items for Your Team
Immediate Actions
Audit your SDK inventory. List every third-party SDK your applications load, the loading method (npm package, CDN script tag, bundled), and the current version. If you used AppsFlyer Web SDK, review your logs from March 9-11 for cryptocurrency-related JavaScript errors or modified clipboard operations.
Implement Subresource Integrity checks. For any SDK loaded via script tag, add SRI attributes:
<script src="https://cdn.example.com/sdk.js"
integrity="sha384-[hash]"
crossorigin="anonymous"></script>
When the SDK provider updates their code, your application will refuse to load it until you update the hash—giving you a manual review gate.
Deploy Content Security Policy headers. Start with report-only mode to identify what's currently executing:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri /csp-reports
Move to enforcement once you've inventoried all legitimate scripts.
Medium-Term Changes
Establish vendor security requirements. Before integrating any SDK, require the vendor to provide:
- SOC 2 Type II report covering their build and release processes
- Incident response contact and notification SLA
- Code signing certificate for SDK artifacts
- Security contact for vulnerability reports
Implement runtime application self-protection (RASP). Tools that monitor JavaScript behavior at runtime can detect when an analytics SDK suddenly starts scanning for cryptocurrency addresses. runtime application self-protection
Create a third-party component response playbook. Document your process for when a vendor announces a compromise:
- Identify affected applications and versions
- Review logs for indicators of compromise
- Communicate with affected users
- Replace or remove the component
- File incident reports required by your compliance frameworks
Strategic Improvements
Shift to self-hosted SDK copies. Instead of loading SDKs from vendor CDNs, download specific versions, verify their integrity, and serve them from your own infrastructure. This adds operational overhead but gives you control over when updates occur.
Require SBOMs from vendors. If the SDK depends on other libraries, you need visibility into the entire dependency tree. Request CycloneDX or SPDX-format SBOMs as part of your procurement process.
Implement automated dependency monitoring. Tools that alert you when third-party code changes help you detect compromises faster than waiting for vendor notifications. automated dependency monitoring
The AppsFlyer incident wasn't an application vulnerability in the traditional sense—it was a trusted supplier becoming an attack vector. Your security controls must account for this reality. The standards already require these protections; now you have a concrete incident to justify the implementation effort to your leadership.
