We went looking: What Woo has done about security since June

If you run a WooCommerce store, or build for people who do, you’ve seen many security updates from us over the last few months: core patch releases, extension updates, and a PHP advisory. I want to explain why that’s happening, what we’ve been doing, and why I think the result is a stronger platform. 

In short: AI tools have made finding vulnerabilities much easier, for everyone. Researchers are pointing them at our code, but more importantly, so are we. We chose to go looking, and a wave of fixes is keeping WooCommerce a secure platform for your commerce needs.

The rest of this post covers what changed, what we’ve put in place since June, how fixes reach your store now, and what you should do next. If you just want the checklist, skip to What to do now.

AI is making security vulnerabilities easier to find

↑ Back to top

Security has always been important to us at WooCommerce (and our parent company Automattic). Besides maintaining a bounty program via Hacker One, at various points in previous years we’ve also done our own internal security-focused research through the codebase to find and fix vulnerabilities. It is also an important part of every review our code goes through and we have used tools like PHPCS and PHPStan to help with static review around best practices for secure websites.

However, for anyone following the changes AI is bringing to the tech industry, you understand the impact LLM intelligence is having on the security of every piece of software. Over the last year, reports about Woo products through Automattic’s HackerOne program increased roughly nine times. Duplicates jumped as well, which indicates that lots of people are pointing similar AI tools at the same public code, and they’re finding the same things.

We’re not alone. WordPress launched its Core Security Initiative in August in response to an even greater rise in incoming reports, and the wider Open Source world is seeing it too. That attention is one of Open Source’s real strengths. Anyone can read WooCommerce’s code, which means anyone can check it, and right now a lot of people are. Closed-source software has the same kinds of bugs, but fewer people are allowed to look for them and you rarely see the fixes. With open code, problems get found sooner, fixes ship in the open, and anyone can verify what changed.

Two things are worth knowing about that volume. 

First, most of it isn’t urgent: about three quarters of the valid issues we’ve tracked in WooCommerce core since July are Medium or Low severity. These are a class of issues that, on their own, are still valid and need to be addressed, but the vulnerability either requires a specific set of conditions to exist or the impact of an exploit based on it is minor.

Second, every report still needs a person to verify it, fix it, test that there are no undesired side-effects from the fix, and then ship the fix. We’re working on streamlining this process too, but given the importance of WooCommerce as a platform for commerce across hundreds of thousands of stores, it’s important we get things right.

Our scans are finding vulnerabilities before external reports arrive

↑ Back to top

The bigger change over the past year is what we do before anyone reports anything. Security work used to be mostly reactive (outside of regular human review checks on pull requests): a report came in, we fixed it, we shipped it. Since late May, we’ve aggressively switched to a more proactive approach:

• In July we ran a tailored AI-assisted review across a full year of WooCommerce releases to test it against history. This review caught every high-severity issue we already knew about, which gave us the confidence the initial setup could be used more broadly for ongoing detection.
• In August we ran deep scans across the WooCommerce monorepo and the extensions we maintain. These scans flagged roughly 700 potential issues. Raw scanner output always includes false positives, so teams validated each finding and fixed the ones that remained.
• Since August, every merge to WooCommerce core’s trunk and release branches gets an automated security scan with powerful LLM models. Every merge to trunk also gets an AI-powered regression review. Since August, there have been 34 security-related issues surfaced by this scan and of those, 18 turned out to be valid. The regression review has also prevented a large number of flaws from ever getting into a release and we’re currently seeing a 77% valid rate across findings.
• In October we enrolled WooCommerce and an initial batch of our extensions in Anthropic’s OSS Scanner program, and more of our extensions are in line. In the initial batch, Anthropic flagged roughly 200 findings across all the enrolled projects. Within the platform software itself, about 90% were deemed valid after triage, and those fixes are shipping in 11.2.2 and 11.3.1. We’re also looking into other frontier model Open Source programs (when they become available) to supplement our internal scanning work.

As a result of the above efforts, our own scanning and the scanner programs we opted into have turned up more than twice as many valid core issues as external reports have. We’re also increasingly finding things before a report comes in (and closing reports that come in as duplicates of what we’ve already discovered and are addressing). This is a pretty important signal because we’d much rather find a problem in our own scans than in a report.

We’ve also learned that no single scan finds everything. Even if we fix every finding from one pass, the next pass (often with better models, or learning from previous scans and the validation loop) will turn up more — which is why we have automated scans running on our codebases.

AI triages reports, people verify issues and approve fixes

↑ Back to top

The volume of fixes that we’re seeing would typically bury a team that handled every report manually. And based on the latest indicators we see across the industry, this volume is likely to continue to rise in the short term. The latest models are continually getting better than humans at finding arcane and hard-to-spot exploits, sometimes chained together across multiple seemingly-minor flaws to escalate severity, and at a rate that is impossible for humans to keep up with using the processes of six months to a year ago.

