WordPress security this week: the runtime, the backup console and the kernel all failed at once

If you read one section, read this one. The PHP release covered in Wednesday’s alert is now a week old, and the news since is about timing rather than versions. Amazon’s honeypot network recorded an exploitation attempt on 17 October, four days before PHP’s release, from an address on a commercial anonymisation network; proof-of-concept exploits were circulating from about 02:00 UTC on release day, twelve hours before the embargo lifted; and broad exploitation followed within hours of 14:00 UTC. Any server that was unpatched after 17 October has a window to investigate, not just a package to install. cPanel, EasyApache 4 and CloudLinux all shipped fixed packages on 21 October, including backports for ea-php74, ea-php80 and ea-php81 that keep their old version numbers, so the check is the package changelog, not the version string.

The UpdraftCentral incident is a different shape. Nothing was exploited on the sites; a trusted management channel was used as designed, by someone holding stolen keys. The update revokes the keys, and that is all it does. Whatever was installed through the channel before the revocation is still there. On the server, CloudLinux’s ZDI-CAN-33367 is the piece that turns any of this week’s site-level footholds into root on a shared host: a public exploit, no fixed kernel, and a one-line sysctl mitigation that has to be checked for side effects before it goes on.

Wednesday’s alert covered the flaws themselves: two unauthenticated remote code execution bugs in PHP core, one reached through out-of-memory handling and one through request state that outlives its memory, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at 14:00 UTC on 21 October. PHP’s position has not changed: every installation that serves web requests is at risk, PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed alike, there are no complete mitigations, and updating is the only safe choice. WordPress.org said the same on 21 October: no WordPress update is required or planned, the fix is PHP’s, and the version WordPress runs on is at Tools, Site Health, Info, Server.

What is new is the timeline. Amazon Threat Intelligence published on 23 October what its MadPot honeypots saw: a single exploitation attempt on 17 October from an address tied to a commercial anonymisation network, four days before disclosure and with no explanation of how the actor had the details; several proof-of-concept exploits appearing from about 02:00 UTC on 21 October; more attempts from further anonymised infrastructure between 02:00 and 08:00 UTC with varying payloads, which Amazon reads as several actors; and after the 14:00 UTC release, new exploits within hours and attempts against the sensors almost immediately, which it calls broad exploitation in the wild. Amazon is careful on one point: it has not confirmed that any attempt would have succeeded on a real system. Its advice follows from the dates anyway: start any investigation from 17 October, search form-upload POST requests for the string PHP_SESSION_UPLOAD_PROGRESS, and treat the six addresses it lists as leads to investigate rather than a block list, because they include shared anonymisation infrastructure.

On cPanel, every supported version is affected, and the fix arrived in cPanel & WHM 11.110.0.153, 11.134.0.66, 11.136.0.50, 11.138.0.18 and WP Squared 11.138.1.17, with EasyApache 4 25.91 on 21 October carrying the rebuilt packages: ea-php82 to ea-php85 at the upstream versions, and ea-php74, ea-php80 and ea-php81 as backports at 7.4.33-19, 8.0.30-12 and 8.1.34-5. 25.92 the same day only rebuilds the meta packages so their changelogs list the CVEs. CloudLinux has its own ea-php builds from ea-php52 to ea-php85 and alt-php packages for 5.2 to 8.5 on CloudLinux 7, 8, 9 and Ubuntu 22.04; on CloudLinux 10 only alt-php 5.2 is in the stable repository and the rest come through the TuxCare extended-lifecycle repository. For anything older than 7.4 on cPanel itself, cPanel points to TuxCare ELS for PHP.

The backports keep the lower version string. CloudLinux’s own example is a fixed ea-php84 reporting 8.4.26-2 rather than 8.4.27, and the cPanel-built ea-php74 reports 7.4.33 with a package release number that has moved. So php -v cannot tell you whether a server is fixed, in either direction. The package changelog can:

