WAF Watch: Drupal Commerce exploited for fraudulent orders, an unauthenticated RCE in WP Project Manager, and Leipzig University goes dark

(opens in a new tab)Mac Clark (opens in a new tab) · November 2, 2026

A short roundup of what hit websites this past week, and what to do about it if you run campus or agency sites.

ProtectMyWebsite is the WAF that tells you what’s safe to block: rules start in count, then your dashboard shows what to promote. You still decide.

1. Drupal Commerce Core — an access bypass being used to place fraudulent orders

On October 28 the Drupal Security Team rated Commerce Core (SA-CONTRIB-2026-254, CVE-2026-118539) highly critical and said plainly: "This vulnerability is being actively exploited in the wild." The module doesn’t sufficiently protect certain routes and entity fields, which lets an anonymous visitor manipulate orders in ways that can cost the merchant money. Affected: everything before 8.x-2.41, and 3.0.0 through 3.3.12. Fixed in 3.3.13 and 8.x-2.41.

The Commerce maintainers at Centarro say the reports came from merchants who saw suspicious orders on live sites: orders placed but never paid, orders marked paid with no payment behind them, and prices changed before checkout (one example was $0.01). They don’t currently believe the attack was scripted beyond the first sites. Exposure goes back years: since 8.x-2.18 (May 2020) on sites using JSON:API, and since 8.x-2.25 (June 2021) for everyone else. Companion fixes shipped the same day for Commerce API, Commerce License, Commerce Shipping, and Commerce Stripe.

Campus/agency angle: Drupal Commerce often sits under the parts of a university site that take money: campus stores, event and conference registration, continuing-ed enrollment, parking or permit fees. Those are usually run by a department, not central IT.

Do this: Update Commerce Core and all the Commerce companions together. Then audit recent orders. Centarro’s post includes SQL queries for orders placed outside checkout with a balance due, "paid" totals that exceed recorded payments, overridden unit prices, and manually added adjustments. If your site doesn’t need to write through JSON:API, switch it back to read-only. And don’t fulfill anything on checkout completion alone; confirm payment first.

SA-CONTRIB-2026-254 · Centarro maintainer guidance (Oct 29) · BleepingComputer (Oct 30)

2. The rest of Drupal’s October 28 batch — CAPTCHA, Stage File Proxy, and an RCE in Single Content Sync

Commerce was one of 21 contributed-module advisories that Wednesday, carrying 39 separate fixes, with nothing for core. Drupal says October was its busiest month on record, at 106 advisories. The ones most likely to be on a campus or agency site:

CAPTCHA (SA-CONTRIB-2026-281, about 276,000 sites): a solved CAPTCHA wasn’t fully invalidated, so a protected form can be resubmitted without a new challenge. That weakens protection against spam registrations, comment spam, and login brute-forcing, and Drupal’s risk score marks an exploit as existing. Fixed in 2.0.11 and 8.x-1.18.
Stage File Proxy (SA-CONTRIB-2026-286, about 27,000 sites): a cross-site scripting path in its 404 fallback. Fixed in 4.0.1 and 3.1.7. It’s a development helper, so it probably shouldn’t be on production at all.
Single Content Sync (SA-CONTRIB-2026-275): a crafted import file can lead to remote code execution, though the attacker needs the import permission. Fixed in 1.4.19.
Field Permissions (SA-CONTRIB-2026-289, about 78,000 sites): "Private" fields on entities without an owner could be viewed, and in some cases edited, by anyone. Fixed in 8.x-1.6.
OAuth Login – OAuth OIDC SSO (SA-CONTRIB-2026-284): an unprotected test route and missing email-verification checks could let someone log in as an existing user whose email they know. Fixed in 3.1.1.
Three modules were marked unsupported with no fix (CacheFlush, GroupEx PRO, PayUmoney). Remove or replace them.

Do this: composer outdated "drupal/*" on every site and multisite child. Patch CAPTCHA quickly on any public registration or login form, and pull Stage File Proxy off production. Drupal 10 still reaches end of life on December 9, 2026.

Drupal security advisories · SA-CONTRIB-2026-281 (CAPTCHA) · Drupal: 256 advisories in five months · RescuePHP roundup