This is why our defense has to be powered by LLMs as well. Across Automattic, incoming reports now get an AI first pass assessment within minutes through a specialized tool we’ve built called SentrySift, so people spend their time confirming severity and working with agents to create fixes instead of sorting inboxes. Automation prepares the work. People decide severity, review every fix, and approve anything that goes out. 

Security fixes now ship in dedicated patch releases by default

↑ Back to top

We’re also improving how security fixes ship. Through the summer they mostly rode along with regular releases (outside a few planned patches). That had a cost we didn’t like: if a feature release had an unrelated regression, rolling back a staggered release meant losing the security fixes too — which was problematic because the vulnerabilities have been publicly disclosed already.

Now our default is to give security fixes their own releases:

• Critical and High severity fixes ship in the next patch release on the current released version.
• Medium and Low severity fixes ship in the patch release after the next minor version.

While that’s the new default, it’s not a hard rule. When our testing gives us enough confidence and a fix is important enough, we’ll still ship it in a regular release. WooCommerce 11.2.2 is the first release under this new approach, and 11.3.1 will follow 11.3.0 with the next set. The point is smaller, predictable updates you can apply quickly, separate from new features. 

Extensions get the same attention. We published security updates for Stripe for WooCommerce in August and WooPayments this week. There’s also a new way for those fixes to reach you, covered in the section below.

Under our Security Patch Support Policy, the most severe issues will be considered for backporting to older major versions. Everything else ships in the latest release only. 

Required security updates install automatically on eligible connected stores

↑ Back to top

This change is a really valuable one as a part of providing a great security posture for our merchants. In August we fixed a vulnerability in WooCommerce Subscriptions eight days after our own scanning found it. The fix was ready, but we had no way to get it onto stores that don’t update on their own. All we could do was publish it and ask people to install it.

Starting with WooCommerce 11.2, WooCommerce.com can mark an extension’s security release as required. Connected stores with an active subscription then install it on their next update check, usually within a day, even if auto-updates are turned off. WordPress.org already does this for critical updates on plugins hosted in that directory. WooCommerce only uses it for security fixes, and only after the developer has published the fixed version. A store that’s set up to block automatic updates programmatically can still do so.

This protection is available for all extensions available through the WooCommerce Marketplace, on stores connected to WooCommerce.com with an active subscription. That’s one of the best reasons to buy extensions via the official marketplace and keep that connection in place: when something serious turns up, the fix comes to you instead of waiting for you to notice it.

Your PHP version and hosting need security updates too

↑ Back to top

The PHP security release in October was a good reminder that WooCommerce is one layer of many. Those vulnerabilities affected any server running PHP, and no WooCommerce update could fix them. Stores on Automattic hosting were already protected; everyone else needed their host to act.

PHP versions before 8.2 no longer get security updates from the PHP project. WooCommerce 11.3 adds an admin notice for stores on PHP 7.4 and 8.0, 11.5 is the last release that supports them, and 11.6 (February 2027) requires PHP 8.1 or newer while we recommend 8.3 or newer. Most stores are already there: about 9% of tracked stores run 7.4 or 8.0, and closer to 6% among stores updated in the past year. 

Security fixes take priority, delaying some planned features

↑ Back to top

Right now, validated security work takes priority over everything else on our roadmap, and unfortunately at the moment that does mean some of the work we have planned across our products has been delayed to make room. I think most readers will agree that’s the right trade. Adding new features in the software has no value if you can’t trust that what has already shipped is safe and secure.

What we’re working on now is making the impact of this elevated security challenge something that is routine for us, instead of all hands on deck. We’ve already proven many of the separate pieces work, and we’re continuing to iterate and streamline the gaps that still exist. The goal is simple: make Woo a hard target, without stopping everything else to do it.

What to do now: Update your software, keep extensions connected, and check PHP

↑ Back to top

If you maintain an extension, scan your own code before someone else does. If you distribute your plugin through WordPress.org or WooCommerce.com, you already have scanning against every release.

For merchants managing their own stores, or a developer/agency maintaining stores for clients, the following items are important contributors to a good security posture:

• Keep WooCommerce, your extensions, and WordPress up-to-date. After a security update, check the installed version even if automatic updates are on.
• Buy extensions through the WooCommerce Marketplace, keep your store connected to WooCommerce.com, and keep your subscriptions active, so critical fixes can reach you on their own.
• Check your PHP version under Tools > Site Health > Info > Server, and plan a move to PHP 8.3 or newer. If you’re already on one of Automattic’s hosting options (VIP, Pressable, or WordPress.com), you’re already covered! Otherwise, confirm with your host that they’ve applied the latest PHP security releases.
• Check every site you manage, including publicly accessible staging and development sites. One updated site tells you nothing about the others.
• Test against release candidates so a security patch release is a non-event for your store environments. This includes testing against release candidates of WordPress (did you know WordPress 7.2 Beta 4 is available?).
• Found a vulnerability? Report it privately through Automattic’s HackerOne program (to keep it out of the hands of bad actors), not in a public issue.

To everyone who has reported an issue responsibly this year: thank you. More eyes and faster fixes is how Open Source is supposed to work. Let’s keep this collaboration going.