$ rpm -q --changelog ea-php81-php-cli | grep -m1 -E 'CVE-2026-(109618|109619)'
$ rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'
$ zgrep -E 'CVE-2026-109618' /usr/share/doc/ea-php81-php-cli/changelog.Debian.gz

Run it for every ea-php and alt-php branch that any site selects, not just the server default. Imunify360’s ruleset 8.88 adds rule 77049357, which blocks a serialised PHP object in the upload-progress field regardless of the Referer header; CloudLinux calls it a virtual patch that stops known request patterns at the edge while the vulnerable code stays as it is, says no rule yet covers the out-of-memory path of CVE-2026-109618, and that crafted requests resembling normal uploads may get through. It helps while the packages install. It is not a reason to delay them.

TeamUpdraft, the company behind UpdraftPlus, says it identified unauthorised access to its systems over the weekend of 17 and 18 October. The customer database it believes was accessed held names, email and billing addresses, order history, password hashes, two-factor authentication settings, and the connection keys for three services: UpdraftCentral, the hosted console that manages WordPress sites remotely; UpdraftVault, its backup storage; and UpdraftClone. No card data was held; payments go through Stripe and PayPal. The attacker used UpdraftCentral keys to do what the console is for, sending commands to the connected sites, and TeamUpdraft reports administrator accounts created, malicious plugins installed, and a pattern of unexpected editor roles. It does not yet know the full extent.

The scope matters, because most UpdraftPlus installs are not in it. Affected are sites connected to the UpdraftCentral cloud service hosted by TeamUpdraft. A self-hosted UpdraftCentral is not affected. The UpdraftPlus plugin and its downloads were not tampered with. Backups kept in your own remote storage were not accessed, though TeamUpdraft says a site that was reached through UpdraftCentral should re-authorise its storage and rotate the storage credentials, since the attacker had the same access to them that the site did. UpdraftVault was disconnected from every site and reissued credentials, so Vault backups stop until each site reconnects; every UpdraftClone key was replaced.

The plugin fix is UpdraftPlus Free 1.26.13 or Premium 2.26.13, released just after 22:00 BST on 19 October. It revokes every UpdraftCentral cloud connection made before 13:07 BST on 18 October. The changelog records that 1.26.12, released the same day, was meant to do this and did not: 1.26.13 is described as properly applying the revocation in 1.26.12. By 20 October WordPress.org had pushed the release to all users, so most sites have it; check the version anyway, because a site with automatic updates disabled or a stuck filesystem lock has not. Wordfence’s analysis of the campaign, which this briefing draws on for the indicators below, describes the attacker sending signed plugin.upload_plugin commands over the console’s own protocol with valid keys, which is why nothing on the site side looked like an attack.

1. 01

   Preserve before you change anything

   Copy the access logs from 17 October onward, the plugin and must-use plugin folders, and a database dump to somewhere outside the site. If the site turns out to be compromised, this is the evidence of what was done with it.

2. 02

   Revoke the key and update

   Delete the UpdraftCentral connection key from UpdraftPlus, Advanced Tools, UpdraftCentral, or remove the option from WP-CLI, then update to 1.26.13 or 2.26.13 or later, which revokes any key that predates 13:07 BST on 18 October:

   WP-CLI

   $ wp plugin update updraftplus --skip-plugins --skip-themes
   $ wp option get updraft_central_localkeys --skip-plugins --skip-themes

   A site still on 1.26.12 believed it had revoked the keys and had not.

3. 03

   Inspect from outside WordPress

   List users, plugins and must-use plugins with every plugin skipped, so a hiding filter cannot run, and compare against the folders on disk:

   shell

   $ wp user list --role=administrator --skip-plugins --skip-themes
   $ wp user list --role=editor --skip-plugins --skip-themes
   $ wp plugin list --skip-plugins --skip-themes
   $ ls -la wp-content/mu-plugins wp-content/plugins

   Then search the whole site for wp_set_auth_cookie near hash_equals, for pre_user_query and pre_count_users, and for PHP in uploads, drop-ins such as advanced-cache.php and object-cache.php, the theme folders and the site root.

