WAF Watch: PHP2Shell takes campus sites offline, the UpdraftCentral breach traced to the vendor, and 34 Drupal advisories

(opens in a new tab)Mac Clark (opens in a new tab) · October 26, 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. PHP2Shell — two critical PHP flaws, universities offline for a day, and now confirmed exploitation

On October 21 the PHP project shipped 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical flaws, CVE-2026-109618 (memory corruption during out-of-memory handling) and CVE-2026-109619 (stale state left behind after a fatal error), both rated CVSS v4 9.2 and nicknamed "PHP2Shell." Both can allow unauthenticated remote code execution. PHP says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, and it rates mod_php highest risk: a demonstrated exploit triggers with a single unauthenticated request before any application code runs. CISA issued an alert the same day urging immediate patching.

Campuses felt it first. Duke took a large number of university-hosted sites offline Wednesday morning, including Duke Today and the Student Affairs site, and restored critical sites by late afternoon after patching. Berkeley’s security office took affected sites and services offline until they were patched. Leiden limited vulnerable faculty and institute sites to eduroam and eduVPN, then suspended them overnight. Radboud took its website and intranet offline from 1 p.m. to 8 p.m. Kiel took all its online services offline as a precaution. Duke said it had no evidence any information was compromised.

That was the right call. On October 26, BleepingComputer reported the first high-quality confirmation of successful in-the-wild exploitation, against an Apache mod_php server still on PHP 8.4.26. Attackers had been probing for days before the patch, and on October 23 PHP disclosed a third, narrower RCE (CVE-2026-115560) that has no patch yet and only affects an unusual session configuration.

Campus/agency angle: PHP isn’t one application, it’s under WordPress, Drupal, Moodle, departmental tools, and vendor products you didn’t build. The sites that were down longest were the ones nobody knew were running PHP.

Do this: Update every PHP install to a fixed version and restart every worker (FPM pools, Apache). PHP 8.1 and older get no project fix, so upgrade or get your vendor’s backport; CISA says take unpatched systems offline. Set session.upload_progress.enabled=0 in php.ini or the pool config (not ini_set() or .user.ini); that also covers the new October 23 issue. If anything can’t be patched today, PHP’s own stopgaps are a low post_max_size and request limits at the web server or proxy (decoded body size, multipart part count, header count). CISA notes a WAF "may provide some protection until systems are updated," but it’s a bridge, not a fix. Then ask your vendors which of their hosted products embed PHP; the Dutch NCSC keeps a php2shell product list on GitHub.

PHP security advisory (Oct 21) · CISA alert (updated Oct 23) · BleepingComputer (Oct 26) · The Duke Chronicle (Oct 22) · Leiden University updates

2. Update: UpdraftCentral — the vendor confirms its own site was breached, and a fix now revokes the keys

Last week we covered attackers using UpdraftCentral keys to push backdoor plugins onto WordPress sites running UpdraftPlus. There’s real news since. TeamUpdraft confirmed that someone had unauthorised access to teamupdraft.com over the weekend of October 17–18 and that it believes its customer database was accessed: names, emails, billing addresses, order history, hashed passwords, two-factor settings, and the connection keys for UpdraftCentral, UpdraftVault, and UpdraftClone. Card data wasn’t stored there, and the vendor says the plugin and its downloads weren’t affected.

The fix is UpdraftPlus 1.26.13 (free) / 2.26.13 (Premium), released the evening of October 19, which automatically disconnects UpdraftCentral connections made before 13:07 BST (12:07 UTC) on October 18. WordPress.org pushed it to free users automatically. Two catches: the earlier emergency release, 1.26.12 / 2.26.12, deleted no keys because of a bug (per Nethemba’s code review), and keys created later on October 18 aren’t revoked by 1.26.13. As of October 22, TeamUpdraft is still seeing unexpected Editor accounts and asking customers to check their sites, "even if you’ve never used UpdraftCentral."

Campus angle: if you ever bought a Premium license on a university card, that account’s details and 2FA settings were in the leaked database. And the update stops new commands; it doesn’t remove a backdoor that already landed.

Do this: Confirm every site is on 1.26.13 / 2.26.13 or later, not 1.26.12. Log in to each site directly and delete its UpdraftCentral key by hand anyway. Check Users and Plugins, including Must-Use, for anything you don’t recognise, and rotate admin passwords. Change the teamupdraft.com password and reset its 2FA. If you find a backdoor, TeamUpdraft suggests restoring from a backup taken before October 17.

