WooCommerce 11.2.2 was released on 4 November 2026 as a security release, and the WooCommerce developer blog recommends updating as soon as possible. The release also changes how checkout behaves when something goes wrong while an order is being saved, so it deserves a checkout test, not just a click on “Update now”. If you run WooPayments, there is a second, separate security update to check.
The facts below come from the WooCommerce developer blog, the WordPress.org plugin API and the plugin changelog, read on 5 November 2026. Recheck them if you are reading later, because point releases can follow.
What the WooCommerce 11.2.2 security update changes
The 11.2.2 release notes flag the release as a security update that includes a database update. The published changelog is a list of hardening fixes. It does not include CVE identifiers or severity ratings, and I could not find any statement about active exploitation, so I will not characterize how serious any single item is. The items fall into a few groups:
- Cart and Store API: the quantity is now validated when a cart item is updated through the Store API, attributes a product does not use are ignored when a shopper adds it to the cart, and a chosen shipping method is only used if its rate was calculated for that cart.
- Checkout: each Store API checkout request now starts with its own order and payment data, and checkout no longer continues to payment when the order could not be saved. Phone numbers over 100 characters are rejected.
- Authentication and admin endpoints: REST API key authentication is restricted to REST API requests, and two Jetpack connection endpoints used during onboarding now need a logged-in administrator browser session.
- Data handling: the product CSV importer validates its column mapping more strictly, unexpected payment settings profile data is handled more safely, and custom default attribute values are kept intact when a global attribute term slug is renamed. The database update cleans up data affected by that last issue.
- PayPal Standard: shipping address updates now recalculate shipping and tax correctly.
You can read the same list in the plugin changelog on WordPress.org. WordPress.org showed 11.2.2 as the current version, requiring PHP 7.4 and tested up to WordPress 7.1.4.
The checkout behavior change worth knowing about
One line in the release notes matters more to developers than to store owners. If a callback attached to woocommerce_before_order_object_save, woocommerce_new_order or woocommerce_update_order throws an exception during a Store API checkout, checkout now returns a 500 error. Before 11.2.2, checkout carried on with a partially saved order. The notes add that save() itself still does not throw.
In plain terms: code that used to fail quietly during checkout may now fail loudly. That is the safer outcome, since a half-saved order that proceeds to payment is worse than an error, but it changes what a store owner sees. A custom snippet, a theme function or an integration plugin that throws on a rare order (a missing field, an unexpected shipping method, a timeout talking to a CRM) could turn into failed checkouts for that kind of order.
I would not read this as a reason to delay the update. I would read it as a reason to test checkout on staging first, with the orders your store actually gets, and to look at your PHP error log afterwards. If checkout fails after updating, the approach in finding a plugin conflict without taking the live site down narrows it to a plugin without making the live store less stable.
For agencies and extension authors, this is also a prompt to grep your own code for those three hooks and check that nothing in them can throw. The release notes do not say how many extensions are affected, and I have not tested any, so treat that as a review task, not a known problem.
WooPayments has a separate security update
On 3 November, the WooCommerce developer blog published a security update for WooPayments. It says the update addresses a security issue in the subscriptions functionality bundled with WooPayments, and links to the earlier WooCommerce Subscriptions security update from 5 August 2026, which asked users to update to Subscriptions 9.1.0 or later. The WooPayments post does not describe the vulnerability, give a severity, or mention exploitation.
The practical part is a version table. The post maps each WooPayments release line to a fixed release, for example 11.2.0 to 11.2.1, 11.1.0 to 11.1.1 and 11.0.0 or 11.0.1 to 11.0.2, and says anything older than 9.0.0 should go to 11.2.1. WordPress.org showed WooPayments 11.2.1 as current, published on 3 November.
A trap here: WooPayments 11.2.1 and WooCommerce 11.2.1 are different plugins with different release dates. WooCommerce 11.2.1 came out on 9 October. If you are comparing version numbers from memory, you can easily conclude that you are already patched when you are not.
The post also says to check the installed version even if automatic updates are on, and that a completed update on one site does not confirm the status of another, including staging and development copies.
Who is affected, and who may not be
- Every store on WooCommerce below 11.2.2 has the unfixed code. Whether a given hardening item is reachable on your store depends on your setup, such as whether you use the Store API checkout, local pickup, the product CSV importer or PayPal Standard. The release notes do not say how any of these were found, so I would not rank them.
- Stores without WooPayments can ignore that section. Check Plugins > Installed Plugins and look for it, including on staging.
- Stores on older WooCommerce lines: the release notes I read do not describe backports. If you cannot move to the current line, ask your host or developer what the plan is rather than assuming an old version is covered.
A short, safe update routine
- Back up first and make sure the backup can be restored. A database update is part of this release, so a files-only backup is not enough.
- Update staging first if you have it, and run the database update if WooCommerce prompts for it, letting it finish before you test. Place a test order for each payment method and shipping method you offer, plus one with a coupon and one for a logged-in customer.
- Update WooCommerce, then WooPayments, in separate steps, so that a failure points to one change. The staging workflow for WooCommerce updates has the longer version.
- Confirm the versions afterwards: WooCommerce 11.2.2 or later, and WooPayments at the fixed release for your line.
- Check the PHP error log and the order list for the next day or two, including failed or missing orders and customer emails.
If you are also behind on core, the WordPress 7.1.4 security update checklist covers that side. None of this guarantees a store cannot be attacked, and an update will not remove anyone who is already inside. If you see unfamiliar admin users or odd files, treat it as a possible compromise and start with what to do in the first hour if WordPress is hacked.
What to watch next
WooCommerce 11.3 is in beta according to the developer blog, with its own notes for developers: the deprecated MCP endpoint is removed, and extensions can declare parent-child cart item relationships. I have not read those posts closely enough to advise on them yet, and no release date was stated on the pages I saw. If you maintain integrations, put them on your reading list.
If you want someone else to sequence the updates, test checkout and send you a written result, the Care Plan below covers that. If you suspect an existing plugin or custom code is already interfering with checkout, a WooCommerce Store Audit is the more direct starting point.