4. 04

   Remove what was installed, and rotate

   Delete the plugins and users that do not belong, and the cron events they registered. Change every administrator password, invalidate all sessions and regenerate the salts in wp-config.php. If the site uses UpdraftVault or remote storage that UpdraftCentral could reach, re-authorise it and rotate the storage credentials.

5. 05

   Reset the TeamUpdraft account

   From a clean device, type the address directly rather than following a link, change the password, change it anywhere else it was reused, and reset two-factor authentication. The database held password hashes and 2FA settings, so both are compromised.

6. 06

   If there is evidence, restore and investigate

   A site with an unknown administrator, a generated-name plugin or the login backdoor should be restored from a backup taken before 17 October, then re-patched and re-inspected, and the account around it should be checked for what the attacker did with the site’s credentials. That is incident response, not maintenance.

7. 07

   Reconnect last

   Create a new UpdraftCentral connection only after the site is clean and updated. Reconnect UpdraftVault with the new credentials and run a manual backup to confirm it works.

CloudLinux published its advisory on 23 October for ZDI-CAN-33367, a Linux kernel flaw that has no CVE assigned yet. The bug is in skb_zerocopy(), the networking code that builds packets from existing memory pages rather than copies. A local user can use it to change the contents of a file they are only allowed to read, through the page cache, and from there the usual route to root is open. The attacker needs a shell on the machine, which on shared hosting every customer account provides. A public exploit exists. The fix for Dirty Frag, CVE-2026-43284, added a check for a shared-fragment marker; in this bug the marker is lost before the check runs, so a server with the Dirty Frag fix is still exposed.

CloudLinux measured CageFS against it and is direct about the result: inside the cage the exploit succeeded. What does close the local route is whether ordinary users can create user namespaces. CloudLinux 7 is not affected, because its kernel never decrypts in place. CloudLinux 7 Hybrid is exposed as shipped. CloudLinux 8 and 9, and their ELS variants, are conditional: installations since mid-2024 ship with the namespace path closed by default, older installations have it open. CloudLinux 10 and CloudLinux for Ubuntu 22.04 are closed by default. The check is one command, and 0 is the safe answer:

$ sysctl user.max_user_namespaces

No fixed kernel has shipped for any line; the upstream fix was posted for review and is not merged. KernelCare is ahead of the kernels: the livepatch is in the production feed for CloudLinux 10 and AlmaLinux 10, in review for CloudLinux 9, in progress for CloudLinux 8, in preparation for CloudLinux 7 Hybrid and 9 ELS, and not started for Ubuntu 22.04, whose kernel fix will come from Canonical. CloudLinux 8 ELS has no livepatch stream at all, so there the only route is a kernel upgrade and a reboot when one exists. On CloudLinux 10:

$ kcarectl --update
$ kcarectl --patch-info | grep -i 33367

CloudLinux notes that --patch-info is the command that shows it; --info does not.

cPanel’s article, published on 13 October and updated on 22 October, describes CVE-2026-107663 in WP Toolkit, which ships with cPanel & WHM: in 6.11.4 and earlier, an authenticated user may be able to place malicious files in a domain owned by another user on the same server. The article gives no severity score, and as of 26 October the CVE record has not been published at MITRE or NVD, so the vendor description is all there is. Read in the context of this week, it is the lateral step: a compromised customer account, whether through PHP, a plugin or a stolen key, becomes PHP files in a neighbour’s document root, on a product whose purpose is to manage every WordPress site on the server.

The fixed version is 6.11.5. Because WP Toolkit updates on its own schedule rather than with cPanel & WHM, check the installed version rather than the cPanel version, and update through the installer script cPanel’s article links from wp-toolkit.plesk.com with the version pinned if the server has not already picked it up:

