WooCommerce Vulnerability Statistics 2026: The Latest Security Data

Key WooCommerce Vulnerability Statistics for 2026

The most useful WooCommerce security statistics are the ones with a clearly defined denominator. A raw database total can mean unique advisories, CVEs, patched findings, or the same flaw repeated across multiple supported release branches. The table below keeps those scopes separate. It also includes attack telemetry and wider WordPress ecosystem data because the real WooCommerce attack surface extends beyond the core plugin, but those ecosystem figures are labeled so they are not mistaken for WooCommerce core statistics.

The six numbers worth remembering

7+ million active WooCommerce installations make every broadly exploitable core flaw a high-reach event, although the number of truly affected stores always depends on version, configuration and exposure. 44 and 45 are the two most useful current core-history totals from Wordfence and Patchstack. 127 is WPScan’s raw record count, but it should not be interpreted as 127 unique flaws. 52 release branches needed patches for the March 2026 Store API CSRF issue. 9.55 million blocked requests targeted the old WooPayments CVE-2023-28121 in Q4 2025. Finally, 91% of all WordPress ecosystem vulnerabilities disclosed in 2025 were in plugins, which explains why a WooCommerce store’s extension inventory matters as much as the core plugin itself.

How Many WooCommerce Vulnerabilities Are There?

There is no single defensible answer unless the source and counting method are stated. As of September 3, 2026, four commonly used data sources produce four different totals for WooCommerce core. The spread runs from 33 CVEs in a strict product mapping to 127 raw WPScan records. That does not mean one database is necessarily wrong. Each system has a different purpose. Some count advisories without CVE IDs, some only count CVEs, and some create separate records for one advisory when WooCommerce backports a fix across many supported release branches.

Why WPScan shows 127 records

The March 2026 Store API CSRF issue demonstrates the counting problem better than any abstract explanation. WooCommerce says its engineers produced patches for 52 affected versions or supported release branches after the flaw was reported. The CVE record for CVE-2026-3589 also enumerates 52 affected version ranges. WPScan then surfaces that same CVE repeatedly with different “fixed in” versions, which is useful when a scanner needs to tell a site exactly which branch to update to. It is not useful if a researcher simply copies the 127 headline and calls it 127 separate WooCommerce flaws.

WPScan’s 127 raw records are about 2.9 times Wordfence’s 44 core advisories, but the ratio should not be read as a coverage contest. It is primarily evidence that vulnerability statistics need a methodology statement. For this report, ScanTitan uses Wordfence’s 44-record core history for year and type analysis, Patchstack as a cross-check, WPScan for branch-level remediation data, and CVE records for standardized identifiers.

Why Wordfence and Patchstack differ by one

Wordfence currently lists 44 WooCommerce core vulnerability records while Patchstack lists 45 patched findings. A one-record difference is small compared with the WPScan gap, and it can arise from inclusion rules, advisory timing, findings without CVE IDs, or how combined components such as WooCommerce Blocks are handled. ScanTitan does not force the two feeds into an artificial merged total because doing so would create false precision.

The practical conclusion is simple: cite the source with the number. “WooCommerce has 44 vulnerabilities in the Wordfence database” is defensible. “WooCommerce has exactly 44 vulnerabilities” is not. The same rule applies to broad searches that return hundreds or thousands of records containing the word WooCommerce, because those searches often include payment gateways, themes, product add-ons, multivendor plugins, marketing tools and unrelated extensions rather than the core plugin.

WooCommerce Core Vulnerabilities by Year

Wordfence’s current WooCommerce core history contains 44 records published from 2013 through 2026. ScanTitan grouped those records by the publication year shown in the database. The distribution is not a direct measure of code quality because disclosure volume depends on researcher attention, reporting practices, CVE assignment and product changes. It is still useful for showing when core advisories clustered and for separating long-term history from the much larger third-party extension ecosystem.

2024 produced the largest cluster in the current Wordfence history

