WordPress security this week: the plugin update that was the attack

If you read one section, read this one. The Rank Math incident is different in kind from a vulnerability. Nothing was exploited: the plugin itself, fetched from the vendor through the normal update path, was the payload. That means the usual signal, an out-of-date version number, tells you nothing. What matters is when the package was obtained and whether it was activated. Patching is not the response; incident response is.

The rest of the week is more familiar, and still urgent. Four plugin flaws are being exploited, and each one goes straight from the internet to administrator access or code execution. On the server side, CloudLinux is still waiting on fixed kernels for PwnEscape, and five ModSecurity fixes change what a cPanel web application firewall does and does not catch.

Rank Math’s advisory says that “a limited number of users” who downloaded Rank Math SEO PRO 3.0.123 between 20:02 UTC on 15 October and 07:12 UTC on 16 October received plugin files containing malware. That is the vendor’s own distribution channel, so the affected copies arrived through ordinary downloads and automatic updates. Rank Math removed the files and published 3.0.124 as the clean release. Wordfence assigned the incident CVE-2026-111862 and scored it 9.8. Rank Math has not said how many sites were affected, who was behind it, or how the malicious build entered distribution. The free Rank Math SEO plugin on WordPress.org is not part of the advisory.

The version number alone proves nothing. A 3.0.123 package obtained before the window is clean, and so is one obtained after it. Rank Math sorts sites into three groups. A site where an affected copy was installed and activated must be treated as compromised. A site where it was installed but never activated should delete the plugin files, install 3.0.124 from the Rank Math account and run a scan as a precaution. A site that only downloaded the package, without installing or activating it, has no indication of compromise from this incident alone. If Rank Math has contacted you directly, follow its instructions whatever version the site runs now.

What the malware does, according to Rank Math and Wordfence: it establishes persistent access and contacts the domain rank1cdn.com; it recreates hidden PHP backdoors whenever the site is visited, so removing a file while the loader remains brings the file back; it creates administrator accounts; it drops a fake Core file in wp-includes; it adds .htaccess rules that let .cache files run as PHP; it adds cron entries at system level, outside WordPress; and it exposes everything the web server can read, which includes the database credentials and salts in wp-config.php, API keys, and payment and mail credentials. The PHP it writes uses base64_decode with XOR loops, proc_open, and PHP-FPM socket code.

1. 01

   Restore from before the window if you can

   A full restore of files and database from a backup taken before 20:02 UTC on 15 October is Rank Math’s preferred route. Then scan, rotate credentials as in step five, and install 3.0.124 downloaded by logging in at rankmath.com. Rank Math says it never sends login or download links by email.

2. 02

   Otherwise, disable the rebuild mechanism first

   Delete the whole rank-math-pro folder; deactivating is not enough. Delete the three options from wp_options. Block outbound connections to rank1cdn.com at the host or firewall if you can. Do not start removing backdoors until all three are done, or they come back.

3. 03

   Then remove what it left

   Search for the indicators above. Remove unknown administrators, the fake Core file, the .htaccess rules and .cache files, the system cron entry, and PHP in uploads and mu-plugins. Reinstall WordPress Core, plugins and themes from official sources rather than deleting files one by one.

4. 04

   Look beyond the site

   Review authorized_keys for SSH, the crontabs of other system users, running processes, and writable locations outside the document root. The malware ran as the site’s user and could reach anything that user could.

5. 05

   Rotate every credential the site could read

   WordPress passwords, the database password in wp-config.php, the authentication keys and salts, API keys, payment gateway and SMTP credentials, and the cPanel, FTP, SFTP and SSH logins. Rank Math calls this essential even after a restore. Re-check two-factor authentication on administrator accounts.

6. 06

   Verify, then keep watching

   Verify Core and every plugin that has public checksums, and review the scheduled events:

   WP-CLI

   $ wp core verify-checksums
   $ wp plugin verify-checksums --all
   $ wp cron event list

   Compare premium plugins, which have no public checksums, against a fresh download from the vendor. Watch outbound connections for several days; if a removed file reappears, the cleanup missed a layer.

The Grid is the most serious of the four on paper and the hardest to inventory. Patchstack published it on 14 October from a 2 September report by Rafie Muhammad, and the CVE record followed on 16 October with a CVSS of 10: network, no privileges, no interaction, and a scope change. The plugin is commercial, so it will not appear in WordPress.org update checks; look for the-grid in the plugins folder of every site and compare the version in its header with 2.8.2. The CodeCanyon changelog visible on 19 October still ends at 2.8.1, so confirm the fixed build with the vendor if the updater offers nothing.

