WAF Watch: Stolen backup-plugin keys backdoor WordPress, a Drupal core RCE, and an exploited Jira/Confluence file-read bug

(opens in a new tab)Mac Clark (opens in a new tab) · October 19, 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. UpdraftPlus — stolen remote-management keys are installing WordPress backdoors right now

This one is still unfolding as of Monday morning. Patchstack and Nethemba report that an attacker holding valid UpdraftCentral dashboard keys has been pushing backdoor plugins to connected WordPress sites since October 18 at 15:32. UpdraftCentral is the remote-management service bundled inside UpdraftPlus, the backup plugin on more than four million sites. The commands are correctly signed, so the plugin treats them as legitimate. It isn’t a code bug, there’s no CVE, and as of October 19 no plugin update stops it; the latest releases are affected the same as older ones. The evidence points to keys leaking from the vendor’s cloud side, and the vendor hadn’t published an explanation when Patchstack posted.

The backdoor creates an account that looks like an Editor but quietly holds manage_options and install_plugins, and it logs the attacker in by setting a cookie directly, which skips the login form, two-factor, and login-limit plugins. Patchstack logged 99 different backdoor plugin names, all carrying the description "Small maintenance toolkit: keeps option storage tidy." Many sites have a key nobody meant to create: a checkbox on the TeamUpdraft account screen enrols the site in UpdraftCentral by default.

Campus angle: UpdraftPlus is the default backup plugin on a lot of departmental and student-org WordPress sites. "We only use it for backups" doesn’t mean the site has no key.

Do this: On every WordPress site, run wp option get updraft_central_localkeys. Any output means the site is exposed. Delete the keys (wp option delete updraft_central_localkeys, or Settings → UpdraftPlus Backups → Advanced Tools → UpdraftCentral). Backups keep working. Then look for the plugin description above, Editor accounts that also hold manage_options, and an option ending in _sync_token. If you find the backdoor, delete the key first, then move the plugin out of the web root rather than uninstalling it from wp-admin. Check Patchstack’s status line before acting, since it’s being updated as the vendor responds.

Patchstack (Oct 19)

2. Drupal core — a critical Field UI RCE, plus Entity List, on October 14

After a pre-announcement on October 12, the Drupal Security Team shipped SA-CORE-2026-014 (CVE-2026-108097), a critical remote code execution flaw in core’s Field UI module. Core alone can’t reach it, but contributed modules can, and at least one known path requires no login. The same day brought SA-CONTRIB-2026-218 (CVE-2026-108099), a similar critical RCE in the Entity List module, and two moderately critical core XSS fixes in the Link and Navigation modules. No in-the-wild exploitation had been reported as of the end of last week, but the team warned exploits "might be developed within hours or days," and one research team has already published a lab reproduction of the exploit chain (using a stand-in module, since the advisory doesn’t name the contrib modules that expose it).

Campus/agency angle: Drupal’s biggest footprint is universities and governments, and the fixed versions only cover supported branches. Anything older than Drupal 10.6 or 11.3 is end-of-life and gets no fix.

Do this: Update core to 10.6.19, 11.3.19, or 11.4.10, and Entity List to 3.0.10. If you can’t update a site today, uninstalling field_ui mitigates the core flaw in the meantime. Include every multisite child and every forgotten departmental install in the sweep.

Drupal SA-CORE-2026-014 · Drupal security advisories · BleepingComputer (Oct 17)

3. Jira, Confluence, and the rest of Atlassian Data Center — exploited file read, now on CISA’s KEV list

On October 15, CISA added CVE-2026-21589 to its Known Exploited Vulnerabilities catalog, meaning there’s evidence of active exploitation. Atlassian rates it critical (9.3): an unauthenticated attacker can read specific files inside the web application root of every version of Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible, and Fisheye on Data Center and Server. The attacker needs to know the exact file path, but Atlassian notes some configurations leave sensitive files there. Atlassian’s cloud products are already patched.

Campus/agency angle: self-hosted Jira and Confluence are common in central IT, research computing, and agency project offices, and they’re often reachable from the internet so outside collaborators can log in.

Do this: Patch to Atlassian’s fixed versions (for example Confluence 9.2.26 or 10.2.19, Jira Software 9.12.40, 10.3.26, or 11.3.12). If you can’t patch right away, Atlassian’s first recommendation is to pull the instance off the public internet; its second is a WAF or proxy rule that blocks .. next to /, \, or ::, including URL-encoded forms. Search your access logs for the same pattern to check for earlier attempts.

CISA KEV alert (Oct 15) · Atlassian advisory

4. Baden-Württemberg — one shared service center hit, a whole state’s universities stalled

On the evening of October 7, the Hochschulservicezentrum Baden-Württemberg (HSZ-BW) in Reutlingen, which runs shared IT systems for several of the state’s universities, detected a cyberattack. It took every system offline, cut its internet connection, and shut off its phones. The center says attackers planted malware and accessed data; how much left is still under investigation. Eleven days later, German public broadcasters reported that schools still couldn’t pay invoices, student assistants, or scholarships; students at several schools couldn’t pull transcripts or enrollment certificates; and HfG Schwäbisch Gmünd’s online application portal was down, with applications taken by email instead.

Campus angle: this wasn’t a website exploit, but it’s a reminder that the systems behind your public application and student portals may live with a shared provider you don’t control.

Do this: List which public-facing forms and portals (applications, payments, records requests) depend on a shared service or consortium, and make sure each has a fallback page and a published alternative you can switch to in an hour.

RWU updates (English) · SWR (Oct 14) · tagesschau (Oct 18)

5. Government DDoS — a rented botnet that can pick which countries the traffic comes from

Azerbaijan’s national CERT says DDoS attacks from October 13 to 15 hit government agencies, media, and embassy websites; the state security service counted more than 100 government domains targeted, with several agency sites disrupted. A hacktivist group claimed it, and the CERT found the attackers used a commercial DDoS-for-hire service sold over Telegram that lets buyers route attack traffic through bots in countries they choose. The CERT’s point: that feature weakens defenses based on where traffic comes from. Separately, Bavaria’s Landratsamt Cham (a county administration) was knocked offline on October 8 by a flood from roughly 50 countries, taking out email, phones, and citizen services like vehicle registration until systems were restored.

Agency angle: if your DDoS plan is mostly "block traffic from countries we don’t serve," a rented botnet can be pointed at you from countries you do serve.

Do this: Pair any geo rules with per-IP rate limits on expensive pages (search, login, forms) and make sure your status page and phone tree don’t run on the same network that’s under attack.

CERT.az (Oct 16) · APA (Oct 14) · BR24 on Cham (Oct 14)

Tip of the week

When the vendor hands you a WAF rule, count it briefly, then promote it.

Atlassian’s advisory this week literally ships a regex for your WAF. That’s the best case for a virtual patch: the request shape is known and narrow. It’s still worth a short look in count before blocking, because a path-traversal pattern can match something odd your own integrations send.

Patch if you can. If you can’t, restrict access first.
Add the vendor’s rule, scoped to the affected hostname or path.
Leave it in count against real traffic and watch what it matches.
After about a day, open the dashboard — it shows what’s safe to block.
One click to promote. You stay in the loop.

For something actively exploited and internet-facing, don’t let the count window become your only protection: limit who can reach the app while the rule proves itself.

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: Talk to 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 12), and start a 14-day trial.