Seven of the 44 Wordfence records carry 2024 publication dates, the highest annual count in the current core dataset. Those records include unauthenticated HTML injection, stored and reflected XSS, content injection and CSRF. The 2025 total fell to four, covering information exposure and multiple XSS variants, while the current 2026 Wordfence history contains the Store API CSRF record. That does not prove WooCommerce is becoming safer year by year. Security disclosures arrive unevenly, databases can add older findings later, and a single severe vulnerability can matter more than several low-impact ones.

The more important observation is that WooCommerce core has a comparatively small historical advisory set relative to the size of the surrounding plugin ecosystem. Store owners who only watch the WooCommerce version number miss the payment, shipping, checkout, product-option, membership, invoice, multivendor and theme components that expand the actual attack surface.

Cross-Site Scripting Accounts for Half of Wordfence’s WooCommerce Core History

ScanTitan classified the 44 Wordfence WooCommerce records by the words in their advisory titles. Twenty-two of 44 records, exactly 50%, explicitly name Cross-Site Scripting or XSS. This is a title-level classification, not an official Wordfence category, and some advisories can involve more than one weakness. Even with that limitation, the concentration is large enough to matter.

XSS allows attacker-controlled content to execute in a victim’s browser when an application fails to neutralize untrusted output. In WooCommerce, the impact depends heavily on context. A reflected XSS that requires an administrator to follow a crafted link has a different risk profile from a stored XSS that persists in content and executes when a privileged user opens a page. That is why the most common WordPress vulnerabilities should be prioritized by authentication requirements, user interaction, privilege level and reachable business data rather than by category name alone.

XSS is common, but it is not automatically the most urgent flaw

The 50% figure explains frequency, not priority. WooCommerce’s 2026 CSRF flaw could lead to arbitrary administrator creation under specific conditions, while the 2025 Store API issue could expose guest order details to logged-in customers. Neither has “XSS” in the title, yet both can matter more to a particular store than a low-impact script injection. The same applies to SQL injection, path traversal, object injection, unauthorized order changes and sensitive information exposure present elsewhere in the historical dataset.

This is why ScanTitan’s remediation guidance should not sort WooCommerce findings by CVSS alone. A store should combine technical severity with whether exploitation needs authentication, whether the vulnerable endpoint is public, whether exploit code or attack traffic exists, and what the compromised component can reach. The vulnerability remediation prioritization guide covers that decision model in detail.

The March 2026 WooCommerce Store API Vulnerability in Numbers

On March 2, 2026, WooCommerce disclosed a Store API vulnerability affecting versions 5.4 through 10.5.2. WooCommerce described it as a critical phishing vulnerability because a successful CSRF attack could create an administrator account and potentially give the attacker full site control. The attack required a logged-in administrator to visit a malicious link and only worked under specific browser conditions. WooCommerce said it had no evidence of exploitation outside its security testing program at the time of disclosure.

One flaw required 52 branch-level security patches

The most striking statistic is not the base score. It is the 52 affected release branches WooCommerce patched. WooCommerce worked with the WordPress.org Plugins Team to roll security updates to affected stores, including older supported lines. That backport footprint explains why a vulnerability database designed for scanner remediation may create many records for what humans would call one vulnerability.

The issue also illustrates why “latest version only” is an incomplete way to think about WooCommerce security operations. A large e-commerce platform may support stores pinned to older minor branches because of compatibility requirements. When a high-impact flaw lands, the vendor has to protect those branches without forcing every merchant through a major upgrade at once. For defenders, the action remains simpler: inventory the exact installed version, compare it with the patched release for that branch, then rescan after deployment to verify the vulnerable behavior is gone.

CVSS disagreement shows why severity is not a complete risk model

WPScan lists CVE-2026-3589 at 7.5 High, while Wordfence currently shows 4.3 Medium for its WooCommerce core record. WooCommerce used the word “critical” in its operational advisory because the possible end state was administrator creation and full site control. Those descriptions can coexist because a severity score measures a defined technical vector, while vendor urgency also reflects business impact and the consequences of successful exploitation.

