How Attackers Are Paying $1 for $500 Orders on WooCommerce (CVE-2026-9876)

The WooCommerce Store API is the JSON-driven back end for the newer block-based checkout. When the storefront JavaScript asks for the cart total, the Store API returns a structured object with line items, taxes, and a final total. That total is what the storefront hands to the payment processor -- Stripe, PayPal, whoever -- as the authoritative charge amount.

CVE-2026-9876 is the discovery that, in affected WooCommerce versions, the Store API trusts the client more than it should. The extensions block on the checkout payload can include a previously-computed totals snapshot from an earlier, smaller cart. The server takes it as authoritative and hands the small amount to the payment processor. The attacker pays $1.02 for a $487 order. The shop confirms the order and ships the goods.

This is not a payment-processor bug. Stripe and PayPal charge what WooCommerce tells them to charge. The bug is in the glue between the storefront and the processor, specifically in the assumption that the totals block is server-authoritative. Fixed in WooCommerce 9.6.3 by re-computing the totals server-side before the payment capture call.

What it lets an attacker do

Direct revenue theft. The attacker builds a cart, submits a crafted checkout with a totals block from a smaller cart, and pays a nominal amount. The order confirmation triggers. The fulfillment pipeline ships the goods. By the time anyone reconciles the payment processor against the order database, the goods are gone.

This is industrialized at this point. Sansec saw 2,400 attempts against 160 WooCommerce stores in the first week of the disclosure, with a 14% success rate on unpatched sites. The automation is straightforward: script the checkout flow, substitute the totals block, measure which stores accept it.

Long-tail small merchants are the sweet spot. Enterprise WooCommerce deployments tend to have server-side reconciliation that catches the discrepancy before shipping. Stores running on a hosted plan with default settings and no custom checks do not.

How to tell if you're exposed

Two conditions. First, you run WooCommerce 9.0.0 through 9.6.2. Second, the Store API is enabled (which is the default for the block-based checkout template).

Check the version:

# From wp-admin:
# Plugins -> Installed Plugins -> WooCommerce (version shown next to the plugin name)

# Or from WP-CLI:
wp plugin get woocommerce --field=version

# Or from the public readme (yes, it's world-readable):
curl -s https://yourstore.com/wp-content/plugins/woocommerce/readme.txt | head -20

Check whether the Store API is live:

curl -s https://yourstore.com/wp-json/wc/store/v1/cart | head -50
# A JSON response with "items", "totals", and "extensions" fields means the Store API is exposed.

If both are true, you are exploitable.

What the PoC looks like

The public structure is: build a cart of low-value items, complete the checkout flow via the Store API to capture a valid totals snapshot, then rebuild a larger cart and submit the checkout with the small-cart totals snapshot in the extensions block. Affected versions honour the client-provided totals. Patched versions re-compute server-side and reject the mismatch.

We are not publishing the exploit script. The WooCommerce security advisories feed contains the canonical writeup and the Sansec blog has the industrial-scale reporting.

Our scanner test for this

CELVEX Group runs ZERODAY-2026-0005 -- WooCommerce Store API order total manipulation on every e-commerce scan. The wave-1 probe reads the WooCommerce version from readme.txt and checks whether the Store API responds on /wp-json/wc/store/v1/cart. When both conditions are true against a vulnerable version range, wave 3 runs a safe non-destructive replay test (no actual purchases, no fraudulent totals submitted to a live processor) that confirms whether the checkout endpoint honours a client-supplied totals block. High-severity finding when it triggers.

Module: core/test_catalog/_supplement_zeroday_2026-04-18.py, test_id ZERODAY-2026-0005.

What to do today

1. Upgrade WooCommerce to 9.6.3 or later. This is a standard plugin upgrade. It will require a staging test because WooCommerce minor versions occasionally break theme-specific customizations, but 9.6.3 is a security-only release with a narrow changelog.
2. If you cannot upgrade today, disable the Store API as a compensating control. In wp-config.php: define('WC_STORE_API_ENABLED', false);. This forces your checkout back to the legacy server-rendered path, which re-computes totals server-side regardless of version. Your block-based checkout page will stop working until you upgrade or re-enable -- flag this as a same-day fix.
3. Reconcile the last 90 days. Pull your Stripe / PayPal / Square transaction log, diff it against WooCommerce orders, and flag any order where the charged amount is less than 80% of the order total. That discrepancy threshold catches the fraud pattern without over-flagging legitimate discount codes.