Vulnerabilities
Drupal Commerce flaw exploited for one-cent orders
CVE-2026-118539 lets unauthenticated attackers place underpaid orders on Drupal Commerce stores. Fixed versions, the order audit and JSON:API advice.
Drupal Commerce Core, the contributed module behind the cart, checkout and order system on more than 42,000 Drupal sites, has an access bypass that attackers are already using. Tracked as CVE-2026-118539 and published as SA-CONTRIB-2026-254 on October 28, the flaw lets an attacker with no account reach routes and entity fields the module should protect. The practical result is an order the store accepts without full payment: merchants have reported orders priced at $0.01, and others with prices that looked normal but were never paid.
Every store on Commerce Core 3.x before 3.3.13, or on any release before 8.x-2.41, is affected regardless of configuration. Drupal rates it "Highly critical", 21 out of 25 on its own scale, and lists an exploit as existing. The fixed releases are 3.3.13 and 8.x-2.41. Patching stops new abuse but does nothing about orders already placed, so the second job is an audit of recent orders before you ship anything else.
How it works
In a normal Drupal Commerce checkout, the customer builds a cart, walks through the checkout steps under /checkout/, and the payment step creates a payment entity (Drupal's record of a charge) before the order is placed. Prices come from the product variation, adjusted only by promotions, taxes and fees the store defines. Staff can override a unit price or add a manual adjustment from the admin order form, and that permission is meant to stay with staff.
Drupal's advisory says the module "doesn't sufficiently protect certain routes and entity fields". That missing authorisation check (CWE-862) means an anonymous visitor can reach some of the operations and fields that should be limited to the checkout flow or to administrators. Drupal and the maintainers at Centarro have not published the exact routes, which is reasonable while exploitation is live.
Centarro does describe what the bypass makes possible. An order can be placed directly without passing the payment step, so it never reaches the checkout's complete step. On headless stores that write Commerce data through JSON:API (Drupal's REST-style interface for decoupled front ends), an order can be marked as paid with no payment entity behind it. An attacker can also change a price before checkout through the "Override the unit price" field, or add discounts and fees that no promotion created. The storefront and JSON:API reach the flaw through different routes, so both kinds of site are exposed.
The weakness is old. According to Centarro, exploitation has been possible since Commerce Core 8.x-2.18, released May 26, 2020, for sites using JSON:API, and since 8.x-2.25, released June 30, 2021, for all other sites.
What attackers are doing
The flaw was reported privately and the fixes were coordinated with the Drupal Security Team before the October 28 release. Centarro wrote on October 29 that two merchants had reported suspicious orders on live sites, and that as of that date neither Centarro nor the Security Team had seen evidence of scripted or wider abuse. The reported orders included obviously wrong prices such as $0.01, alongside orders whose prices looked plausible.
Drupal has not said who is behind the activity, how many stores were hit, or whether it began before the patch. SecurityWeek reported that the method had not been disclosed. As of October 30 the CVE record carried no CVSS score and the flaw was not in CISA's Known Exploited Vulnerabilities catalog, according to Rescana and Brandefense, so do not wait for either before acting. The harm here is to the merchant: goods shipped against orders that were never paid, or paid at a fraction of the price.
What to do
1. Update Commerce Core
Move 3.x sites to 3.3.13, which supports Drupal 10.3 and later and Drupal 11. Sites on the 2.x branch go to 8.x-2.41, which supports Drupal 9.3 and later and Drupal 10. With Composer that is composer require 'drupal/commerce:^3.3' or composer require 'drupal/commerce:^2.41', followed by drush updatedb and a cache rebuild. Afterwards, check the installed version under Reports > Available updates matches the fixed release.
Commerce API, Commerce License, Commerce Shipping and Commerce Stripe received security releases the same day, so update any of them you run in the same change. Commerce Stripe's advisory, SA-CONTRIB-2026-263 (CVE-2026-118558, rated Critical), fixes a cross-site request forgery in the Stripe Connect return URL, where an administrator tricked into clicking a crafted link could mark an order as paid without payment. It affects 2.0.0 up to 2.2.3 and is fixed in 2.2.3.
2. If you cannot update today
Drupal lists no workaround that replaces the upgrade. Two changes reduce the damage until you can. If your site does not need to create or change data through JSON:API, open Configuration > Web services > JSON:API (/admin/config/services/jsonapi) and set it to accept only read operations; Centarro recommends this even after updating. And stop fulfilling orders on the strength of a completed checkout: confirm that the full amount reached your payment provider before anything ships.
3. Audit your orders
Drupal's advisory tells every site to audit orders for inconsistencies. Centarro gives a rubric, from the simplest manipulation to the subtlest:
- Placed orders with a balance due and no pending or authorised payment. If your store does not sell free items, a free order deserves a look too.
- Orders marked as paid that have no payment entities, mainly on sites that write through JSON:API.
- Prices no promotion or adjustment would produce. Check for order items with "Override the unit price" enabled where your staff would not normally use it. On releases before 3.3.0, look on the order edit form for unknown adjustments.
- Discounts, fees or other adjustments that staff did not add and that no promotion created.
Centarro's post includes four SQL queries against the Commerce tables, one per item. The first looks for orders whose checkout step never reached complete, because exploited orders are placed outside checkout. Another searches order and order item adjustments for the custom source ID that the manual adjustment widget assigns. All four also return legitimate results, such as staff-entered orders, orders created by gateway webhooks and donation products, so treat hits as leads.
In the admin console, Commerce > Orders (/admin/commerce/orders) lists orders, and each order's Payments tab should match what your payment provider recorded. For any suspect order, take its IP address and timestamp to your web server access logs and see whether that visitor walked the normal checkout path under /checkout/ or went straight to other endpoints.
4. Clean up what you find
Cancel or hold unpaid orders before fulfilment, and reconcile anything already shipped against your payment provider's records. Remove manual price overrides and adjustments your staff cannot account for. If you find signs of an issue the rubric does not describe, Drupal asks that it be reported through its confidential security process.
Patch the shop like a payment system
Contributed modules on a CMS often get patched on the same monthly cycle as the theme and the analytics script. The Commerce module handles money, and Drupal's contributed security advisories usually come out on Wednesdays, so a store team should read that list every week and put payment modules in the same emergency group as the server operating system. Centarro also points out that 8.x-2.x support ends when Drupal 12 is released, which makes now a good time to plan the move to 3.x.
Our web penetration tests check checkout and order flows for exactly this kind of missing authorisation, including the JSON:API side of headless stores, and our on-demand risk reduction work can help you get an urgent update and audit done this week. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Drupal SA-CONTRIB-2026-254, Drupal SA-CONTRIB-2026-263, Drupal Commerce project page, Centarro, SecurityWeek, Rescana, Brandefense.