For a store owner, the right question is not “Which score is correct?” It is “Does my site run an affected branch, can an administrator be induced to trigger the request, and what would administrator compromise expose?” WooCommerce said a successful attack could expose order information including names, emails, phone numbers, shipping and billing addresses, payment method types, purchased items and metadata. It explicitly said passwords, credit cards and other financial details were not exposed by this flaw itself.

The December 2025 Store API Data Exposure Vulnerability

Three months before the 2026 CSRF advisory, WooCommerce patched another Store API issue. CVE-2025-15033 affected versions 8.1 through 10.4.2 and could allow a logged-in customer to access order details belonging to guest customers under the vulnerable authorization logic. WooCommerce created patches for 23 affected version branches and again said it had no evidence that the vulnerability had been exploited outside security testing when the advisory was published.

GitHub Security Lab reported the issue to the maintainer on December 18, 2025, and recorded it as fixed with a public WooCommerce blog post on December 22, a four-day coordinated disclosure window. GitHub says an AI agent developed by its Security Lab discovered the issue, with the report submitted by Man Yue Mo and Peter Stöckli.

The 2025 and 2026 advisories show two different Store API failure modes

The December 2025 flaw was a data-authorization problem: a logged-in customer could access arbitrary guest orders by relying on an easily enumerable order ID where stronger order-key validation was missing. The March 2026 flaw was a request-validation problem: malformed Store API batch routing could bypass nonce checks and make an authenticated administrator’s browser perform unintended actions. Both touched the Store API, but they should not be collapsed into one generic “API vulnerability” category.

The comparison is also useful operationally. WooCommerce patched 23 branches for the 2025 disclosure and 52 for the 2026 CSRF disclosure, a 2.26 times larger branch footprint. That does not make the 2026 flaw 2.26 times more severe. It shows how wide the supported-version remediation job was. Teams running headless storefronts or custom checkout integrations should combine component-version monitoring with dedicated API vulnerability scanning instead of assuming a patched WordPress admin means every API path is safe.

WooPayments Exploitation Shows Why Old Vulnerabilities Stay Dangerous

WooCommerce disclosed the flaw in March 2023 after it was found through its HackerOne program. Vulnerable WooPayments versions 4.8.0 through 5.6.1 could allow unauthorized administrator access. Wordfence assigned the authentication bypass and privilege escalation flaw a CVSS 9.8 Critical score. At the time of the July 2023 attack wave, Wordfence said the plugin was installed on more than 600,000 sites.

Attack traffic peaked at 1.3 million requests against 157,000 sites in one day

Wordfence reported that large-scale exploitation started in mid-July 2023 and peaked on July 16 at 1.3 million attacks against 157,000 sites. The campaign included reconnaissance for the WooPayments plugin before the main exploit wave and attempts to create malicious administrator users. This is the kind of evidence that a static CVSS score cannot provide: the vulnerability was not merely theoretically severe; attackers actively searched for installations and used it at scale.

The more surprising data comes later. In Wordfence’s Q3 2025 telemetry, the same 2023 WooPayments vulnerability generated 4,199,069 blocked requests, making it the fifth most-targeted unique vulnerability in that quarter’s top ten. In Q4 2025, blocked requests jumped to 9,548,371, an increase of 127.4% quarter over quarter. These are firewall-blocked requests, not successful compromises, but they show persistent attacker interest more than two years after the patch became available.

Patch age does not make exploit traffic disappear

The Q3 to Q4 comparison exposes one of the most useful lessons in the entire dataset. Attackers do not retire a vulnerability when defenders stop talking about it. They keep probing because forgotten stores, abandoned staging sites, old backups brought online and unmaintained client installations can remain vulnerable for years. Discount Rules for WooCommerce shows the same pattern: Wordfence blocked 2.14 million requests in Q3 2025 and 4.13 million in Q4, a 93.4% increase.

