CMS Weekend: Drupal Commerce Is Being Exploited, and WordPress Core Has an RCE Drawing 63,000 Attacks a Day

Happy Halloween. Both of the big open source CMS platforms decided to hand out tricks this week. If you run a Drupal store or any WordPress site, this is a patch-before-the-candy situation.

Drupal Commerce: Exploited Now

• The bug: CVE-2026-118539 in Commerce Core, the module behind a lot of Drupal storefronts. It's a missing authorization check that lets attackers bypass access controls on certain routes and entity fields. Drupal calls it "Forceful Browsing" and rates it highly critical.
• Status: Drupal says it is actively exploited in the wild. No details yet on who or how widely.
• Impact: Drupal's own wording is that it "may financially impact the vendor," meaning the store owner. On a commerce module, an access bypass on entity fields is the kind of thing that touches orders, prices and customer data.
• Fix: upgrade to Commerce Core 3.3.13 on the 3.x branch, or 8.x-2.41 on older sites. Check the advisory for anything newer.
• Credit: reported by Dan Puccetti, Marcus Johansson and Robert Snyder.

Not in CISA's KEV catalog as of this writing. Don't wait for it.

WordPress Core: A Race Attackers Are Running Anyway

• The bug: a remote code execution flaw in WordPress core itself, not a plugin, rated CVSS 8.1. No CVE yet.
• How it works: during full-package core upgrades, WordPress unpacks files, including the installer, into a predictable, web-reachable folder under wp-content/upgrade. Hit that installer during the brief upgrade window and you can get code execution. Wordfence says the window lasts only seconds in the lab.
• Affected: WordPress 4.7 through 7.1.3. Fixed in 7.1.4, released October 28.
• Activity: Wordfence blocked 62,969 attempts in 24 hours. The biggest sources hammered small sets of sites for about 14.5 hours, probing paths like setup-config.php, waiting for an upgrade to start.

A race measured in seconds sounds hard to win. Attackers don't care. Polling the same sites for half a day is cheap, and auto-updates make the timing more predictable than you'd think.

The Pattern

Neither of these is exotic. One is a forgotten authorization check. The other is temporary files sitting somewhere the internet can reach. That's most of web security in two bullets. And every public-facing web app is a target the moment a fix is published, because attackers read patch notes faster than most of us schedule maintenance windows.

What To Do

• Drupal Commerce: upgrade today, then review orders, prices and account changes from the last few weeks for anything odd.
• WordPress: confirm you're on 7.1.4 or later, even if you think auto-updates handled it. Then look in your logs for requests to installer paths under wp-content/upgrade and to setup-config.php.
• Put a WAF or virtual patch in front of public CMS sites so you have cover in the gap between disclosure and patch.
• Admin panels don't belong on the open internet. /wp-admin and Drupal's admin routes can sit behind zero trust access for your editors while the public site stays public.

Bottom Line

Two CMS platforms, two different bugs, one lesson: when a web app patch ships, the attack traffic is already on its way. Update before you go trick-or-treating.

Sources: Drupal advisory SA-CONTRIB-2026-254, The Hacker News on Drupal, Security Affairs, WordPress 7.1.4 release, Wordfence, and The Hacker News on WordPress