Cyber One Solutions logo.
Get Support

Security Advisory

PCI DSS Payment Page Script Rules Are in Effect: A Real Checkout Skimming Attack Shows Why They Exist

Published August 3, 2026 · Cyber One Solutions

PCI DSS Requirements 6.4.3 and 11.6.1 for payment page scripts are in effect, and a real WooCommerce skimming attack shows exactly why they exist.

Two PCI DSS v4.0.1 requirements built specifically to stop online card-data theft, Requirement 6.4.3 for payment page script management and Requirement 11.6.1 for payment page change and tamper detection, became effective on March 31, 2025 for in-scope payment pages and pages that can affect payment security. Applicability still depends on the checkout architecture and validation method, including whether payment content is fully outsourced. Assessment methods that include Requirements 6.4.3 and 11.6.1 evaluate them with no remaining transition period. The January 2025 SAQ A revision removed those requirements from that questionnaire and instead added an e-commerce eligibility criterion for applicable embedded payment pages, so merchants should confirm the correct validation method with their acquirer, payment brand, or Qualified Security Assessor. The PCI Security Standards Council published supplemental guidance on meeting both requirements because, in its own words, scripts running in a shopper's browser are now a significant target for attackers seeking to steal payment card data. For any commercial business that takes card payments through its own checkout page rather than a fully hosted third-party payment form, that guidance is no longer background reading.

The gap these requirements target is not theoretical. In May 2026, researchers at Sansec and reporting from BleepingComputer documented active exploitation of CVE-2026-47100, a flaw in the FunnelKit Funnel Builder plugin for WooCommerce, which was installed on more than 40,000 websites. The missing authorization check let unauthenticated attackers inject a payment card skimmer into vulnerable checkout pages while disguising it as a legitimate Google Tag Manager script. The injected script captured card numbers, CVV codes, and billing addresses as customers typed them in, and Sansec reported the attackers planted the fake analytics script directly in the plugin's own external-scripts setting. WooCommerce core and the payment processor were not the compromised components; the vulnerable FunnelKit plugin was. Its missing authorization check let an attacker store a malicious script in the plugin configuration. That attack path shows why payment-page monitoring must detect unauthorized script changes before customers enter card data.

Why This Matters for Businesses Taking Cards Online

PCI DSS applies to every organization that stores, processes, or transmits cardholder data, regardless of size, and it is enforced by contract through the card brands and your acquiring bank rather than by a government agency. Forensic investigators at SecurityMetrics have reported that across their e-skimming case work, the security failure sat on the merchant's own referring page in every case they examined, not on a malicious script planted at a third-party hosted payment page. That finding matters directly for the small and mid-size e-commerce operations common across our service area, WooCommerce and WordPress-based storefronts, Magento and Adobe Commerce sites, and any professional services firm that added its own online payment or invoicing portal, because it means the exposure usually sits in code the business itself controls or has plugged a third-party marketing script into, not in infrastructure a payment processor is responsible for securing. A confirmed skimming incident can bring an unscheduled forensic investigation at the merchant's expense, increased card-brand fees, and in serious cases a suspension of the ability to process card payments at all, independent of any state breach-notification duties that also apply.

What It Means for Your Obligations

Start with an honest inventory of every script that loads on your payment page, including analytics, chat widgets, and marketing tags, not only scripts your developers wrote. Requirement 6.4.3 expects a documented list of every authorized script with a written business justification for each one, and an unexplained script on that inventory is itself a finding.

Implement a method to confirm the integrity of each authorized script, such as subresource integrity hashes or an equivalent control, so a script cannot be silently modified or swapped without detection.

Deploy the change and tamper detection mechanism Requirement 11.6.1 requires, one that monitors the payment page for added scripts, modified scripts, altered page code, and changes to the security-impacting HTTP headers received by the customer's browser, and generates an alert rather than relying on a general web application firewall to catch it incidentally. The mechanism must run at least once every seven days, or more often if your own targeted risk analysis calls for it.

Extend script governance to your marketing and analytics stack. The FunnelKit incident and similar campaigns succeed precisely because attackers disguise the skimmer as a Google Tag Manager or analytics script that marketing teams and developers already treat as routine and safe.

Patch your e-commerce platform and every plugin or extension on it on a defined, documented cycle, and treat an actively exploited plugin vulnerability like CVE-2026-47100 as an emergency patch rather than something to fold into the next maintenance window.

Keep evidence. A script inventory, integrity-check configuration, tamper-detection alert history, and patch records are what a QSA or your own Self-Assessment Questionnaire response will ask you to produce, and they are far cheaper to maintain continuously than to reconstruct after a card brand or acquiring bank asks questions.

Train the developers and marketing staff who can add scripts to your checkout flow on why an unreviewed tag is a compliance and security event, not a routine deployment.

The Bottom Line

A payment page is only as trustworthy as the scripts running on it, and PCI DSS expects in-scope businesses to know, authorize, and monitor the scripts that affect payment security rather than assume a platform or payment processor handles every responsibility. A current script inventory and tamper-detection log help a business answer an acquiring bank's questions with evidence instead of assumptions. This brief is general security awareness, not a PCI DSS compliance or validation service. Cyber One Solutions does not provide PCI DSS program design, Qualified Security Assessor services, or Attestations of Compliance. Our separately documented IT and security assessments, managed cybersecurity, and website development and maintenance can reduce technical risk, but they do not replace a scoped PCI DSS program or assessment. Your acquiring bank, payment processor, or a Qualified Security Assessor remains the authority on your specific validation requirements.

Sources