$ grep version /usr/local/cpanel/3rdparty/wp-toolkit/build.json

On a server that ran 6.11.4 or earlier with more than one customer, add one check to this week’s review: PHP files in any account’s document roots that were created by, or at the times of activity of, a different account’s user. WP Toolkit writes as the target domain’s user, so ownership alone will not show it; creation times against the other account’s session and cron activity will.

Duplicator is the one to think about rather than just update. Wordfence assigned CVE-2026-82814 on 21 October from a finding by Alex Thomas and its Argus analysis: the plugin deserialises untrusted content from the database during a migration, and the content can be put there without logging in, for instance as a comment. The payload then waits. Nothing happens until an administrator builds a package and runs a migration, which is the user interaction in the CVSS vector, and at that point the installer that Duplicator bundled into the package does the deserialising. That installer is a copy of the code as it was when the package was built. Updating the plugin to 5.0.0 changes future packages; it changes nothing inside the packages already sitting in storage, which still carry the old installer and, if the payload was planted before the package was built, the payload too. A package built before the fix should be rebuilt before it is ever imported, and a site that imports old packages on a routine, staging refreshes for example, should treat every one of them that way.

The other four are straightforward to act on and hard to be sure about afterwards. Each gives an anonymous visitor an account or code execution, and each is being used. OttoKit’s fix shipped on 8 October with no security note in the changelog, eight days before Patchstack published, so a fleet that looked only for security releases missed it. The Events Calendar’s object injection was fixed on 10 September; what changed is the exploited marker, which means a site that was slow to update in September needs the look-behind now. miniOrange’s 5.5.8 changelog says security updates for phone-based login and Patchstack says 5.5.8 is still vulnerable; 5.6.0 is the version that closes it.

Read the items in sequence rather than as a list. A remote code execution in PHP, or in OttoKit, LearnPress or The Events Calendar, or a plugin pushed through a stolen UpdraftCentral key, ends in the same place: a shell running as one customer account. ZDI-CAN-33367 takes that shell to root on any CloudLinux host where user namespaces are open, and CageFS does not stand in the way. WP Toolkit 6.11.4 offers a quieter route to the same effect, from one account’s files into another’s. At root, every site, database, mailbox and credential on the server belongs to the attacker. The week’s work is therefore not plugin updates; it is the PHP runtime and its running workers, the kernel’s namespace setting, the panel tool that crosses account boundaries, and only then the plugins.

The UpdraftCentral incident adds a problem of trust in your own tools. The console that was used against the sites is also the console most operators would use to check them, and the malware observed hides from the Users screen and the plugin list. A site that was connected has to be inspected from the file system, the database and WP-CLI with plugins and themes skipped, and the TeamUpdraft account itself has to be treated as compromised, password and two-factor settings included. Patching stops the next command; it does not undo the last one.

On the PHP flaws, the honest position a week on is that exposure began on 17 October for anyone whose server was reachable, that the fixed packages have existed since 21 October on every branch cPanel and CloudLinux ship, and that the only acceptable state now is patched, restarted and verified by changelog, with the logs from 17 October read. A server that shows PHP_SESSION_UPLOAD_PROGRESS in multipart POSTs before its patch time has a question to answer, and the answer is in its process table, its cron, its new files and its outbound connections, not in its version string.

1. 01

   Inventory and update every PHP branch

   On cPanel and CloudLinux, refresh the repositories and update the ea-php and alt-php packages, then restart the web server and PHP-FPM so the workers reload. Use yum in place of dnf on CloudLinux 7, and restart LiteSpeed where it is the web server:

   shell

   $ /scripts/update-packages
   $ dnf clean all && dnf upgrade 'ea-php*' 'alt-php*'
   $ /scripts/restartsrv_httpd
   $ /scripts/restartsrv_apache_php_fpm

   Include every branch any site selects in MultiPHP Manager, native distribution PHP, and anything a container or appliance bundles. On Debian and Ubuntu, apply the distribution update and restart php-fpm or apache2.