3. WP Project Manager — unauthenticated remote code execution, CVSS 9.8

On October 30 Wordfence disclosed CVE-2026-116512 in weDevs’ WP Project Manager plugin (wedevs-project-manager, 5,000+ active installs). In versions up to 4.1.1, an unsanitized id parameter on a REST route gets turned into PHP function calls, and because WordPress runs the route’s validation callback before its permission check, the plugin’s authorization never gets a chance to stop it. No login is needed. Version 4.1.2, released October 29, fixes it.

Exploitation reports are mixed: one commercial threat feed lists it as exploited since October 30, while CISA’s Known Exploited Vulnerabilities catalog doesn’t list it and we found no published attack details. With an unauthenticated RCE and public details, assume it won’t stay quiet.

Campus/agency angle: project and task plugins tend to live on departmental or committee WordPress sites that someone set up once and nobody patches. The Pro add-on also needs to be current if you use it.

Do this: Search your WordPress fleet for wedevs-project-manager and update to 4.1.2 or later. If you can’t update today, deactivate it. Then look for unfamiliar admin users and unexpected PHP files in uploads.

CVE-2026-116512 record · Fused advisory · EverThread explainer

4. Leipzig University — every internet-facing server pulled offline

On the morning of October 28, Leipzig University detected an attack on its IT systems and took all internet-connected servers and services offline to limit the damage, including its websites, email, Moodle, and the AlmaWeb student portal. More than 30,000 students lost access to schedules, grades, and enrollment certificates. The university set up a crisis team, brought in an outside incident-response firm, notified authorities, and put up a stand-in website. Online submission deadlines were pushed to November 6, and the university said servers would come back up gradually from Monday, November 2 at the earliest. How the attackers got in, and whether any data was taken, hasn’t been made public.

Campus angle: the stand-in website and Instagram became the only reliable way to reach 30,000 students. When everything goes dark, a static status page that’s hosted somewhere else is part of your incident plan.

Do this: Make sure you can publish a basic status page from outside your own infrastructure on short notice, and that comms staff know where it is. Decide ahead of time which public-facing systems (the LMS, the student portal) get restored first, and what has to be true before they’re turned back on.

Leipzig University notice (Oct 28) · MDR Sachsen (Oct 31) · Süddeutsche Zeitung / dpa

PHP2Shell follow-up: there’s still no patch for the narrower CVE-2026-115560; PHP says the fix comes with the next regular bugfix release. Keep session.upload_progress.enabled=0 in place. PHP also rebuilt its Windows packages on October 26 (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) to pick up a Brotli fix. PHP news

Tip of the week

Watch the routes that change money, not just the ones that run code.

The Commerce Core bug didn’t need a web shell. It let attackers create or change orders through routes and fields that should have been off-limits. You can see that kind of abuse at the edge if you’re looking:

Patch Commerce Core and the companion modules first.
Add narrow rules for the write paths anonymous visitors shouldn’t use: PATCH/POST to JSON:API order and order-item endpoints, and order-placement requests that skip /checkout/.
Leave them in count against real traffic and see what actually hits them. Your own decoupled apps or payment webhooks may.
After about a day, open the dashboard — it shows what’s safe to block.
One click to promote. You stay in the loop.

The same pattern works for CAPTCHA: a rate rule in count on your registration and login forms will show you how much replayed traffic you’re getting before you decide to block it.

That’s how ProtectMyWebsite works: Rules start in count. After 24 hours, the dashboard shows what’s safe to block — one click. The WAF Cybersecurity Advisor is rule-based: it reads your count window and explains in plain English why a rule looks safe to promote, or why to hold it or allowlist something. It never blocks on its own; you click.

Self-serve is $150/site/month with a 14-day trial. Refer a peer and you both get 10% off for three months.

Running a multi-site estate (main site, departmental WordPress and Drupal, portals)? Ask about Campus Estate and talk to our sales team.

If you run campus or agency sites: scan your site, see what WAF count mode is, what’s safe to block on a WAF, WAF for higher education, WAF for government, the blog, Prior Watch (Oct 26), and start a 14-day trial.