For a small security team, this argues for continuous asset and plugin inventory rather than news-driven patching. A store should know every installed extension and exact version even when the plugin is inactive or the vulnerability is old. ScanTitan’s continuous vulnerability scanning guide explains why rescanning after deployments and new disclosures is more reliable than a quarterly manual check.

WooCommerce Extension Vulnerabilities Expand the Attack Surface

WooCommerce core is only one component in a production store. Payment gateways, product customizers, invoice systems, social login, memberships, wishlists, shipping logic, multivendor marketplaces, analytics and themes all add code that can receive public requests or handle privileged data. This is where broad searches for “WooCommerce vulnerabilities” become misleading: they mix core and extension findings, but they also reveal the scale and diversity of the real attack surface.

The examples below are not WooCommerce core vulnerabilities. They are representative 2025 findings in plugins built for or around WooCommerce, selected to show different exploit paths. The table deliberately uses concrete CVEs instead of vague statements that “plugins are risky.”

File handling and authorization failures deserve special attention

Several high-impact WooCommerce-adjacent findings involve file upload, file move or file inclusion because e-commerce extensions often accept customer-supplied assets, invoices, product customizations or import files. CVE-2025-4403, for example, allowed unauthenticated arbitrary file upload in Drag and Drop Multiple File Upload for WooCommerce up to version 1.1.6 because the plugin did not enforce real extension or MIME validation correctly. Wordfence rated it 9.8 Critical and warned that remote code execution could become possible.

Its earlier CVE-2025-2941 shows how a different file-handling mistake can reach the same end state. An unauthenticated attacker could move arbitrary server files because path validation was insufficient. Wordfence specifically noted that moving a file such as the WordPress configuration file could enable code execution under the right conditions. ScanTitan already has deeper guidance on WordPress file upload vulnerabilities because this class deserves testing beyond a simple plugin-version check.

Extension names can make broad WooCommerce statistics explode

A search for the word “WooCommerce” in a vulnerability database can return thousands of results because plugin names often contain WooCommerce even when Automattic did not develop the component. Wordfence search results include payment gateways, checkout field managers, membership tools, gift cards, social login extensions and many other third-party projects. Broad vendor views can also include official Woo products such as Bookings, Subscriptions, PayPal Payments and Stripe.

That broader ecosystem is security-relevant, but it should be labeled “WooCommerce-related” rather than “WooCommerce core.” This distinction is one of the biggest weaknesses in many WooCommerce security statistics pages. The number gets larger and more dramatic, but the denominator disappears. A useful report tells a merchant whether a figure refers to the core plugin, an official Woo extension, a third-party extension, a Woo-compatible theme or the entire WordPress plugin ecosystem.

The WordPress Plugin Ecosystem Is the Bigger Statistical Context

Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% from 2024. It classified 4,124 findings, or 36%, as serious enough to require its mitigation rules and 1,966, or 17%, as high severity with potential for automated mass exploitation. Most importantly for WooCommerce stores, Patchstack says 91% of new vulnerabilities were found in plugins and 9% in themes; it recorded only six low-priority WordPress core issues.

These numbers are not WooCommerce vulnerability statistics. They are the environment WooCommerce runs inside. They explain why a merchant can run the latest WooCommerce core release and still expose a critical flaw through a checkout add-on or payment extension.

Read More: WordPress Plugin Vulnerability Statistics: What 42,000+ Disclosures Reveal in 2026.

Plugin concentration changes the security job for store owners

A WooCommerce store usually becomes more customized as it grows. Each payment method, shipping provider, tax integration, loyalty system, product designer or subscription feature introduces another component with its own release cadence and security history. Even individual official integrations can have hundreds of thousands of active installations. That creates a supply of high-reach targets for automated scanning when a flaw becomes public.

