Stripe for WooCommerce Adaptive Pricing Patch: Update Now

Payment gateway advisories are the ones I read on the day they land, not the ones I let queue up in a “review later” folder. A checkout that undercharges is a bug on your P&L. A checkout that overcharges is a bug on your reputation. Neither waits for the next sprint.

Stripe for WooCommerce just shipped a patch for exactly that shape of bug, and if you run any B2C store that sells across borders you are in scope. The trigger is not exotic: it is the Adaptive Pricing feature that Stripe quietly turned on by default in 10.8. If nobody on your team switched it off, it is on.

Below is what actually happened, why it matters more than a generic “update your plugin” nag, and the exact call I would make on a client store this afternoon.

What is actually new

On July 14, 2026 the WooCommerce Developer Blog published a dev advisory by Brent MacKinnon titled “Stripe for WooCommerce payment validation issue patched”. The vulnerability was reported through HackerOne by a researcher credited as e0x1337 and was fixed in three parallel patch releases:

• 10.6.0–10.6.1 → patched in 10.6.2
• 10.7.0 → patched in 10.7.1
• 10.8.0–10.8.3 → patched in 10.8.4

The advisory language is precise and worth quoting: “A payment validation issue was identified in Stripe for WooCommerce when Adaptive Pricing is enabled. Under certain conditions, the payment amount processed by Stripe could differ from the WooCommerce order total.” In plain English: the amount your customer actually paid on Stripe’s side and the amount your WooCommerce order recorded could be two different numbers. Reconciliation nightmare, and depending on which direction it drifted, either a silent write-off or an angry chargeback.

The exposure is much broader on the 10.8.x line because as of Stripe for WooCommerce 10.8.0 Adaptive Pricing is enabled by default for all eligible merchants. “Eligible” is a low bar: Optimized Checkout Suite active, manual capture off, Stripe account in a supported country (India is the only excluded market at the moment), and store currency matching payout currency. If you connected or upgraded a store on the 10.8.x line and did not explicitly disable Adaptive Pricing, it is on, quietly showing international shoppers converted prices at checkout.

Two things worth clarifying about scope. First, this is a payment-validation bug, not an authentication bypass. Reports elsewhere reference CVE-2026-2381, which is a separate, older auth issue. This July 14 advisory does not carry a CVE identifier of its own. Second, it is a Stripe-plugin-specific issue: WooCommerce Payments, PayPal Payments, and other gateways are not affected. The failure mode is the currency conversion path that Adaptive Pricing introduces between the Stripe charge and the WooCommerce order total.

Timing is the part that makes this a today problem rather than a next-sprint problem. WooCommerce 11.0 ships on July 28, 2026, and WordPress 7.1 Beta 1 lands today, July 15. Every serious store owner has an upgrade window opening up in the next two weeks. Do not walk into it with a known-bad payment gateway on production.

Why it matters for WordPress and WooCommerce people

The advisory reads like a small dot release, and mechanically it is. Practically, this is one of the more consequential Stripe patches of the year for three reasons.

The default flipped without most operators noticing. Adaptive Pricing existed for years as an opt-in Optimized Checkout Suite feature. Stripe for WooCommerce 10.8.0 turned it on by default for eligible merchants. That is a legitimate product decision — local-currency checkouts convert better on cross-border traffic — but it means a lot of stores are running a currency-conversion pipeline they never consciously enabled. When a bug lives in that pipeline, the blast radius is much larger than the number of stores that actively configured it.

Payment-total mismatches survive on a store for weeks unnoticed. Nobody reconciles Stripe against WooCommerce daily. Most agencies do it monthly, some quarterly, some never. A £49.00 order that Stripe actually captured as £48.87 because of a rounding edge in the converted amount does not fire an alarm. It sits in the ledger, and by the time the finance team asks why totals do not line up, the exposure window covers hundreds or thousands of orders. This is the class of bug that quietly rots numbers you rely on.

The upgrade window is already tight. Between WordPress 7.0.1 last week, WooCommerce 11.0 on July 28, and WordPress 7.1 in mid-August, agencies are stacking staging cycles. If you push Stripe 10.8.4 into that queue behind “when we get to it”, you will get to it in September. Meanwhile the affected code stays live on production. Payment security patches jump to the front of the queue, always.

There is also a governance lesson underneath. This is exactly the kind of bug WordPress and the WooCommerce ecosystem catch and disclose quickly precisely because there is a mature reporting channel: HackerOne coordinated disclosure, official developer-blog advisory, three parallel patches across the supported release lines instead of forcing everyone to jump to latest. That maturity is worth naming. It is one of the reasons I keep clients on WordPress and Stripe rather than on hosted checkout SaaS that ships a hotfix on their timeline, not yours.

What I would do (or not do) about it

Concrete plan for today, in the order I would run it on a client store:

• Check installed version now. wp plugin get woocommerce-gateway-stripe --field=version over SSH, or Plugins screen in wp-admin. If it is 10.6.0, 10.6.1, 10.7.0, or anything on 10.8.0 through 10.8.3, you are exposed.
• Update on the same release line. The Developer Blog patched three lines on purpose — do not use this as an excuse to jump from 10.6.x straight to 10.8.4 unless you have already validated the intermediate breaking changes. On 10.6.x, go to 10.6.2. On 10.7.x, go to 10.7.1. On 10.8.x, go to 10.8.4.
• If you cannot update within the hour, disable Adaptive Pricing. The advisory says so explicitly: “temporarily disable Adaptive Pricing until the extension can be updated.” That single toggle removes the trigger. WooCommerce > Settings > Payments > Stripe > Optimized Checkout Suite > Adaptive Pricing → off.
• Run a reconciliation pass on orders since your upgrade to 10.8.x. Export WooCommerce orders and cross-check totals against Stripe’s charge amount converted back to store currency. Any store on 10.8.0 (released with Adaptive Pricing on by default) needs this done — treat May–July as the working window and go wider if you upgraded early.
• Do this on production before you touch WooCommerce 11.0 staging. Two weeks from now the whole team is heads-down on the 11.0 upgrade. Fix the known-bad first.

What I would not do: I would not switch payment gateway over this. Stripe caught it, disclosed it, patched three release lines the same day. That is the process working. I also would not treat the workaround (disable Adaptive Pricing) as a permanent fix — the feature does earn its keep on cross-border conversion, and once you are on 10.6.2 / 10.7.1 / 10.8.4 there is no reason to keep it off.

Update the plugin, run the ledger check, keep moving. The rest of July is going to be busy enough.