WAF Watch: A campus WordPress web shell, self-healing backdoors, FortiMail file writes

Mac Clark · October 5, 2026

A short roundup of what hit websites this past week — and what to do about it if you run campus or agency sites. Fear is cheap; checklists are useful. Last week’s Watch covered PeopleSoft path tricks, a WordPress LFI, Drupal Webform, and FBIjobs.gov. Here’s what landed since then.

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. UNMC — public WordPress environment rebuilt after web shells

The University of Nebraska Medical Center said on October 5 that its Brand Wise site is back online after attackers exploited a WordPress vulnerability on a public-facing WordPress environment, got onto the web server, and deployed malicious web-shell files. UNMC says forensic analysis found no evidence of sensitive data loss. The response included new web security controls, rebuilding the affected infrastructure and sites, and accelerating a platform modernization. UNMC has not named the specific vulnerability, so we won’t guess.

Campus angle: this is the textbook shape of a higher-ed web incident. It wasn’t the flagship homepage; it was a departmental/brand site on shared WordPress infrastructure. Those long-tail sites are where patch lag lives.

Do this: Inventory every WordPress install you’re responsible for, including brand, events, and departmental microsites, and confirm core and plugin versions actually changed after updates. Sweep web-writable directories for unexpected .php files. If you find a shell, rebuild rather than “clean,” the way UNMC did.

UNMC Newsroom (Oct 5)

2. “SC” — a WordPress backdoor that rebuilds itself from eight places

Sucuri documented a WordPress infection it calls SC that stores the same backdoor in at least eight locations: a .user.ini auto_prepend_file loader, a hidden loader in wp-content, the db.php and advanced-cache.php drop-ins, a theme functions.php, a fake hyper-engine-kit plugin installed as both a must-use and a normal plugin, the database, and a System V shared-memory segment. Delete one copy and any surviving copy restores the rest on the next request or cron run. It hides from the admin plugin screen, creates a hidden administrator, uses the Ethereum blockchain for command and control, and can inject JavaScript skimmers into visitor pages. Sucuri doesn’t know how the initial access happened.

Same week, The Hacker News reported active exploitation of CVE-2026-1581, an unauthenticated SQL injection in the wpForo Forum plugin (all versions through 2.4.14, CVSS 7.5) — low volume so far (fewer than 20 attempts since July per Previdian), but it’s exactly the kind of forgotten plugin that sits on a club or alumni site.

Do this: If you clean a WordPress compromise, stop execution first (take the site offline or block PHP), then remove database, cron, and shared-memory persistence before deleting files, then rotate every admin password, session, and key. Check wp-content/mu-plugins, db.php, advanced-cache.php, and any .user.ini for things you didn’t put there. Update or remove wpForo.

Sucuri · The Hacker News (Oct 1)

3. FortiMail — unauthenticated file write, exploited, fixes still “upcoming” (CVE-2026-104286)

On October 1 Fortinet published FG-IR-26-175: a path traversal plus NULL-byte flaw in FortiMail (CVSS 9.8) that lets an unauthenticated attacker write arbitrary files via crafted HTTP/HTTPS requests. Fortinet says it’s exploited in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog the same day. Affected: 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8, and all of 7.2. At publication the fixed builds (8.0.2, 7.6.7, 7.4.9) were listed as upcoming; 7.2 users are told to move to 7.4 or later.

Campus/agency angle: a lot of universities and local governments run FortiMail as their mail gateway, with the webmail and encrypted-mail (IBE) interfaces reachable from the internet. This is a case where there’s no patch to apply yet, so the edge is the mitigation.

Do this: Apply Fortinet’s workaround now: turn off the IBE service, or restrict the webmail interface to trusted networks. Fortinet’s own advisory also says that if a web application firewall sits in front of FortiMail, block POST requests to /ibe containing ../. Check for the IoC IPs and the unexpected archive account config change listed in the advisory. Upgrade as soon as the fixed builds ship.

Fortinet FG-IR-26-175 · CISA KEV alert (Oct 1)

4. DTU — identity system breached with stolen credentials

The Technical University of Denmark disclosed on October 2 that attackers used compromised DTU profiles to log into DTUBasen, its identity and access management system, and downloaded a large amount of data going back to 2003. DTU can’t yet say exactly what was taken; the system holds records for about 40,000 active and 160,000 former users, including national ID (CPR) numbers. Separately, Munich’s LMU confirmed on October 4 that its whole admissions-system dataset — about 600,000 records — was affected in a mid-September intrusion.

Campus angle: no exploit needed when valid logins work. Identity portals and admissions systems are the crown jewels, and they’re web apps.

Do this: Require MFA on every account that can reach identity and admissions back-ends, including former-staff and guest accounts you forgot to retire. Alert on bulk exports and unusual query volume from a single account. At the edge, rate-limit login and export endpoints and put credential-stuffing patterns in count so you can see who’s hammering them before you block.

DTU notice (Oct 2) · BleepingComputer (Oct 3) · LMU coverage (Oct 4)

Tip of the week

When there’s no patch yet, a narrow edge rule buys you time. Watch it before you block with it.

FortiMail is the cleanest example this week: the vendor itself says block POST to /ibe with ../. That’s a precise, low-false-positive rule, but “low” isn’t “zero,” and you only find out which by watching real traffic. The same goes for WordPress hardening rules (blocking direct PHP execution in uploads, or flagging writes to mu-plugins): good ideas that can break a legitimate plugin.

The right move:

Patch when the fix exists; use the vendor workaround when it doesn’t.
Deploy a narrow virtual-patch rule for the exact request shape.
Leave it in count against real traffic.
After about a day, open the dashboard — it shows what’s safe to block.
One click to promote. You stay in the loop.

That’s how we run ProtectMyWebsite: Rules start in count. After 24 hours, the dashboard shows what’s safe to block — one click. Promote Copilot explains in plain English why a rule looks safe to promote, or why to hold or allowlist it — you still click once. It does not auto-block for you.

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

If you run a multi-site estate (main site, departmental WordPress, portals), ask about Campus Estate: Talk to the sales team. No cookie-cutter dollar figure on a blog post; your inventory drives the conversation.

If you run campus or agency sites: scan your site, see what WAF count mode is, what's safe to block on a WAF, managed WAF for university and college websites, managed WAF for government and public-sector websites, Prior Watch (Sep 28), Prior Watch (Sep 21), and start a 14-day trial.