On March 10, 2026, AppsFlyer’s JavaScript SDK was compromised in an active supply chain attack. If you run an ecommerce site and that script loads on your payment pages, you’ve potentially been serving malicious code to every customer who checked out over the past 72+ hours. No changes to your codebase required. No alerts from your WAF. No red flags on your server logs.
This is actively happening.
And for anyone who’s been wondering why the PCI Security Standards Council added requirements 6.4.3 and 11.6.1 to PCI DSS 4.0.1, this is your answer.
What Happened#
Attackers modified the AppsFlyer JavaScript SDK, a marketing attribution script loaded by thousands of websites across ecommerce, fintech, healthcare, and SaaS. The compromised script includes a multi-layered payload that hooks into browser network requests, monitors DOM input fields in real time, and intercepts data as users interact with the page.
The payload operates as a crypto wallet address swapper, replacing legitimate cryptocurrency addresses with attacker-controlled wallets. But the underlying technique is what matters here: the malicious code uses fetch proxies, XMLHttpRequest patches, and MutationObserver watchers to capture and manipulate anything a user submits through a form field. That includes payment card data on checkout pages.
The attack was identified through community analysis on GitHub and Reddit, with security researchers reverse-engineering the obfuscated payload. AppsFlyer acknowledged a domain availability issue on March 10 through their status page, and Feroot Security published an advisory confirming the compromise.
The Same Attack, Different Vendor#
This attack pattern isn’t new. It’s been hitting ecommerce for nearly a decade, and the playbook barely changes.
British Airways, 2018. Attackers injected 22 lines of malicious JavaScript into a trusted script on the airline’s payment page. The skimmer captured payment card data from roughly 380,000 customers over 15 days. The result was a GDPR fine that initially topped 183 million pounds.
Ticketmaster, 2018. Attackers compromised Inbenta, a third-party chatbot provider whose code ran on Ticketmaster’s checkout pages. The malicious skimmer sat undetected for five months and captured payment data from approximately 40,000 customers.
Newegg, 2018. A skimmer was placed directly on the payment processing page’s source code, exfiltrating card data to a lookalike domain for over a month.
Every one of these follows the same pattern: a third-party script running on a payment page gets weaponized, and the merchant has no visibility into what’s executing in the customer’s browser.
The term “Magecart” originally referred to groups targeting Magento shopping carts, but it’s now shorthand for any web-skimming attack that injects malicious JavaScript to harvest payment data from ecommerce sites. Some attacks are highly targeted. Others take a bulk approach, scanning for misconfigured cloud storage buckets and injecting skimmers into any unprotected JavaScript files they find. A 2019 campaign compromised 17,000 domains in a single operation using that method.
The AppsFlyer incident follows the supply chain variant of this playbook. The merchant doesn’t get breached directly. Instead, a trusted third-party vendor’s script gets poisoned, and every site loading that script becomes a victim without changing a single line of their own code.
This Is Exactly Why 6.4.3 and 11.6.1 Exist#
The PCI Security Standards Council didn’t add these requirements on a whim. They were a direct response to the wave of Magecart and e-skimming attacks that made one thing painfully obvious: traditional server-side security controls can’t see client-side script attacks, let alone stop them.
PCI DSS 4.0.1 Requirement 6.4.3 mandates that all scripts on payment pages are managed through a formal process: each script must be authorized, its integrity must be verified, and a complete inventory must be maintained with written justification for why each script is necessary.
PCI DSS 4.0.1 Requirement 11.6.1 requires change and tamper detection mechanisms that monitor HTTP headers and payment page content as rendered in the consumer’s browser. Alerts must be generated when unauthorized modifications are detected.
Both requirements became mandatory as of April 1, 2025.
Walk through the AppsFlyer scenario: if a merchant loading that SDK on their payment pages had proper 6.4.3 and 11.6.1 controls in place, they would have had three layers of protection working for them.
First, script inventory and authorization (6.4.3). The AppsFlyer SDK would need to be documented in the payment page script inventory with a business justification. A marketing attribution script loading on a checkout page is already a questionable inclusion, and many organizations would catch this during the authorization review. Does a marketing tracking script really need to execute on the page where customers enter their card numbers?
Second, integrity verification (6.4.3). Mechanisms like Subresource Integrity (SRI) hashes or behavioral monitoring would flag that the script’s content had changed from its authorized baseline. The moment attackers modified the SDK, the integrity check would fail.
Third, tamper detection and alerting (11.6.1). Continuous monitoring of the payment page would detect unauthorized changes to scripts and HTTP headers, triggering alerts that let the security team investigate and respond before significant data exposure occurs.
None of these controls require exotic technology. They require discipline, process, and the right tooling.
What Merchants Should Do Right Now#
If you’re running an ecommerce operation and accept card payments online, here’s what you should be doing today, whether or not you use AppsFlyer.
Immediate Response (If You Use AppsFlyer)#
Check every page on your site for the AppsFlyer JavaScript SDK. Don’t just look at marketing pages. Many implementations load the script site-wide, including on checkout and payment flows. If it’s present, remove or block the script immediately until AppsFlyer confirms a clean, verified build.
Review your network traffic logs for the past 72 hours. Look for unexpected outbound data calls, unfamiliar domains, or any traffic patterns that don’t match normal checkout behavior.
If payment data was potentially exposed, notify your security and compliance teams. Depending on your jurisdiction and card brand agreements, you may have regulatory reporting obligations.
Build Your Client-Side Security Program#
Thinking beyond the immediate incident, here’s how merchants should be protecting their ecommerce pages.
Audit your payment page scripts. Document every script that loads on your checkout pages. For each one, ask: is this script necessary for completing a payment transaction? If a marketing, analytics, or tracking script doesn’t need to be on the payment page, move it off. Reducing your script surface area does more to lower your risk than any product you can buy.
Implement Content Security Policy (CSP). CSP headers tell the browser which domains are allowed to serve scripts and where data can flow. A well-configured CSP won’t prevent a compromised first-party or authorized third-party script from executing, but it will block unauthorized scripts from loading and restrict where data can be exfiltrated. Start with Content-Security-Policy-Report-Only to understand your baseline before enforcing.
Use Subresource Integrity (SRI) for static scripts. SRI attributes on script tags let the browser verify that a script’s content matches a known cryptographic hash before executing it. If attackers modify the script at the source (as in the AppsFlyer case), the hash check fails and the browser refuses to run it. SRI works well for versioned, static scripts loaded from CDNs but doesn’t cover dynamically generated scripts.
Deploy a Web Application Firewall (WAF) with client-side protection capabilities. A traditional WAF protects your server-side application. But modern WAF platforms from vendors like Cloudflare (Page Shield), Imperva (Client-Side Protection), and Akamai (Page Integrity Manager) now include client-side monitoring features that inventory scripts, detect behavioral changes, and alert on suspicious activity. Cloudflare’s Page Shield, for example, uses machine learning and threat intelligence to monitor JavaScript dependencies and can map directly to PCI DSS 6.4.3 and 11.6.1 requirements.
Consider dedicated client-side protection solutions. Products like Jscrambler, Feroot PaymentGuard, c/side, and DataStealth focus specifically on client-side security for payment pages. These tools provide continuous script discovery, real-time behavioral monitoring, automated integrity verification, and audit-ready compliance reporting. They go beyond what CSP and SRI can do alone by monitoring actual runtime behavior and detecting when a previously trusted script starts accessing payment fields or making outbound calls it shouldn’t.
Use your CDN’s security features. If you’re behind Cloudflare, Akamai, or Fastly, you likely already have access to features that can help. Edge functions can inject dynamic CSP nonces, bot management can reduce reconnaissance, and origin shielding can limit direct access to your application servers. These aren’t substitutes for proper client-side monitoring, but they add friction that makes exploitation harder.
Process and Governance#
Tools don’t run themselves. You need the process to back them up.
Maintain a living inventory of every script on your payment pages. Review it regularly and force re-authorization when scripts change. Establish a change management process that includes security review for any new third-party script before it touches a payment flow. Run tabletop exercises that walk through an e-skimming scenario from detection through incident response and notification.
And critically, don’t let marketing teams deploy tracking tags on payment pages without security review. One of the most common ways third-party scripts end up on checkout pages is through tag managers that marketing controls independently of engineering and security. Attackers count on that disconnect.
What This Means Going Forward#
The AppsFlyer incident makes something concrete that a lot of security teams still treat as abstract: your attack surface includes every script running in your customer’s browser, even the ones you didn’t write.
PCI DSS 6.4.3 and 11.6.1 exist because a decade of Magecart attacks proved that server-side controls alone weren’t stopping card data theft. These requirements force you to account for what’s actually executing on your payment pages, and that visibility is what separates the merchants who catch a compromise in hours from the ones who find out through a card brand notification weeks later.
The question every merchant should be asking themselves right now isn’t whether they use AppsFlyer. It’s whether they can tell you which scripts ran on their checkout page in the last 24 hours, and whether any of them were modified from their authorized versions.
If you can’t answer that confidently, that’s the gap to close first.