Patchstack’s broader 2025 dataset also reported that highly exploitable WordPress vulnerabilities increased 113% year over year and that 46% of vulnerabilities did not receive a fix from the developer in time for public disclosure. Those ecosystem figures make plugin selection a security control, not a cosmetic preference. Before installing an extension, check maintenance activity, disclosure history, supported versions and whether a safe patched release actually exists. ScanTitan’s plugin safety checklist and WordPress plugin vulnerability guide cover those checks in more depth.

The strongest WooCommerce security metric is inventory accuracy

Counting global CVEs is useful for research, but a store owner cannot patch a global number. The operational metric that matters is whether the organization has an accurate list of core, plugins, themes and custom components with exact versions. That inventory lets a scanner answer a binary question when a disclosure lands: “Are we affected?”

This is also why version-aware vulnerability scanning has more value than a generic site health score. A scanner should fingerprint the WooCommerce stack, map versions to known CVEs and advisories, test exposed application behavior where appropriate, and attach enough evidence for the owner to remediate confidently. ScanTitan’s WordPress vulnerability scanner is designed around that component-aware model, while the broader website vulnerability scanner covers web application, API and configuration weaknesses beyond WordPress version matching.

WooCommerce Malware Statistics Need a Different Denominator

A vulnerability is a weakness. Malware is evidence that malicious code is present or being delivered. Mixing the two creates bad statistics because a store can have known vulnerabilities without being infected, or it can be infected through stolen credentials, a malicious plugin or a supply-chain event without a public CVE. WooCommerce stores need both vulnerability scanning and compromise detection because the controls answer different questions.

Wordfence documented multiple WooCommerce-focused malware campaigns in 2025. In May, its researchers described formjacking malware that inserted a convincing fake payment form into legitimate WooCommerce checkout flows and exfiltrated captured data to a command-and-control server. In October, Wordfence published another campaign in which a rogue WordPress plugin concealed credit-card skimming payloads inside fake PNG files, hid from privileged users and used multiple persistence and fallback mechanisms.

Checkout malware targets the business process, not just the CMS

The formjacking case is important because the storefront can continue to look functional while customer data is being stolen. A merchant who only checks uptime or the WordPress dashboard may see nothing obviously wrong. The October campaign went further by packaging malicious behavior as a plugin and using fake image files to hide payloads, illustrating why a clean plugin list is not enough if the site is already compromised.

There is also a social-engineering layer. WooCommerce has warned merchants about phishing emails that claim a security vulnerability requires an emergency “security patch” download. The supposed patch is malware. That means a real vulnerability disclosure can itself become bait for a second attack path. Administrators should install updates through trusted WooCommerce or WordPress channels and verify urgent advisories independently before downloading anything from an email.

If a store shows evidence of malicious JavaScript, hidden administrator accounts, unexpected plugin folders or checkout tampering, vulnerability remediation alone is not enough. The incident needs compromise investigation and cleanup. ScanTitan’s hacked WordPress recovery guide and website malware removal service address that post-compromise side separately.

What WooCommerce Vulnerability Statistics Mean for Real Stores

The dataset points to a more practical conclusion than “WooCommerce is insecure.” WooCommerce has a large install base, a visible security-research ecosystem and a long support tail. That combination produces public advisories and a large potential target population. At the same time, the clearest examples of mass exploitation in this report come from an extension, WooPayments, and from older third-party WooCommerce-related plugins rather than from the current WooCommerce core advisory.

The right response is therefore not to avoid WooCommerce. It is to manage the stack as an internet-facing application that processes valuable customer and order data. That means tracking component versions, applying security releases quickly, validating fixes, limiting administrator exposure, securing APIs, monitoring files and checkout behavior, and removing plugins that no longer justify their attack surface.

CVSS alone is a poor patch queue