The three takeovers share a shape: a parameter that an anonymous visitor controls ends up in a function that writes user data. In MailOptin the attack needs a WordPress user registration opt-in form published on the site; the form’s identifier is visible in the page source. In Theme My Login the CVE record says exploitation applies to multisite installs in certain configurations, and the 7.2.2 changelog describes the fix as stopping a lost-password request from overwriting an account’s password on multisite; a single-site install may not be reachable, but with exploitation under way and the fix a one-line changelog entry, update anyway. In My Calendar the plugin’s own /my-calendar/ page is public by default after activation, so a default install is exposed. Patchstack classifies the My Calendar flaw as PHP object injection; the CVE record, assigned by Wordfence, and the plugin’s changelog describe it as privilege escalation through reflected shortcode injection. The fix is the same either way.

LearnPress, with more than 70,000 installs, is vulnerable up to 4.4.10 to an unauthenticated PHP object injection, CVE-2026-104736, scored 9.8 and published by Wordfence on 17 October from a Wordfence PRISM finding; Patchstack published it on 16 October and also marks it as exploited. The checkout-email parameter of the checkout AJAX action is passed through sanitize_text_field, which does not strip serialized object syntax, stored in the LearnPress session table, and later unserialized with no allowed_classes restriction. Object injection on its own does nothing; it needs a gadget chain in some other code on the site. The CVE record does not name one, and neither does Patchstack. That is a reason to update to 4.4.11, released on 16 October, before someone finds one, not a reason to wait. Exploit aggregators already list a public proof of concept.

WP Booking System, with more than 10,000 installs, is fixed in 2.1.0.4, released on 16 October. CVE-2026-109369 is a missing authorization check: a subscriber who has already been given edit rights on at least one booking form can overwrite the plugin’s own access-control list and grant themselves and any other user edit access to every form. Wordfence scores it 6.8, because of that precondition and the high attack complexity; Patchstack rates its priority high and expects it to be exploited. The changelog entry for 2.1.0.4 says only “Security improvements”.

CVE-2026-99999, which its finder calls PwnEscape, is a flaw in how the Linux kernel handles checksum metadata from virtio-net. A guest sends a packet with an unfinished checksum and a csum_start value that points inside the IPv4 header; when the host fragments the packet and completes the checksum, two attacker-controlled bytes land in a header the kernel has already validated. The kernel then re-reads the header length and copies that many bytes into each fragment, which leaks host heap memory back to the guest. The bug has existed since Linux 2.6.27. It was found by Paulos Yibelo of pwn.ai during Vercel’s sandbox security challenge, reported privately, and fixed in mainline by Michael Tsirkin of Red Hat; the kernel’s CVE record of 15 October scores it 9.3 and lists fixed stable releases 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113 and 6.18.57.

CloudLinux’s advisory of 16 October is candid about what is and is not known. The researcher reported a host memory leak, a host crash and code execution as root on a test host; CloudLinux has not reproduced the attack, no public proof of concept exists, and it has seen no exploitation. CISA has not added the CVE to its catalog. CloudLinux nonetheless treats every supported kernel as affected: CloudLinux 7, 7h, 8, 8 LTS, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04. As of that advisory no fixed kernel had shipped for any of them. CloudLinux 9 and 10 wait on AlmaLinux’s kernel, 8 LTS and 9 LTS on the TuxCare extended-support kernel, and the Ubuntu build follows Canonical’s fix through apt.

The KernelCare livepatch is the only thing that has moved. The patch for the EL9 family is rolling out, and the advisory names K20261016_0002 for AlmaLinux 9 and CloudLinux 9 as being in the main feed, with the RHEL, Oracle and Rocky 9 patches still in testing; el8 and el10 are in progress. The advisory is inconsistent with itself in places, saying both that the EL9 patch is in the test feed and that it is in the main feed, and giving two different verification commands, so check rather than assume: update, then search the patch information for CVE-2026-99999.

$ kcarectl --update
$ kcarectl --patch-info | grep CVE-2026-99999

Servers licensed through CLN apply livepatches automatically; servers managed through KernelCare ePortal follow the rules set there.

EasyApache 4 25.89, released on 7 October, moves ea-apache24-mod_security2 from 2.9.14 to 2.9.15, the upstream release of 29 September. cPanel lists five CVEs against it. Two matter most to a WordPress host because they are evasions, not crashes: a request can be built that passes the firewall’s rules and still reaches the application with the payload intact. The release also patches ea-openssl11 for the five CVEs in OpenSSL’s 29 September advisory, including the high-severity DTLS flaw CVE-2026-84782 covered here last week, and moves Passenger to 6.2.0, which fixes an unauthenticated Watchdog API and a Watchdog privilege escalation. Note the behaviour change: an empty watchdog_api_server_authorizations value used to skip authentication and now allows none.

