WordPress security this week: the update became the attack, and six plugins are being exploited

If you read one section, read this one. The Core flaw is the priority because it is in CISA’s catalog and because the exposure is created by the thing you do to fix it: a full-package update extracts WordPress into wp-content/upgrade/, and until 7.1.4 the folder name was predictable and the installer inside it was reachable from the web for as long as the extraction took. Patchstack rates the attack as impractical because the window is seconds long; Wordfence, the CVE numbering authority for it, scores it 8.1 and logged more than 18,500 attempts in its first 21 hours; CISA added it on 3 November. All three can be true at once. The window is short, the attackers are polling for it anyway, and nobody has published a confirmed compromise. Update, and deny web access to the folder so the window closes for good, including on fleets with slow storage or staged rollouts where the extraction takes longer than a few seconds.

Six plugin flaws carry Patchstack’s known-to-be-exploited label this week, and three of them give an anonymous visitor an account or code execution: WP Project Manager’s remote code execution, and the authentication bypasses in Uncanny Toolkit for LearnDash and WP Social. Contact Form 7’s file upload needs the server to help, by listing directories or interpreting what lands in the upload folder; the two object injections, in Gravity Forms and FunnelKit Automations, need a gadget chain the site happens to carry. Below the application, Brotli is the item that updating WordPress cannot touch, cPanel has three fixes including one that turns any panel login into root, and CloudLinux’s kernels are finally out.

WordPress 7.1.4 was released on 28 October as a security release with 22 fixes, most of them stored cross-site scripting reachable by Contributor or higher accounts, plus an information disclosure of unpublished Customizer changes, a permissions bug in post notes, and an update to the bundled root certificates. The one that matters to this briefing was reported by Umut Bayram and described by WordPress as a race condition during core updates that could lead to remote code execution. It affects every version from 4.7 to 7.1.3, which is to say every WordPress that has updated itself in the last decade. Wordfence assigned CVE-2026-119977 and scored it 8.1; Patchstack’s database entry carries a 9 with a Low priority and the note that exploitation is impractical. CISA added it to the Known Exploited Vulnerabilities catalog on 3 November with a 6 November deadline for federal agencies, which is a three-day window and a signal of how it reads the evidence.

The mechanism, from Patchstack’s reading of the code, is this. When WordPress installs or updates itself from a full package, it extracts the archive into a working folder under wp-content/upgrade/, a directory the web server serves. Before 7.1.4, the folder name came from the package name, so for an administrator-uploaded or standard update it was predictable. The cleanup routine then deleted everything in wp-content/upgrade/, including the index.php that stops directory listing. The extracted copy is a complete WordPress, and it contains wp-admin/setup-config.php, the installer that runs without the site’s configuration. An attacker who requests that file while the extraction exists can run the installer against a database they control, and from there execute code. The window lasts as long as the extraction and copy take, which is seconds on fast storage and longer on NFS, saturated disks or staged deployments. It recurs on every update, including unattended ones, and it needs no account.

The paths the attackers request look like this, with the directory name varying by package:

$ /wp-content/upgrade/wordpress-7.1.4/wp-admin/setup-config.php
$ /wp-content/upgrade/wordpress-7.1.4/wp-admin/install.php

7.1.4 adds three defences: sixteen random characters appended to the extraction folder name, an index.php that is recreated and no longer deleted, and wp-config.php added to the list of files never copied out of the working directory, a change Patchstack found in update-core.php and the release post does not mention. The backports shipped the same day for every branch WordPress still patches: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 and so on down to 4.7.39. WordPress’s own documentation lists which of the 22 issues reach each branch; 7.0 and 6.9 get all 22, 6.8 and 6.7 get 20, 6.6 gets 19. The 28 October announcement said the backports were in progress and would ship as ready, so a site on an older branch should be checked rather than assumed. 4.6 and earlier get nothing.

Wordfence published a firewall rule at 20:30 UTC on 28 October and saw the first matching request nine minutes later. In the first 21 hours it counted more than 18,500 requests for staged setup-config.php paths. Those are attempts seen by one vendor’s firewall, not compromises; Wordfence has not reported a successful one, and neither has anyone else as of this briefing. Treat the number as proof that the path is being polled at scale, and your own logs as the only evidence about your own sites.

