If your WooCommerce store takes cards through Stripe, open your own checkout in a private browser window today. Security firm Silent Push published research on 13 January 2026 describing a web skimming campaign that hides the real Stripe payment form and swaps in a convincing fake one built inside an iframe. Shoppers type their card number into the fake. The data leaves the page before the order is even placed.
The campaign has been running since at least January 2022, according to Silent Push, and it was still live when their analysts published.
What Silent Push actually found
The investigation started with a single domain, cdn-cookie[.]com, hosted on infrastructure tied to a sanctioned bulletproof host. From there the analysts traced obfuscated JavaScript loading on unrelated web shops running on different platforms, in different countries, with different hosting.
On one live infected store the injected code was loaded through WordPress’s own wp_enqueue_scripts action hook. That is a detail worth pausing on. The attacker was not dropping a file into a random directory. They were using the same mechanism WordPress uses to load legitimate scripts, which makes the injection blend into normal page rendering.
The deobfuscated payload runs to roughly 600 lines of JavaScript. Silent Push documented what it does:
- Watches the page with a MutationObserver so it re-runs after any DOM change
- Waits for WooCommerce to finish loading, then checks whether the shopper selected Stripe
- Hides the genuine Stripe Universal Payment Element form by setting its display to none
- Injects an iframe containing a replica payment form with matching styling and field names
- Formats card numbers and shows the correct card brand image for Mastercard, American Express, JCB, Diners Club, Discover and UnionPay
- Captures every input on the checkout page, not just card data, including name, phone, billing and shipping address
- XOR encrypts the harvested data with the hardcoded key “777”, base64 encodes it, and POSTs it to an external collection endpoint
The fake form even applies red error styling to invalid entries. It behaves like a real payment field because that is the point.
Why the store owner never sees it
Here is the part that should worry anyone who checks their own site by clicking around while logged in.
The skimmer looks for the wpadminbar element in the DOM. If it finds it, meaning a logged-in administrator is viewing the page, the code removes itself entirely and shuts down the MutationObserver. The owner sees a clean checkout. The customer sees the fake.
The evasion continues on the shopper side. After exfiltrating the data, the skimmer deletes the fake form, restores the real Stripe form, sets a localStorage flag so it does not run twice on the same visitor, and simulates a click on the checkout button. The shopper gets a payment error, assumes they fat-fingered the card number, retypes it into the genuine form, and the order goes through normally.
Nobody files a complaint. The order completes. The card is gone.
How to check your checkout in ten minutes
None of this requires a security vendor to spot. Do this today:
1. Log out completely. Use a private window or a browser you never sign into WordPress with. Any check performed while the admin bar is present is worthless against this family of skimmer.
2. Add an item and go to checkout. Open your browser’s developer tools, switch to the Network tab, and reload. Look at every JavaScript file loading on that page and ask where each one comes from. Your payment processor, your analytics, your tag manager. Anything you cannot name is a problem.
3. Check the Initiator column. Silent Push used exactly this to trace the request back to the line of code that triggered it. If a script is being echoed inline by a theme or plugin rather than enqueued as a proper file, look at it closely.
4. Inspect the payment field itself. Right click the card number input. If it sits inside an iframe your processor does not own, stop and call your host.
5. Ask your shoppers. A pattern of “the payment failed the first time but worked on the second try” support emails is not a UX problem. It is the signature described in the Silent Push write-up.
Keeping the underlying platform patched matters too. Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025, a 42 percent increase over the prior year, with 91 percent of them found in plugins rather than core. Skimmers need a way in first, and an unpatched plugin is the usual door. Store owners weighing their infrastructure may find our WooCommerce hosting comparison for growing stores useful, since patching discipline varies enormously between providers. The same pattern played out earlier this year when a critical Magento flaw needed immediate patching.
The compliance side you cannot ignore
Client-side script attacks are not just a security problem now. They are a validation problem.
The PCI Security Standards Council added a new eligibility criterion to SAQ A under PCI DSS v4.0.1, effective 1 April 2025. The wording is blunt: the merchant must have “confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
In a February 2025 post on the PCI Perspectives blog, the Council explained that FAQ 1588 gives merchants two ways to satisfy that criterion. Either apply protective techniques such as those in Requirements 6.4.3 and 11.6.1 yourself or through a third party, or obtain confirmation from your PCI DSS compliant payment provider that their solution, implemented per their instructions, protects your payment page from script attacks.
The Council also noted that this criterion applies specifically to merchants whose page embeds a provider’s payment form, for example through an iframe. Full redirects and fully outsourced payment pages are treated differently.
Translation for a WooCommerce owner running Stripe Elements: you are in scope, and “my processor handles it” is only an answer if you have actually asked your processor and have their confirmation on file. We covered the broader implications in why your checkout page may be breaking PCI rules right now.
What to do this week
Silent Push recommends a Content Security Policy to restrict which external resources a page may load, current patching across CMS and plugins, strong credentials with multi-factor authentication on admin accounts, and periodic review of the site from a logged-out browser session.
Add one more: write down every script that is allowed to run on your checkout page, with a reason for each. You need that inventory for PCI anyway, and it turns “is this script supposed to be here” from a judgment call into a lookup.
The uncomfortable truth in this research is that the attack was designed around WooCommerce and Stripe specifically, not stumbled into. Automated traffic and targeted tooling now treat storefronts as infrastructure to be mapped, a shift we wrote about in why your store is now the internet’s top bot target.
Your checkout looks fine to you. That is exactly what it was built to do.
Sources
- Silent Push, “Silent Push Uncovers New Magecart Network: Disrupting Online Shoppers Worldwide,” 13 January 2026 — silentpush.com/blog/magecart
- PCI Security Standards Council, “FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants,” PCI Perspectives blog, 28 February 2025 — blog.pcisecuritystandards.org
- PCI Security Standards Council, “Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A,” 30 January 2025 — blog.pcisecuritystandards.org
- Patchstack, “State of WordPress Security in 2026” — patchstack.com/whitepaper/state-of-wordpress-security-in-2026
- MDN Web Docs, Content Security Policy guide — developer.mozilla.org
Last reviewed: 28 July 2026.
Affiliate disclosure: this site may earn commissions from links in this article, at no extra cost to you. That never changes which tools or findings we report on.
