← All articles

September 4, 2026 · Vedanshu Jain

Is WooCommerce Secure? The Honest Answer and the Checklist Behind It

Is WooCommerce secure? Core is well maintained; the real risk sits in plugins, admin access, and old PHP. Here is the checklist and the PCI reality.

Is WooCommerce secure? Yes — WooCommerce core is actively maintained, runs a public bug bounty, and accounts for a tiny share of WordPress vulnerabilities. The risk lives almost entirely elsewhere: third-party plugins and themes, admin accounts without two-factor authentication, and PHP versions that stopped receiving security fixes years ago. Those are all things you control.

WooCommerce core’s actual security posture

Start with where vulnerabilities are found. In Patchstack’s State of WordPress Security report covering 2024, 7,966 new vulnerabilities were disclosed across the WordPress ecosystem — 96% of them in plugins, 4% in themes, and 7 in WordPress core, none of which posed a widespread threat. The platform is not the problem. The catalog of things bolted onto it is.

WooCommerce itself is developed in the open, ships roughly monthly with patch releases in between, and handles disclosures through Automattic’s HackerOne program with a paid bounty. Its security policy is explicit about support scope: “Generally, only the latest version of WooCommerce has continued support,” with critical fixes sometimes backported (WooCommerce SECURITY.md). WordPress core operates on similar lines, coordinating with hosting providers and security vendors and pushing fixes through automatic background updates (WordPress security page).

The practical reading: staying current is the whole game. An unpatched store is not running WooCommerce’s security posture, it is running a snapshot of it from whenever you last updated.

Where the attack surface really is

Plugins and themes. A typical store runs thirty to sixty extensions, each written by a different team with a different security process. Patchstack found that 33% of 2024’s vulnerabilities were not fixed before public disclosure, and that 1,614 plugins and themes were removed from the WordPress repository over unpatched issues — 1,450 of them carrying high or medium severity. Abandonment is the underrated risk. A plugin with no release in eighteen months is not stable; it is unmaintained.

Admin access. Credential stuffing against wp-login.php is constant, cheap, and automated. Most successful WordPress compromises do not involve an exploit at all — they involve a reused password on an account with full privileges. WordPress’s own hardening guidance covers the basics directly: avoid default usernames, use two-factor authentication, restrict database privileges, set conservative file permissions, and add define( ‘DISALLOW_FILE_EDIT’, true ); so a stolen session cannot edit plugin code from the dashboard (Hardening WordPress).

Outdated PHP. This one is measurable. WordPress.org’s public statistics show 17.16% of WordPress sites on PHP 7.4, 4.11% on 8.0, and 11.51% on 8.1 (WordPress.org PHP stats). Every one of those branches is past its security-support end date — PHP’s own schedule now lists 8.2 and later as the branches still receiving security fixes (php.net supported versions). Add the older 5.x and 7.x branches and roughly 38% of WordPress sites are running an interpreter that will never be patched again. WooCommerce’s stated minimum is now PHP 8.3 or greater with MySQL 8.0 or MariaDB 10.6 (server requirements).

Payment page scripts. The modern card-skimming attack does not steal your database. It injects a script into the checkout page that reads keystrokes before the browser ever talks to the payment processor. That is why the card industry’s rules changed, which is the next section.

Risk, likelihood, mitigation, and who owns it

Risk Likelihood Mitigation Who owns it
Known vulnerability in an installed plugin or theme High Patch within days, subscribe to a vulnerability feed, delete anything unused Store team
Abandoned extension that will never be patched Medium to high Inventory every extension; replace anything with no release in 12 months Store team
Compromised administrator or shop manager account Medium Two-factor on every privileged account, least-privilege roles, no shared logins Store team
PHP branch past security end-of-life High across the ecosystem Run a branch still receiving security fixes; PHP 8.3 or later Host
Skimming script injected into the checkout page Low but severe Hosted payment fields, a strict Content Security Policy, script change detection Store team and payment provider
Brute force and credential stuffing on login and XML-RPC Constant Rate limiting, WAF rules, unique passwords, disable XML-RPC if unused Host and store team
Backup that has never been restored Medium Quarterly restore drill into a staging environment, timed end to end Host and store team
Update applied straight to production Medium Staging that mirrors production, plus rollback in one action Store team; host supplies the tooling
Vulnerability in WordPress or WooCommerce core Low Automatic minor updates on, stay on the current WooCommerce release Store team

Sources: Patchstack, Hardening WordPress, WooCommerce security best practices, php.net.

PCI DSS, without the panic

Nothing about PCI DSS makes WooCommerce non-compliant. What determines your obligation is whether card data touches your servers.

If you use hosted payment fields — Stripe Elements, a redirect to a hosted checkout, PayPal, or any gateway where the card number goes straight from the browser to the processor — the card number never reaches your PHP. Stripe puts the alternative plainly: businesses that handle sensitive card data directly “might be required to meet more than 300 security controls in PCI DSS,” including dedicated hardware, software, and external auditors (Stripe integration security guide). It also confirms that the non-sensitive data returned after a charge — card brand, last four digits, expiry — is outside PCI scope and safe to store.

