Drupal Commerce Core Access Bypass Is Being Exploited in the Wild

Online stores running Drupal Commerce are under attack through a highly critical authorization flaw in the Commerce Core module. The Drupal security team has confirmed that the weakness is already being exploited, and patched releases are available for both supported branches.

What happened

The vulnerability, tracked as CVE-2026-118539, is a missing-authorization bug in Commerce Core, the module that gives a Drupal site its shopping cart, checkout flow and the APIs used by decoupled (headless) storefronts. Certain routes and entity fields are not properly protected, so a request that should be rejected can go through. The practical outcome is an access bypass that can hit the merchant directly in the wallet.

Affected versions:

• Commerce Core 2.x (the 8.x-2.x branch), up to and including 2.41
• Commerce Core 3.x, before 3.3.13

No CVSS score has been assigned yet, but the maintainers rate the issue "highly critical", the top rating on Drupal's severity scale. Exploitation in the wild has been confirmed. There is no public detail on who is behind it, how many shops are affected, or what the attackers do once inside.

Why it matters

Commerce modules sit on the money path. An authorization gap in that layer is not an abstract risk: depending on which routes and fields are exposed, an attacker could read or alter orders, tamper with prices and promotions, or reach customer data that normally requires a logged-in account.

This kind of attack is also quiet. There is no malware to detect and no crash to notice, only HTTP requests that look like ordinary shop traffic. If your detection relies on anomalies in server behaviour, an access bypass can run for weeks unnoticed.

Drupal security releases are reverse-engineered quickly. Once a fix is public, the diff tells attackers exactly where to look, which is why the gap between "advisory published" and "mass exploitation" keeps shrinking.

Meanwhile, PHP2Shell is still being probed

The Drupal advisory lands while two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619 (both CVSS 9.2, known together as PHP2Shell), continue to attract exploitation attempts.

As of 25 October, roughly 52% of monitored organisations were still considered significantly exposed, a figure that is trending down but far from zero. Two types of activity stand out: attempts that reproduce the public proof-of-concept chain, and "PHP2Shell"-branded tooling that actually relies on session poisoning plus a separate local file inclusion flaw rather than the PHP bugs themselves.

The good news, for now, is reliability. Triggering memory exhaustion alone does not complete the chain, and differences in PHP builds, memory limits and worker behaviour often break the later stages. The bad news is that opportunistic attackers are actively working to turn public PoCs into dependable tooling, and history says they usually get there.

What to do

1. Patch Commerce Core today. Upgrade 3.x sites to 3.3.13 and 2.x sites to 8.x-2.41. Treat this as an emergency change, not a scheduled one.
2. If you cannot patch immediately, restrict access to Commerce routes at the reverse proxy or WAF, review the permissions assigned to the anonymous and authenticated roles, and consider taking checkout offline for the few hours a deployment needs.
3. Hunt for abuse. Review web logs for unauthenticated or low-privilege requests to order, payment, promotion and product routes, and check for unexpected changes to prices, discounts, orders or customer records.
4. Close the PHP gap too. Confirm the PHP runtime on every web server is at a release that fixes PHP2Shell, and look for any local file inclusion issues in your own code, since that is what some of the real-world tooling leans on.
5. Know every Drupal instance you own. Staging, demo and forgotten marketing sites often run the same Commerce module with none of the production hardening.

Flaws like CVE-2026-118539 are exactly what our vulnerability scanning is built to surface: it identifies outdated Drupal cores and contributed modules across your public hosts, so a vulnerable checkout gets flagged before someone else finds it.