1. 01

   Search the access logs for the staged installer

   On cPanel the per-domain logs are in domlogs; elsewhere use the vhost access log. Any hit is worth a ticket, a 200 is an incident:

   shell

   $ grep -rhE "wp-content/upgrade/[^ ]+/(wp-admin/)?(setup-config|install)\.php" /usr/local/apache/domlogs/ | sort | uniq -c | sort -rn | head
   $ grep -rhE "wp-content/upgrade/" /var/log/nginx/*access* | grep -vE " (403|404) " | head

   A 403 after this week’s deny rule is the rule working. A 404 from before it means the attacker missed the window. A 200 or 302 means the installer answered.

2. 02

   Look for what the extraction left behind

   Between updates the folder holds only index.php. Anything else, and above all a wp-config.php or any PHP file that is not index.php, is evidence:

   shell

   $ find /home/*/public_html/wp-content/upgrade -mindepth 1 -not -name index.php -ls
   $ find /home/*/public_html/wp-content/upgrade -name "wp-config.php" -o -name "*.php" -newer /home/*/public_html/wp-settings.php

   Check the live wp-config.php against a known-good copy as well, since the pre-7.1.4 copy routine could promote one.

3. 03

   Verify the Core files

   Confirm the version and that the Core files match the release checksums, with plugins and themes skipped so nothing loaded can interfere:

   WP-CLI

   $ wp core version --skip-plugins --skip-themes
   $ wp core verify-checksums --skip-plugins --skip-themes

   A checksum failure on a file the release touched is expected after a partial update; a failure on a file it did not touch, or an extra file, is not.

4. 04

   Audit who and what arrived after the update

   Administrators, application passwords, plugins, must-use plugins and cron events created in the hours after an update are the shapes a successful run would take:

   shell

   $ wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes
   $ wp user application-password list "$(wp user list --role=administrator --field=ID --skip-plugins --skip-themes | head -1)" --skip-plugins --skip-themes
   $ wp plugin list --fields=name,status,version,update --skip-plugins --skip-themes
   $ wp cron event list --fields=hook,next_run_relative,recurrence --skip-plugins --skip-themes
   $ ls -la --time-style=long-iso wp-content/mu-plugins wp-content/plugins | sort -k6,7

   Then the process table and outbound connections for the account during the same window, which on shared hosting is where the question becomes a server question.

Contact Form 7 is the one most people will find on their servers, and the one whose severity most depends on the server. The vendor’s 29 October notice says the target is any form with a file field on a server that lists directory contents; Patchstack adds that the upload folder name is random and not disclosed, so an attacker who cannot list the directory has to guess. Two server settings decide the outcome: whether Options -Indexes, or the nginx equivalent, is in force for the uploads tree, and whether PHP executes there at all. A site that already forbids PHP in wp-content/uploads and does not list directories has turned this from a takeover into a storage nuisance. Update to 6.2.4 anyway, then look in the wpcf7_uploads folder and the rest of uploads for anything with a PHP, phar, pht or phps extension, a double extension, or a .htaccess that was not there before.

The three that need nothing from the server are the ones to treat as incidents on any site that was exposed. WP Project Manager’s flaw is plain remote code execution reachable from the internet, and its 4.1.2 changelog describes it only as a fix to how project changes are checked before saving. Uncanny Toolkit and WP Social both let a visitor become an existing user, which on a LearnDash or membership site means the administrator who set it up. For those three, review administrators, role changes, password resets and sessions since the fix dates, and look for PHP in uploads, mu-plugins and cron on the Project Manager sites. Gravity Forms and FunnelKit are object injections: no gadget chain, no code execution, but Patchstack marks both exploited, which means someone is sending the payloads and finding chains somewhere. Gravity Forms is a premium plugin that does not auto-update by default and whose fix shipped on 1 October under a one-line changelog, so a site that watches only for security releases has been exposed for a month.