The rules did tighten in one important way. The PCI Security Standards Council removed requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A, and replaced them with a new eligibility criterion: merchants must confirm their site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” That took effect on 31 March 2025 (PCI SSC). In practice, that means the scripts running on your checkout page are now explicitly your problem, even with a fully outsourced payment form. Know every script on that page, lock it down with a Content Security Policy, and get written confirmation from your payment provider about the protections its embedded solution includes. This is a summary, not legal advice — your acquirer decides which SAQ applies to you.

A hardening checklist you can finish this month

  1. Turn on automatic minor updates for WordPress core, and put WooCommerce and extension updates on a weekly staging-tested cadence.
  2. Delete every deactivated plugin. Deactivated code still sits on disk and can still be reachable.
  3. Audit user accounts. Anyone who does not need to install plugins should not be an administrator; WooCommerce documents role restriction as a first-order control.
  4. Enforce two-factor on every administrator and shop manager account. No exceptions for the founder.
  5. Move to a supported PHP branch and confirm it with your host in writing, including their plan for the next upgrade.
  6. Put a WAF in front of the store with rate limiting on login, checkout, and the REST API, and disable XML-RPC if nothing uses it.
  7. Set a Content Security Policy on the checkout page and alert on any change to the scripts it loads.
  8. Restore a backup. Not verify it — restore it, into staging, and time how long it takes. Repeat quarterly.
  9. Force HTTPS everywhere and keep TLS 1.2 or above, as WooCommerce requires.
  10. Keep an activity log so you can answer “what changed” without guessing.

Most of this is a Tuesday afternoon. The reason stores skip it is not difficulty; it is that nobody owns it.

How Urumi handles this

Urumi is the platform layer for WooCommerce stores doing $1M to $50M GMV, and a good deal of that checklist becomes infrastructure rather than a to-do list. Current PHP on latest-generation Google Cloud CPUs refreshed every cycle, Cloudflare Enterprise delivery in front of the store, isolated staging per branch with CI/CD so no update reaches production untested, one-click rollback, and 30-day point-in-time recovery with off-site backups held in a separate region.

The migration is the part most stores fear, because hardening usually arrives with a demand to drop half the plugins. Do Amore moved to Urumi with a zero-downtime migration and every custom plugin intact. As their founder Krish Himmatramka put it: “With Urumi, we avoided a costly move to Shopify. We get Shopify’s speed and scale while keeping the ease and open-source flexibility of WooCommerce.”

Revenue AI watches checkout, cart, pricing, and payments around the clock and ships fixes as pull requests through your review pipeline, so a regression on the payment path is caught by something that never sleeps. Already have a team or an agency? They ship faster with the grunt work covered. See managed WooCommerce on Urumi.

Frequently asked questions

Is WooCommerce safe for taking credit card payments?

Yes, provided you use a gateway with hosted payment fields so the card number goes from the customer’s browser to the processor without touching your server. That keeps you out of the several hundred controls that apply to merchants who handle card data directly. Since 31 March 2025 you also have to confirm your site is not susceptible to script-based attacks, which makes the scripts on your checkout page part of your compliance picture.

Does WooCommerce get hacked often?

WooCommerce core is rarely the entry point. Across the WordPress ecosystem in 2024, 96% of disclosed vulnerabilities were in plugins and 4% in themes, with only seven in WordPress core. Compromises overwhelmingly start with an unpatched third-party extension or a privileged account without two-factor authentication.

Do I need a security plugin on WooCommerce?

A firewall and malware scanner are worth having, but they are the last layer, not the first. Patching within days of a disclosure, removing unused extensions, enforcing two-factor on admin accounts, and running a supported PHP version prevent far more incidents than any scanner catches. A security plugin on an unpatched store mostly tells you that you were breached.

Is WooCommerce PCI compliant out of the box?

PCI compliance applies to merchants and service providers, not to software, so no plugin can be compliant on its own. WooCommerce lets you build a compliant setup by keeping card data off your servers through a hosted payment integration. Your acquiring bank determines which self-assessment questionnaire you complete.

For what a host should be doing on your behalf, read what managed WooCommerce hosting must include, and for diagnosing problems faster, AI WooCommerce troubleshooting.

Last reviewed September 2026. Competitor details come from their public pages on the dates linked; check them before you buy.

Built by the people who built WooCommerce core.

We built WooCommerce core at Automattic — the parts that matter in production: performance, payments, reliability. Earlier, engineering at HackerRank (Y Combinator) through its enterprise scale-up. Naman led Payments and WooCommerce releases to 4.5M merchants; Vedanshu led HPOS, Taxes, and Shipping. Run by AI, overseen by the people who built WooCommerce core.

Grow your store's revenue on Urumi.

The AI platform D2C brands use to grow revenue — built by the people who built WooCommerce core.

See the WooCommerce platform  ·  Start your WooCommerce store on Urumi  ·  Talk to the founders

Agent live · 99.99% uptime · shipping today.