If you run a checkout page and haven’t touched your PCI DSS compliance since 2024, there’s a good chance you’re already out of compliance. Two requirements that were “best practice” for three years became mandatory on March 31, 2025, and 2026 is the year assessors are actually enforcing them. They target the exact spot where credit card skimmers live: the JavaScript running on your payment page.
This isn’t theoretical. In January 2026, researchers at Malwarebytes reported an active card-skimming campaign hitting checkout pages tied to American Express, Diners Club, Discover, Mastercard, and other major payment networks, one that had been running undetected since early 2022. The attackers plant JavaScript on the page, it reads the card number and CVC as a shopper types them in, then it ships the data out. Some versions even self-destruct after an admin logs in to investigate, according to Malwarebytes.
What actually changed in PCI DSS 4.0.1
The PCI Security Standards Council added two requirements aimed squarely at this attack pattern: 6.4.3 and 11.6.1. Lauren Holloway, the Council’s Director of Data Security Standards, explained the reasoning on the PCI SSC’s own Coffee with the Council podcast: e-skimming attacks have “increased significantly” as stores lean more on third-party scripts, and browser-side scripts are now “a significant target for attackers seeking to steal payment card data.”
In plain terms, the two rules require:
Requirement 6.4.3: Every script that runs on your payment page has to be inventoried, authorized, and checked for integrity. You need to know what scripts are running and confirm none of them have been tampered with.
Requirement 11.6.1: You need a change and tamper-detection mechanism watching your payment pages, one that alerts you when something changes that shouldn’t have.
These aren’t new ideas. They’ve technically been in the standard since 2022 as forward-looking guidance. What changed is that they’re now required during a real PCI DSS assessment, not optional hardening.
Why this is hitting small stores harder than expected
Magecart-style attacks, named for the loose network of criminal groups that pioneered them, originally targeted Magento stores specifically, which is one reason platform security patches matter so much (our recent piece on a critical Magento flaw is worth a read if you’re on that platform). The technique has since spread to every major e-commerce stack.
Smaller merchants tend to assume a hosted checkout, think Shopify Payments or a payment processor’s embedded iframe, gets them off the hook. That’s partly true, but not automatically. The Council’s guidance clarifies that merchants using Self-Assessment Questionnaire A (SAQ A), the shorter questionnaire for card-not-present merchants who’ve outsourced account data handling, must now confirm their site isn’t susceptible to script-based attacks. That confirmation can come from your payment processor if they’ve implemented the right protections, but you have to actually ask for it and document it. Silence isn’t compliance.
What to actually do this week
You don’t need to become a PCI auditor. You need four concrete things in place.
Get a script inventory. List every script that touches your checkout or payment page, including analytics tags, chat widgets, and ad pixels. If you can’t name what’s running on the page, you can’t meet 6.4.3. This overlaps heavily with the basics in our e-commerce security checklist for small stores.
Add tamper detection. A content security policy (CSP) and a script integrity monitoring tool, several are built for exactly this PCI requirement, will flag unauthorized changes to your payment page automatically. This is the practical answer to 11.6.1.
Ask your processor for written confirmation. If you use a hosted or embedded checkout, get it in writing that their solution protects against script-based skimming when implemented per their instructions. Keep that documentation somewhere you can actually find it during an assessment.
Lock down access and passwords. PCI DSS 4.0.1 also tightened requirements around multi-factor authentication for anyone touching the cardholder data environment and longer passphrases for accounts that don’t support MFA. If your team is still using shared logins and short passwords on your store’s admin panel, that’s a separate hole worth closing, and one we cover in more detail in our piece on passkeys replacing weak passwords. It’s also worth pairing this with checkout-level fraud defenses like the ones in our guide to stopping card testing bots, since skimming and card testing often get lumped into the same conversation with your payment provider.
The takeaway
PCI DSS 4.0.1’s e-skimming rules stopped being a future deadline months ago. They’re the standard now, and active campaigns like the one Malwarebytes flagged in January prove attackers already know most stores haven’t caught up. An afternoon spent inventorying scripts and confirming your processor’s protections in writing is a lot cheaper than explaining a breach to your customers.
Sources
- PCI Security Standards Council, “Coffee with the Council Podcast: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025,” March 26, 2025 (blog.pcisecuritystandards.org)
- Pieter Arntz, Malwarebytes, “Online shoppers at risk as Magecart skimming hits major payment networks,” January 14, 2026 (malwarebytes.com)
Last reviewed: July 23, 2026
Affiliate disclosure: This site may earn a commission from some links at no extra cost to you.