Web 2.0 Directory is the awkward one: it is not on WordPress.org, its CVE record names no fixed version, and the secondary reports disagree between 2.10.13 and 3.0.0. Check the vendor’s changelog on CodeCanyon for the entry that mentions the level filter, and treat anything at 2.10.12 or below as vulnerable until then. FormFlow is the one to move first, because an unauthenticated upload with a public nonce is the pattern that goes from published to exploited fastest.

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder, affecting 1.0.3 through 1.2.0 and fixed on 21 October in 1.0.10, 1.1.1 and 1.2.1. CISA added it to the Known Exploited Vulnerabilities catalog on 27 October with a 10 November deadline. It is a library bug, not a WordPress one, and that is exactly why it belongs here: the fix is a package on the server, and nothing in the WordPress update stream will ever deliver it.

Patchstack’s 30 October analysis traces the route. An unauthenticated pingback.ping call to xmlrpc.php makes WordPress fetch the attacker’s source URL with wp_safe_remote_get(). WordPress’s cURL transport sets CURLOPT_ENCODING to an empty string on every request, which asks libcurl to accept and decompress any encoding the server offers; a reply with Content-Encoding: br is therefore decompressed by the system’s Brotli library inside curl_exec(), before PHP or WordPress sees a byte of the body. The same decoder is reached by oEmbed fetches, feed fetches through SimplePie, and any plugin that fetches a visitor-supplied URL. PHP’s own note on its 26 October Windows rebuilds says the vulnerable decoder is reachable through the cURL extension only when automatic decompression is enabled, which is off by default; WordPress turns it on.

What has been demonstrated against PHP is denial of service. A lab published on 27 October showed a worker killed outright and, with a payload under 100 bytes, a worker pinned at full CPU. No public, reproducible code-execution chain exists against PHP behind Apache or PHP-FPM; the chains that do exist target stock Node.js and Bun binaries, and one GitHub repository claims execution against a single pinned Docker image of WordPress, which this briefing could not verify. Say DoS, and plan for the chain to arrive.

The checks and the fix, on RPM systems first:

$ rpm -q brotli brotli-libs
$ dnf update brotli brotli-libs
$ grep -l "libbrotli.*(deleted)" /proc/*/maps 2>/dev/null | cut -d/ -f3 | sort -u

On Debian and Ubuntu, the package is libbrotli1 and the distribution backports the fix into 1.1.0, so compare the package revision rather than the version: Patchstack’s example is 1.1.0-2+b7 vulnerable and 1.1.0-2+deb13u1 patched on Debian 13, with the suffix varying by release. The third command above lists processes still holding the old library after the update; restart them, which on a web server means Apache or nginx, PHP-FPM, and anything else that links libcurl.

$ dpkg -l libbrotli1 | tail -1
$ apt-get install --only-upgrade libbrotli1

cPanel published two advisories dated 20 October whose CVE records became public on 2 November. CVE-2026-105476 is an improper link resolution flaw, CWE-59, that lets a remote authenticated user write arbitrary root-owned files, which is privilege escalation to root by another name; it is scored 8.8 with a vector that needs only low privileges, and it is credited to a researcher known as Boomerang. The briefing source this issue draws on describes the starting point as a reseller account; the CVE record says authenticated users without qualification. Until cPanel’s text has been read against your own account types, assume any login to the panel is in scope. CVE-2026-105475 is a NUL-byte handling flaw that lets an unauthenticated remote attacker read any mail account’s calendar and contact data, scored 8.7 on CVSS 4.0. Both are fixed in 11.110.0.154, 11.134.0.67, 11.136.0.51 and 11.138.0.19; the 138 change log dates 138.0.19 to 26 October and lists only a security-hardening line for them.

The same 138.0.19 build updates Roundcube to 1.6.20, which Roundcube released on 19 October alongside 1.7.5 with 20 security fixes. The one with the highest reach is CVE-2026-113386, an IMAP command injection: a logged-in webmail user can put a carriage return and line feed into the uid parameter of the headers and view-source actions and have the IMAP server run a command of their choosing on their own mailbox. A sibling, CVE-2026-114720, does the same through the flag parameter of the mark action. Authenticated, scored 7.1, and in a shared-hosting context the authenticated user is any customer or any phished mailbox. Check the Roundcube version a server actually runs rather than the cPanel branch, and on branches other than 138 read the change log for the build that carries 1.6.20.

$ /usr/local/cpanel/cpanel -V
$ grep -m1 "RCMAIL_VERSION" /usr/local/cpanel/base/3rdparty/roundcube/program/include/iniset.php
$ /scripts/upcp --force

A phpMyAdmin WebAuthn flaw disclosed this period is reported, in the briefing source, as not affecting the phpMyAdmin that cPanel bundles, on cPanel’s own assessment. This briefing could not find a published cPanel statement to quote, so treat that as unconfirmed, and in any case it says nothing about a phpMyAdmin installed by hand outside the managed package.

Last week’s briefing covered ZDI-CAN-33367 when it had a public exploit, no fixed kernel on any line, and a livepatch only for CloudLinux 10. CloudLinux’s advisory has been updated since. Fixed kernels moved to production on 28 October for CloudLinux 9 and 10, through the AlmaLinux kernel updates, and on 30 October for CloudLinux 7 Hybrid and CloudLinux 8. The ELS variants of 8 and 9 were still pending on their extended-support channel at the cut-off, with 8 ELS waiting on a kernel uplift to 5.14 and no livepatch possible; CloudLinux for Ubuntu 22.04 waits on Canonical. KernelCare has moved less: the livepatch is in production for CloudLinux 10 only, in review for 9, in progress for 8 and in preparation for 7 Hybrid and 9 ELS. Still no CVE.

Installing the package is not the fix; running it is. A kernel that is installed and not booted protects nothing, so the sequence is update, reboot, and compare the running version against the table:

$ dnf update "kernel*"
$ reboot
$ uname -r

Use yum on CloudLinux 7 Hybrid. Where a reboot cannot happen today, keep the mitigation from last week in place, which newer CloudLinux 8 and 9 installs and every CloudLinux 10 already have by default, and schedule a short window:

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

Imunify360 published its fleet numbers for the week after PHP2Shell: close to 3 million attack requests against roughly 100,000 servers and 1.7 million sites, a peak on 24 October of 1.3 million attempts in a day with 99.0 percent blocked, and about 9 million matches on the dedicated PHP2Shell rules between 21 and 26 October, of which about 6.25 million were from blocking rules and the rest from logging ones. No sign of a successful compromise on the fleet, by its account. Two caveats from its own write-up: the blocking rules cover the upload-progress path, which is CVE-2026-109619, while the out-of-memory path of CVE-2026-109618 has logging rules only; and the rules are a virtual patch that stops known request shapes at the edge while the vulnerable interpreter stays as it is. Nine million matches in six days is the argument for checking what is actually running rather than what the repository says.

The things that stay unpatched after a fleet update are the ones outside the update path: a PHP built from source years ago for one application, an alt-php or ea-php branch no domain officially selects but a .htaccess handler still points at, a CageFS skeleton that was not refreshed, a PHP-FPM pool that was never restarted after the packages changed, and a ModSecurity or Imunify rule that was disabled for one domain during an incident and never re-enabled. Each is a one-line check:

$ /usr/local/cpanel/bin/rebuild_phpconf --current
$ for p in /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php; do echo "$p $($p -r "echo PHP_VERSION;")"; done
$ rpm -q --changelog ea-php81-php-cli | grep -m1 -E "CVE-2026-(109618|109619)"
$ grep -rl "ea-php\|alt-php" /home/*/public_html/.htaccess 2>/dev/null | head
$ imunify360-agent config show | grep -iA3 "MOD_SEC"

PHP’s informational advisory of 23 October for CVE-2026-115560, the second session-upload-progress issue, still has no fixed release as of 2 November; PHP’s archive shows only the 26 October Windows rebuilds for Brotli since. The mitigation stands: session.upload_progress.enabled set to 0, on every SAPI and every branch, with the workers restarted. Because php.ini, a .user.ini, a PHP-FPM pool file and a per-domain MultiPHP setting can each override the others, read the effective value from the interpreter rather than the file:

$ for p in /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php; do echo "$p $($p -r "echo ini_get('session.upload_progress.enabled');")"; done
$ grep -rs "upload_progress" /home/*/public_html/.user.ini /opt/cpanel/ea-php*/root/etc/php-fpm.d/*.conf

The Core flaw changes the threat model for the one operation every site performs on a schedule. Updating is supposed to be the safe moment, and for ten years it was also the moment a complete, unconfigured WordPress was reachable on a guessable path. The fix in 7.1.4 is good, and it is still a fix inside the window; the control that removes the window is a web-server rule denying wp-content/upgrade/ from the internet, applied everywhere and left in place. Fleets with staggered rollouts, slow I/O, network storage or long deployment pipelines should assume their window was longer than the seconds Patchstack measured, and should read their logs for the week accordingly.

On a shared host the six plugin flaws, the panel flaw and the kernel are one chain. A form upload or a REST route gives an attacker a shell as one customer. The shell reads wp-config.php, cookies, API keys and whatever credentials the account kept; a reused password or a token reaches cPanel, mail or a reseller login; CVE-2026-105476 takes that login to root on an unpatched build, or ZDI-CAN-33367 takes the shell to root on an unbooted kernel; and from root every site, mailbox and database on the node is the attacker’s. The first-day investigation of a single compromised site therefore has to include the panel’s access logs, the mail logs, authentication records, the process table and recent changes under /etc and /root, not only the public_html that raised the alarm.

Brotli is the reminder that outbound requests are an input. A pingback, a server-side request forgery, an oEmbed, a feed or a webhook all fetch what an attacker chooses, and the reply is processed by native libraries before the application sees it. An inventory of the destinations PHP is allowed to reach, an egress proxy or firewall for the web user, and logging of outbound DNS and HTTP are defences against this week’s decoder bug and against the command-and-control traffic that follows any of the other items.

1. 01

   Deny the upgrade folder, then update Core

   Add the web-server rule first so the window is closed while the update runs. Apache, in the vhost or a .htaccess inside the folder, and nginx:

   shell

   $ printf "Require all denied\n" > /home/USER/public_html/wp-content/upgrade/.htaccess
   $ location ^~ /wp-content/upgrade/ { deny all; }

   Then update every site to 7.1.4 or the backport for its branch and confirm the version afterwards on every node and replica, since the announcement said backports would ship as ready:

2. 02

   Verify Core and look back

   Run the four steps in the Core indicators section above: access logs for setup-config.php and install.php under wp-content/upgrade/, leftovers in the folder, checksums, and the administrators, application passwords, plugins and cron created after each update since 28 October.

3. 03

   Find and fix the six exploited plugins

   Across every site on the server, list the six and update or remove them:

   shell

   $ for s in /home/*/public_html; do wp plugin list --path="$s" --skip-plugins --skip-themes --fields=name,version --format=csv 2>/dev/null | grep -E "^(contact-form-7|gravityforms|wedevs-project-manager|wp-marketing-automations|uncanny-learndash-toolkit|wp-social)," | sed "s|^|$s |"; done

   Targets: Contact Form 7 6.2.4, Gravity Forms 3.1.3, WP Project Manager 4.1.2, FunnelKit Automations 3.8.6.2, Uncanny Toolkit for LearnDash 3.8.3, WP Social 3.2.3, or the current release. Gravity Forms is premium and updates only with a valid licence; where it cannot be updated today, deactivate it.

4. 04

   Review the exposure window for each

   Contact Form 7: list the upload folders for PHP, phar, pht, phps, double extensions and .htaccess files, and confirm PHP does not execute in uploads. Uncanny Toolkit and WP Social: administrators, role changes, password resets and sessions since mid-October. WP Project Manager: treat as code executed; PHP in uploads and mu-plugins, cron, the account’s crontab and processes. Gravity Forms and FunnelKit: the same as Project Manager if any gadget-bearing plugin is installed.

   shell

   $ find /home/*/public_html/wp-content/uploads -type f \( -iname "*.php*" -o -iname "*.phar" -o -iname "*.pht" -o -iname "*.phps" -o -name ".htaccess" \) -newermt "2026-10-01" -ls

5. 05

   Update cPanel & WHM and review privileged state

   Check the build and force the update if it is below the fixed one for its branch:

   shell

   $ /usr/local/cpanel/cpanel -V
   $ /scripts/upcp --force

   Then review reseller accounts, API tokens, SSH authorized_keys for root and resellers, changes under /root and /etc since 20 October, scripts in /usr/local/cpanel/hooks and the standardized hooks list, and root’s crontab.

6. 06

   Patch Brotli where libcurl loads it

   On RPM systems update brotli and brotli-libs; on Debian and Ubuntu, libbrotli1 by package revision. Restart every process still holding the old library, rebuild container images from a patched base, and remember that ea-brotli and ea-nodejs22 are different packages:

   shell

   $ dnf update brotli brotli-libs
   $ grep -l "libbrotli.*(deleted)" /proc/*/maps 2>/dev/null | cut -d/ -f3 | xargs -r ps -o pid,comm -p

   Until then, block xmlrpc.php at the web server and install Patchstack’s must-use plugin that sets the cURL encoding to identity.