2. 02

   Verify the backport, not the version

   For each installed branch, confirm the CVEs are in the package changelog:

   shell

   $ rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
   $ /usr/local/cpanel/bin/rebuild_phpconf --current

   The second command lists what each domain actually runs. A branch with no CVE line in its changelog is unpatched, whatever php -v prints.

3. 03

   Open the forensic window from 17 October

   Search access logs for multipart POST requests containing PHP_SESSION_UPLOAD_PROGRESS, for PHP-FPM or Apache worker crashes and restarts in the error logs, and for the six addresses Amazon lists as leads. Then look at what changed since: new PHP files, webshells, cron entries, processes that outlive requests, administrators, and outbound connections. Amazon confirms broad attempts, not that any succeeded; your logs decide for your server.

4. 04

   Close the CloudLinux namespace path

   Check and, where nothing depends on user namespaces, mitigate:

   shell

   $ sysctl user.max_user_namespaces
   $ echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf && sysctl --system

   On CloudLinux 10 with KernelCare, apply the livepatch and confirm it:

5. 05

   Update WP Toolkit to 6.11.5

   Check the version in build.json, update through cPanel’s installer script if it is 6.11.4 or earlier, and on multi-customer servers review the document roots for files created at the times another account was active.

6. 06

   UpdraftCentral: revoke, update, inspect, rotate

   On every site connected to the hosted UpdraftCentral, follow the cleanup section above in order: preserve, delete the key, update to 1.26.13 or 2.26.13, inspect users and plugins with --skip-plugins --skip-themes and on disk, remove what was installed, rotate administrator passwords, sessions, salts and storage credentials, and reset the TeamUpdraft account password and 2FA from a clean device. Restore from before 17 October where there is evidence.

7. 07

   Update the exploited plugins

   OttoKit to 1.1.41 or the current 1.1.42, LearnPress to 4.4.11, miniOrange OTP to 5.6.0, The Events Calendar to 6.17.5.1 or the current 6.18.2. Where an update cannot happen today, deactivate. Then review administrators, role changes and sessions since 11 October, and look for PHP in uploads and mu-plugins on the object-injection sites.

8. 08

   Duplicator: update, then rebuild old packages

   Update to 5.0.0 or later, and before any migration or staging refresh from a package built earlier, delete the old package and build a fresh one. Treat a stored package as carrying the installer of the version that built it.

9. 09

   Keep session upload progress off

   PHP’s 23 October advisory asks for session.upload_progress.enabled=0 until the next bugfix release, with every worker restarted. If you set it last week, leave it. WordPress does not use the feature.

10. 10

    Confirm Core and the WAF, without closing on either

    WordPress 7.1.3 on every site; 7.2 Beta 1 nowhere near production. Imunify360 ruleset 8.88 where Imunify is installed, confirmed with:

    shell

    $ cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION
    $ imunify360-agent update --force modsec-rules

    The rule buys time while packages install; the item is closed by the package changelog, not the rule.

This briefing was compiled on 26 October 2026 from the published sources below. Versions, dates and figures are quoted as the source reported them and were not independently re-measured. PHP package versions were taken from cPanel’s support article, the EasyApache 4 change log and CloudLinux’s status page; exploitation status from Amazon’s MadPot report and Patchstack’s database labels; fixed plugin versions from Patchstack and the plugins’ WordPress.org changelogs. The UpdraftCentral indicators are as published in Wordfence’s analysis, and the TeamUpdraft timeline and remediation steps are from its own notice. Where sources disagree, as Patchstack and the CVE record do on the Duplicator score, both figures are given. Where a claim rests on a vendor’s word alone, as the WP Toolkit description does, the text says so.