Imagine adding a £200 item to your shopping cart, finding a way into the store's administration pages, and changing the price to £2.
No staff account or stolen password. Just a customer session with access it should never have received.
That's the problem behind CVE-2026-118539, a highly critical access bypass in Drupal Commerce Core.
The vulnerability exposes weaknesses in how Drupal Commerce checks permissions on certain administrative routes and order fields. And according to Drupal's security team, attackers are already exploiting it.
What Is CVE-2026-118539?
Disclosed on 28 October 2026, CVE-2026-118539 affects Commerce Core, a contributed Drupal module used to build online stores.
Commerce Core provides shopping carts, checkout functionality, order management and other features needed to sell products or services.
The vulnerability allows unauthorised users to access functionality that should require additional permissions, potentially enabling changes that financially affect a store.
The two severity ratings use different scoring systems. Drupal's official advisory, SA-CONTRIB-2026-254, rates the issue highly critical and explicitly confirms exploitation.
The Cart Was Yours. The Admin Page Wasn't.
The vulnerability comes down to how Drupal Commerce decides whether somebody has permission to perform an action.
Every online store needs to let customers manage their carts. You should be able to add products, change quantities and remove items before checkout.
Drupal Commerce therefore checks whether an order belongs to the current customer.
For signed-in users, that relationship can be established through their account. For anonymous shoppers, Drupal Commerce can use the customer's session to identify their cart.
That ownership check makes sense for ordinary shopping activity. The problem arose when it was also used to grant access to certain administrative operations.
When Ownership Grants Too Much Access
In vulnerable Commerce Core versions, the cart module's access logic could return an Allowed result when a customer attempted to update an order they owned.
Some administrative routes relied on that result without requiring the additional permission needed to manage store administration pages.
As a result, a shopper could potentially reach staff-only order functionality associated with their own cart.
The issue also involved insufficient field-level restrictions. One particularly important field was the unit price of an order item. Ordinarily, changing a product's price should require appropriate store management permissions.
Through the vulnerable access path, the training scenario demonstrates how an anonymous shopper could reach order-item editing functionality and override the price of an item in their cart.
Check out how one permission mistake gave them control over the price.
How an Anonymous Shopper Reaches Staff-Only Controls
The attack involves a concept called forceful browsing.
This happens when somebody requests a protected page directly rather than navigating through the application's normal interface.
For example, a store might hide its order-management controls from customers while still exposing a vulnerable administrative route.
If the server doesn't enforce the correct permissions, knowing the route may be enough to reach functionality that was intended for staff.
From a Normal Cart to a Manipulated Order
Consider an online retailer selling kitchen equipment. A customer adds a coffee machine to their cart at its advertised price. The application creates a draft order linked to the customer's session, allowing them to manage the cart without signing in.
Under normal circumstances, the customer can change the quantity or remove the product. But the vulnerable Commerce Core installation also permits access to a related administrative order-item form.
The attacker uses that access to change the item's unit price. If the altered price carries through the checkout process, the store could end up processing an order for less than the intended amount.
How Drupal Fixed the Access Bypass
Drupal Commerce released security updates on 28 October 2026. The fix strengthens access controls around the affected routes and entity fields.
Among the changes examined in the TryHackMe room, the patched implementation requires the permission access commerce administration pages for relevant administrative functionality.
It also changes how the cart module responds to update requests involving administration routes. Instead of allowing cart ownership alone to grant that access, the revised behaviour leaves the decision to the appropriate administrative permission checks.
Additional field-access protections restrict changes to sensitive order information, including unit prices.
Check out how one permission mistake gave them control over the price.
How to Spot a Manipulated Order
Drupal's security advisory specifically recommends auditing orders because the vulnerability has been actively exploited.
For store administrators, that means investigating unusual changes rather than assuming every completed checkout represents an authorised purchase.
Look Beyond the Checkout Page
Start with administrative access records. A useful indicator is a request to an order-management page from a session or source that doesn't correspond to an authorised member of staff.
Look for unusual activity involving paths under:
/admin/commerce/orders/
Requests to administrative routes aren't automatically malicious, but they deserve attention when associated with anonymous shoppers or unexpected sessions.
Next, compare the relevant requests with order records. An unexpected unit-price override may indicate that a customer reached functionality they shouldn't have been able to use.
Other findings worth reviewing include:
- Order totals that don't match the expected product prices and authorised adjustments.
- Unit-price overrides without a corresponding legitimate staff action.
- Unexpected order status, ownership or adjustment changes.
- Administrative order requests associated with unauthorised sessions.
Be careful when evaluating individual indicators. A store may legitimately offer discounts, wholesale prices or manual adjustments. An overridden price doesn't automatically prove exploitation.
Look for supporting evidence connecting the change to an unauthorised request or an unexplained modification.
Check Whether the Change Succeeded
One particularly useful distinction is the difference between attempted and successful access.
Application logs may record denied requests without capturing the successful edit that matters. Web server access logs and order records can provide additional evidence.
In the TryHackMe scenario, learners correlate an administrative request with the affected order and item to identify which price was changed.
Patch the Module, Then Audit the Orders
Drupal recommends upgrading Commerce Core to the fixed version for your branch:
Use the official Drupal security advisory to confirm the appropriate release.
After updating, verify that the affected administrative functionality rejects requests from unauthorised users. Then review orders created or modified while the vulnerable version was running.
A patch prevents further exploitation through the corrected code. It doesn't automatically restore a price an attacker may already have changed.
For suspicious orders, preserve the relevant records before making corrections. Check the order details, payment information and associated access activity so the business can determine the appropriate response.
Where necessary, involve the store's operations and payment teams before fulfilling or reversing affected orders.
Find the Price That Shouldn't Have Changed
The Drupal Commerce: CVE-2026-118539 room gives you a vulnerable online storefront to investigate.
You'll explore how Drupal Commerce handles cart ownership and administrative permissions, identify the routes affected by the access bypass and examine how an anonymous shopper can manipulate an order.
Then you'll switch to the defender's perspective, inspect the available logs, trace the suspicious activity to the affected order and verify that the patched version closes the access gap.
It's a useful exercise for anyone learning web application security, access-control vulnerabilities or incident investigation.
Check out how one permission mistake gave them control over the price.
Ayomide Joseph A.
