Rank Math PRO, a paid WordPress SEO plugin, distributed malware from its own official download site. Version 3.0.123 was compromised during an eleven-hour window, from October 15 at 20:02 UTC to October 16 at 07:12 UTC. The vendor removed the affected files and shipped 3.0.124. The free Rank Math SEO plugin distributed through WordPress.org was not affected. If you run the paid version and updated in that window, this is your week.
What the malware does
Reporting describes a first-stage script that establishes a persistent backdoor and talks to a command-and-control domain, then goes looking for credentials: WordPress database credentials and API keys, SSH keys stored on the web server, and cloud credentials for AWS, Google Cloud, Azure and Cloudflare. It also modifies .htaccess, drops PHP code disguised as .cache files, schedules tasks and cron jobs, and alters other plugins and themes.
Read that list again, because it defines the scope of the problem. This was not a defacement or a spam-link injection. It was a credential harvest from the machine your website runs on, and web servers tend to hold keys to things that are not the website.
The part people will get wrong
Updating the plugin does not fix it. Neither does deactivating it. Once a backdoor is established, cron jobs scheduled and other plugin files altered, removing the original delivery mechanism leaves all of that in place. The actual remediation is restoring from a known-good backup taken before October 15, or working through a thorough cleanup, and then rotating every credential that site had access to. If your site could reach a cloud account, that account's keys are part of the incident.
This is also the week to find out whether your backups go back far enough and whether you can actually restore one, which is the question we keep coming back to in testing your backups.
Why this one is different from the usual plugin story
We have written about WordPress several times, including a supply-chain attack through a plugin's remote feed in August. The standard advice after those incidents is to install only from official sources and keep everything updated. Here, the official source was the problem, and updating promptly during the wrong eleven hours is precisely what got you infected. Being diligent was the risk factor.
That is not an argument against updating, which remains overwhelmingly the right default. It is an argument for the thing most small businesses skip: knowing what your website can reach, and being able to tell whether it changed. A site that holds no cloud keys and has a tested backup is a bad afternoon. A site with production API keys in its config and no restore point is a different kind of event.
What to actually do
- Check your version and your update log. If you are on Rank Math PRO, find out whether anyone updated between October 15 and 16, and confirm you are now on 3.0.124 or later.
- Do not treat an update as the fix. If you downloaded in the window, assume compromise and plan a restore or a proper cleanup.
- Rotate credentials, widely. Database passwords, API keys in the site config, SSH keys on the server, and any cloud keys the host could use. Rotate them even if the site looks fine.
- Look for the leftovers: unexpected cron jobs, recently modified
.htaccess, stray.cachefiles containing PHP, admin users you do not recognise. - Ask your web developer or host directly whether they updated in that window and what they have checked. This is a specific question with a specific answer.
- Reduce what the site holds. Production cloud keys do not belong in a WordPress config if a narrower credential would do.
The takeaway
The uncomfortable lesson is that a trusted update channel is a single point of failure, and no amount of careful sourcing protects you during the hours it is compromised. What does help is unglamorous: a backup you have actually restored from, a short list of what credentials live on that server, and the willingness to rotate them rather than hoping the update was enough.