TeamUpdraft incident page (updated Oct 23) · Nethemba analysis · Patchstack

3. Drupal — 34 contrib advisories on October 21, including a USWDS component and an open-government theme

One week after the core Field UI fix we covered last time, the Drupal Security Team published 34 contributed-project advisories (SA-CONTRIB-2026-220 through -253) across 31 projects: one highly critical, seven critical, 25 moderately critical, and one less critical. The highly critical one is Ffmpeg Image Toolkit (SA-CONTRIB-2026-220, CVE-2026-114523), a remote code execution flaw through unsanitized file names passed to ffmpeg; fixed in 1.0.3. Only one site reports using it, but the attacker just needs to be able to upload an image. Every advisory in the batch rates exploitation as theoretical for now.

Two are aimed squarely at the public sector. USWDS Paragraph Components (SA-CONTRIB-2026-234), a set of components built on the U.S. Web Design System, has a cross-site scripting flaw in its templates that needs a content-editing role to exploit; fixed in 3.1.3. The Ágora Transparency Theme (SA-CONTRIB-2026-231), built for transparency and open-government sites, can show the contents of CSV attachments to visitors who aren’t allowed to download them, and cache that preview for others; fixed in 1.2.3. The widely used modules in the batch include Bootstrap (8.x-3.45), Rabbit Hole (8.x-1.3, where a query parameter lets anonymous visitors skip a configured access-denied or redirect), Shield (8.x-1.9), Simple OAuth (6.1.3), and Domain (3.0.2).

Campus/agency angle: Rabbit Hole (about 75,000 sites) is a common way to hide pages that shouldn’t be browsed directly, and Shield puts a password on staging sites. Both fixes are about anonymous visitors reaching things you meant to keep hidden.

Do this: Run drush pm:list --no-core --status=enabled on every site and multisite child, and include themes this time (Bootstrap, Ágora, ABC, Black Hole, and Zero Point are themes). Patch Ffmpeg Image Toolkit first, then the critical items, then the common modules above. composer outdated "drupal/*" shows what’s behind. And remember Drupal 10 reaches end of life on December 9, 2026.

Drupal contrib advisories · SA-CONTRIB-2026-234 (USWDS Paragraph Components) · Digital Matters roundup (Oct 23)

4. University of Copenhagen — a test environment with real data on about 525,000 people

The University of Copenhagen said Friday evening (October 23) that attackers had gained access to a test environment. The attack was discovered on Tuesday and brought under control. The data it exposed covers roughly 525,000 people, including full names, Danish CPR (national ID) numbers, work and private phone numbers, and private email addresses. The university says there’s no sign the attackers reached systems that run day-to-day operations, and it has reported the incident to the Danish Data Protection Agency. The same week, Aarhus University said a hacker got onto one of its servers and tried to change passwords for about 1,700 current and former staff and students before being caught. Danish authorities said they’re following both incidents.

Campus angle: "it’s only test" is how real data ends up on a server with weaker controls, older software, and nobody watching the logs. Staging and test copies of student systems and web apps sometimes get opened to the internet so a vendor or contractor can reach them.

Do this: List every non-production copy of a student, alumni, or applicant system and confirm two things: it doesn’t hold real personal data (mask or synthesize it), and it isn’t publicly reachable. If a vendor needs access, put it behind SSO, VPN, or an IP allowlist, and give it the same patching and logging as production.

The Copenhagen Star (Oct 23) · DR (Oct 23, Danish) · University of Copenhagen statement

Tip of the week

Request-size limits are a virtual patch too. Count them before you block.

PHP’s own advice for anyone who can’t patch PHP2Shell today is to cap requests at the web server or proxy: decoded body size, multipart part count, header count. Those are exactly the kind of edge rules that buy time against a bug that fires before your application ever sees the request. They’re also exactly the kind that can break a legitimate big upload: a thesis PDF, a grant application, a video for the news office.

Patch PHP and restart the workers first.
Add narrow limits on request size and multipart parts, scoped to the hostnames and paths that don’t need large uploads.
Leave them in count against real traffic and see who actually sends big requests.
After about a day, open the dashboard — it shows what’s safe to block.
One click to promote. You stay in the loop.

For anything still unpatched and internet-facing, don’t let the count window be your only protection: restrict who can reach it until it’s fixed.

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 19), and start a 14-day trial.