EasyApache 4 25.90, released on 14 October, patches ea-libcurl 8.17.0 for six CVEs that cPanel rates low, among them a bearer-token leak on cross-protocol redirects and an HTTP/2 server-push use-after-free, and reworks ea-podman: the Jailshell and CageFS command-line paths now run through admin actions instead of a full-access API token, and host ports reserved by a failed container install are released. Neither release touches Apache itself; the 2.4.69 update with its twenty CVEs was 25.88 on 2 October.

Every control that most WordPress operations rely on assumes the update is the safe side of the comparison. Version checks, automatic updates, the advice to keep everything current: all of it treats the vendor’s package as trusted. For eleven hours it was not. The Rank Math incident does not change the advice to update; a site that stays on old versions is exposed to the four exploited flaws below it in this briefing. It changes what you need to be able to answer afterwards: when did each site fetch each package, and from where. Sites with automatic plugin updates and no update log cannot answer that today.

The second lesson is the distinction between patching and remediation, which this briefing has drawn before and draws again. The exploited flaws are closed by an update; whatever they were used for is not. The Rank Math malware is removed by nothing short of a restore or a layered cleanup, because it rebuilds itself and lives partly outside WordPress. A fleet process that reports “all plugins current” after this week has not finished.

On the server, the pattern is waiting with the right posture. PwnEscape has no fixed CloudLinux kernel, and the honest answer for most shared hosts is that the local route is closed when unprivileged user namespaces are off and open when they are on, which on CloudLinux 8 and later they are by default. Knowing which applies to each host, and applying the livepatch where it exists, is the work available this week. The ModSecurity fixes are the reverse: the update is out, and the question is whether the firewall it updated is actually doing anything.

1. 01

   Inventory Rank Math SEO PRO

   List every site with seo-by-rank-math-pro installed and establish when 3.0.123 arrived on each: the plugin updater’s log, the file timestamps on the plugin folder, the hosting account’s access logs for the download, or Rank Math’s own notification. Anything obtained between 20:02 UTC on 15 October and 07:12 UTC on 16 October is in scope.

2. 02

   Treat activated copies as a compromise

   Isolate the site and take a snapshot. Restore files and database from before 15 October 20:02 UTC if a trusted backup exists. If not, delete rank-math-pro entirely, remove the three options, block rank1cdn.com, and only then clean the rest. Rotate WordPress, database, salts, API, SMTP, payment, cPanel, FTP, SFTP and SSH credentials. Review authorized_keys, system and WordPress cron, processes and writable paths outside the document root.

3. 03

   Update or deactivate the four exploited plugins

   The Grid to 2.8.2, Theme My Login to 7.2.2 or the current 7.3.1, My Calendar to 3.8.8 or the current 3.8.9, MailOptin to 1.2.78.7. Where an update cannot happen today, deactivate. Then review administrators and recent password and email changes on every site that was exposed.

4. 04

   Update LearnPress and WP Booking System

   LearnPress to 4.4.11, WP Booking System to 2.1.0.4. Neither CVE record reports exploitation, but Patchstack marks LearnPress as exploited and aggregators list a public proof of concept.

5. 05

   Verify what WP-CLI can verify

   Run these on every site touched by the first four steps:

   WP-CLI

   $ wp core verify-checksums
   $ wp plugin verify-checksums --all
   $ wp user list --role=administrator
   $ wp cron event list

   For premium plugins, compare against a clean package downloaded from the vendor.

6. 06

   Confirm EasyApache 4 25.89 and 25.90 are installed

   Check that ea-apache24-mod_security2 is at 2.9.15 or later, that the Passenger and libcurl updates applied, and that the update did not leave ModSecurity disabled or critical rules excluded for the whole server.

7. 07

   Apply the KernelCare livepatch where it exists

   On CloudLinux 9, update, then confirm CVE-2026-99999 is listed in the patch information:

   shell

   $ kcarectl --update
   $ kcarectl --patch-info | grep CVE-2026-99999

   On other streams, watch CloudLinux’s advisory for the kernel or livepatch and plan the reboot.

8. 08

   Assess PwnEscape exposure per host

   Inventory hosts that run VMs you do not control and consider disabling checksum offload for those guests until a kernel ships. On shared hosts, check user.max_user_namespaces, and do not change it before confirming nothing depends on user namespaces.

9. 09

   Confirm WordPress Core is at 7.1.3

   There is no newer release this week. Check the version on every site rather than assuming automatic updates ran.

This briefing was compiled on 19 October 2026 from the published sources below. Versions, dates, and figures are quoted as the source reported them and were not independently re-measured. Exploitation status comes from Patchstack’s database labels and CISA’s catalog as of 16 October; fixed versions were checked against the plugins’ WordPress.org pages where the vulnerability databases did not list them. Where sources disagree, as they do on the classification of the My Calendar flaw and on the state of the CloudLinux 9 livepatch, both readings are given in the text.