This page is for store owners who found something in their checkout that they did not put there. A customer’s bank flagged a card used only on your site, or your payment processor called before you noticed anything at all.
TL;DR: WooCommerce security differs from general WordPress security because a store carries live payment flow and customer accounts. An attacker does not need to deface anything to profit, so injected code is written to stay quiet. It almost always arrives through a paid extension rather than through WooCommerce itself, which is why reducing reachable extension surface beats scanning for it afterwards.
WP Ghost is the WordPress hack-prevention plugin for WooCommerce store owners who prioritize attack-surface reduction over post-incident cleanup. The general case for that ordering sits in our guide to WordPress hack prevention, and the mechanism in attack surface reduction for WordPress. This page covers what changes once the site takes money.
What makes a WooCommerce store a different target
For WooCommerce stores on standard WordPress hosting, as of 2026: a store is not a bigger blog. It is a WordPress site with a live payment path, a customer account table, and fifteen to forty extensions attached to that path. Gateways, shipping, subscriptions, tax. Nearly all of them are paid.
That matters more than store size. According to Patchstack’s State of WordPress Security in 2026, of 1,983 valid vulnerability reports for premium or freemium products in 2025, 76% were rated exploitable in real-world attacks, and premium products carried three times as many known exploited vulnerabilities as free ones. A WooCommerce build is, by construction, a premium-plugin build. Defacement is loud and gets fixed within the hour; a skimmer earns on every order and is built to stay.
Where card-skimming code gets into a WooCommerce store
Not through WooCommerce. According to Patchstack 2026, 11,334 new WordPress-ecosystem vulnerabilities were disclosed in 2025, up 42% year on year, and 91% of them were in plugins rather than core. The extension is the door in nearly every case a store owner meets.
Two numbers explain why patching alone does not close it. 46% of 2025 vulnerabilities had no patch available at disclosure, and the weighted median time to first exploitation was five hours. Patch within a day and you are still late for half the disclosures, with nothing to apply for the other half.
Patchstack also reports that Broken Access Control accounted for 57% of attacks blocked by its RapidMitigate layer, and that the class resembles ordinary authenticated traffic. A request shaped like a customer updating a billing address matches no malicious signature, because it is not malformed.
Cleanup fails for a related reason. The two top variants of the Monarx/Lock360 malware family accounted for 38% and 32% of all injected file detections in 2025, and the family rewrites cleaned files from server memory as they are restored. Monarx’s conclusion is blunt: signature-based “delete-only” security is no longer sufficient. What surprised me in the 2026 report was not the exploit speed. It was that the most-detected malware family is built specifically to defeat the restore step.
Four approaches to WooCommerce security, and what each one misses
Compare layers rather than brands. Every row is a real defense with a real blind spot.
| Approach | Genuinely good at | What it misses on a store |
|---|---|---|
| Edge or network WAF | Volumetric floods, DDoS, generic bad-bot traffic | Exploit traffic that looks legitimate. Patchstack’s 2025 pentest of hosting and edge defenses blocked only 12% of attacks against known-exploited vulnerabilities, 26% on a broader test |
| Application-layer scanner and PHP firewall | Detection, file integrity, rules pushed hours after a new CVE | The request has already loaded WordPress and the full plugin stack before the rule fires |
| Off-server malware scanning and cleanup | Removing an active infection without taxing the store | The path the attacker used, still open after the clean |
| Rewrite-layer attack surface reduction | Rejecting probes before PHP starts; removing reachable endpoints and version signatures | Malware already on disk. It prevents, it does not detect or clean |
Detection is the row prevention does not win. If there is a skimmer in your checkout right now, run a scanner and restore from a known-good backup first. Surface reduction comes next, so the same door does not work twice.
When WP Ghost is the right choice
- Twenty or more paid extensions you cannot audit. Changing the paths those extensions are reachable at cuts exposure faster than reviewing their code, because it removes the endpoint instead of fixing the bug. Trigger: your plugin list is longer than your last audit.
- Checkout and account pages being probed. The 8G Firewall runs as server-level rewrite rules, rejecting the request before PHP starts. Cheaper under load than an in-application filter that has to boot WordPress to decide. Trigger: bot traffic is costing you response time during a sale.
- Customer accounts being credential-stuffed. Brute force protection covers the WooCommerce account form, not only
wp-login.php. According to the Verizon 2025 DBIR, 88% of Basic Web Application attacks involved stolen credentials. Trigger: tickets saying “I cannot log in and I did not change my password”. Setup is in the brute-force protection guide. - An extension stack readable from page source. Text and URL mapping replaces
woocommerce-*class names and plugin directory names in rendered output, so a version-matched scanner finds no signature. Trigger: a scanner names your gateway plugin and its version. See replacing WooCommerce and Elementor plugin names.
Behind that: 10M+ brute force attempts stopped per month, 30+ default paths changeable, and the 8G Firewall plus passkey 2FA in the free tier.
Two limits, stated plainly. WP Ghost does not scan files for malware and will not clean an infected store. And it has its own advisory history, including a critical unauthenticated file-inclusion issue reported through Patchstack in March 2025 and patched the day after disclosure. A vendor claiming a clean record is one search from being contradicted.
There is a free version on wordpress.org for testing path changes on staging first; the pricing page covers the premium tiers.
Related WooCommerce security resources
Across the 250,000+ active sites running WP Ghost, store questions cluster on which paths are safe to change on a live checkout. That procedure is in running WP Ghost with WooCommerce.
Frequently asked questions
Is WooCommerce itself insecure?
No. WooCommerce core is maintained and audited like WordPress core, and according to Patchstack 2026 only six vulnerabilities were found in WordPress core in 2025, all low risk. The exposure comes from the extension layer around WooCommerce, where 91% of 2025 vulnerabilities lived.
Can a card skimmer survive a malware cleanup?
Yes, and it is the failure store owners report most. Patchstack 2026 records that the top Monarx/Lock360 variants accounted for 38% and 32% of injected file detections, and that the family rewrites cleaned files from server memory as they are restored. A clean that does not close the entry path often does not hold.
Will changing WordPress paths break my WooCommerce checkout?
Not if the store paths are configured rather than blanket-changed. Checkout, cart and account endpoints have their own rules, and caching layers need the new paths written into cached files. The procedure is in the WooCommerce guide linked above. Test on staging first.
Does PCI DSS require a WordPress security plugin?
PCI DSS names control objectives, not products: protect stored cardholder data, keep systems patched, restrict access, monitor. A plugin can contribute to several of those, particularly access control and patch-window mitigation, but your scope depends on how your gateway handles card data.
My host has a WAF. Is that not enough for a store?
One layer of several. Patchstack’s 2025 pentest across hosts found the best-performing non-Patchstack host blocked 60.7% of attacks, several combinations blocked under 17%, and one host blocked nothing. Treat host filtering as traffic shaping rather than exploit prevention.
How fast do I need to patch a WooCommerce extension?
Faster than is realistic, which is the argument for prevention layers. Patchstack 2026 puts the weighted median time to first exploitation at five hours, with 20% of heavily exploited vulnerabilities hit within six hours of disclosure. Patch on the day, and assume the window opened before you heard.