The 2026 Store API advisory makes the point. WooCommerce called the issue critical because successful exploitation could create an administrator. WPScan rates CVE-2026-3589 at 7.5 High. Wordfence currently shows 4.3 Medium. A team that blindly sorts one vendor’s score column can reach a different priority than a team reading the exploit conditions and business impact.

A better priority model combines five questions: Is the exact vulnerable version installed? Is the affected endpoint or feature reachable? Does exploitation require authentication or user interaction? Is there evidence of active exploitation or public exploit code? What data and privileges sit behind the vulnerable component? A medium-scored authorization flaw on a public checkout flow can be more urgent than a critical issue in an unused component on an isolated staging site.

Attack telemetry should change patch urgency

Wordfence’s Q3 and Q4 2025 numbers show how exploitation data changes the decision. CVE-2023-28121 was already more than two years old, yet blocked requests rose from 4.20 million to 9.55 million in one quarter. That is a strong signal to find any forgotten vulnerable WooPayments instance immediately. It is not evidence that 9.55 million stores were compromised, and it should never be presented that way.

This distinction matters for every security statistic. “Attacks,” “requests,” “detections,” “vulnerabilities,” “affected installations” and “breaches” are different units. High-quality WooCommerce security reporting should state which one is being measured every time.

A Data-Driven WooCommerce Security Process

The statistics support a short operational sequence. These steps are ordered because each one supplies information the next decision needs. A store cannot prioritize a component it has not inventoried, and it should not close a vulnerability ticket until a rescan confirms the fix.

1. Inventory every component. Record the exact WordPress, WooCommerce, plugin, theme and custom-extension versions in production, staging and any externally reachable backup environments. Include inactive plugins because dormant code can still become an exposure if files remain web-accessible.
2. Match versions to current intelligence. Check WooCommerce core and every extension against multiple vulnerability feeds rather than relying on a single total. Use CVE IDs where available, but do not discard advisories merely because a CVE has not been assigned.
3. Prioritize reachable exploit paths. Raise findings that need no authentication, touch checkout or Store API endpoints, expose customer data, allow file upload or code execution, or already show real-world attack traffic. Use CVSS as one input rather than the only input.
4. Patch or mitigate the affected branch. Apply the vendor’s fixed version. If a patch is unavailable or a compatibility freeze prevents immediate deployment, disable the vulnerable feature or component, restrict access, or apply a validated compensating control until the code can be updated safely.
5. Rescan the store after deployment. Confirm that the exact vulnerable version is gone and that the exposed behavior no longer responds. A successful update message in WordPress is not proof that every node, cache, container or cloned environment received the fix.
6. Monitor for compromise indicators. Watch for unexpected administrator accounts, new PHP files, modified checkout JavaScript, unfamiliar plugin directories, suspicious scheduled jobs, outbound connections and order-flow anomalies. A patch closes the entry point; it does not remove malware already planted before the patch.
7. Repeat continuously. Trigger new checks after deployments, extension changes and major vulnerability disclosures. Old CVEs continue to receive millions of exploit requests, so security cannot depend on remembering which news item was important last month.

Final Takeaways

WooCommerce security statistics become useful only after the scope is defined. The current core history sits in the mid-forties in Wordfence and Patchstack, while CVE-only and branch-record databases produce different totals. Half of Wordfence’s 44 core titles explicitly mention XSS, but the most important recent core advisories were Store API flaws involving authorization and request validation. The March 2026 issue alone required patches across 52 supported branches.

The more urgent lesson comes from the extension layer. A 2023 WooPayments flaw still generated 9.55 million blocked requests in Q4 2025, and the broader WordPress ecosystem recorded 11,334 new vulnerabilities in 2025, 91% of them in plugins. WooCommerce stores therefore need more than a current core version. They need an accurate component inventory, continuous vulnerability intelligence, evidence-based prioritization, API testing, malware monitoring and verification that patches actually removed the exposure.

For ScanTitan, that is the security story these numbers support: count less blindly, validate more carefully, and prioritize the vulnerabilities that are reachable on the store you actually run.