7. 07

   Boot the fixed CloudLinux kernel

   Update, reboot in a short window, and confirm the running kernel is at or above the table above:

   shell

   $ dnf update "kernel*"
   $ uname -r

   On 8 ELS, 9 ELS and Ubuntu, and anywhere the reboot has to wait, keep user.max_user_namespaces at 0 and on CloudLinux 10 confirm the KernelCare patch with kcarectl --patch-info.

1. 01

   WordPress 7.1.4 or the branch backport on every site

   Confirm from WP-CLI with plugins skipped, on every node, including staging and replicas that update on their own schedule.

2. 02

   No successful request to a staged installer

   Search every access log for setup-config.php and install.php under wp-content/upgrade/ and note the status codes.

3. 03

   The six exploited plugins inventoried and fixed

   Contact Form 7, Gravity Forms, WP Project Manager, FunnelKit Automations, Uncanny Toolkit for LearnDash, WP Social: updated, or deactivated and removed.

4. 04

   cPanel & WHM at or above the fixed build for its branch

   11.110.0.154, 11.134.0.67, 11.136.0.51 or 11.138.0.19, with Roundcube 1.6.20.

5. 05

   Brotli patched on the host, in containers and in chroots

   brotli-libs or libbrotli1 by package revision, old copies out of memory, images rebuilt.

6. 06

   The fixed CloudLinux kernel running

   uname -r at or above the table; the namespace sysctl still at 0 where it cannot be.

7. 07

   PHP2Shell backports present on every active branch

   The CVE identifiers in the package changelog of each ea-php and alt-php branch any domain uses, and the workers restarted.

8. 08

   session.upload_progress.enabled at 0 on every SAPI

   Read from the interpreter, not the file, for every branch.

9. 09

   Recent administrators, cron, mu-plugins, SSH keys and API tokens reviewed

   Since 20 October for the panel, since 28 October for the sites, since 17 October for anything UpdraftCentral touched.

10. 10

    Logs preserved and a ticket opened for every match

    Anything above that matched gets a case, with the logs copied off the server before cleanup starts.

This briefing was compiled on 2 November 2026 and revised on 4 November to add CISA’s 3 November catalog entry for CVE-2026-119977. Versions, dates and figures are quoted as the source reported them and were not independently re-measured. The Core mechanism and code changes are from Patchstack’s analysis; the branch list from WordPress’s own version documentation; the Wordfence request counts and rule timing from Wordfence’s post as reported, since its pages could not be read directly at compile time. Exploitation status for plugins is Patchstack’s known-to-be-exploited label; fixed versions were checked against the plugins’ WordPress.org changelogs and, for Gravity Forms, the vendor change log. The Brotli chain is Patchstack’s; PHP’s note on when the cURL extension reaches the decoder is from its 26 October announcement. cPanel’s two advisories returned an access error to this compiler, so their contents are taken from the CVE records they are cited in, and the reseller detail in the briefing source is flagged as such in the text. The cPanel phpMyAdmin assessment could not be sourced and is marked unconfirmed. CloudLinux’s kernel status is from its advisory as updated on 30 October; Imunify360’s figures are from its own fleet report. Where sources disagree, as they do on the Core flaw’s severity and on Web 2.0 Directory’s fixed version, both readings are given.