WordPress 7.1.2 Attacks Have Started – Check Your Site Now

If you updated WordPress to 7.1.2 this week, there’s now another question you need to answer. Was somebody already trying to get into your website before you installed the fix? Attacks targeting the new WordPress vulnerability have now moved beyond simple scanning, and attackers are attempting to put PHP files onto servers that can execute commands.

Today we’ve also got a newly disclosed single sign-on vulnerability, a problem underneath WordPress in the hosting layer, a very clever new piece of persistent WordPress malware, and another batch of vulnerabilities in Forminator. I’ve spent 25 years building production software and manage hundreds of WordPress websites. So today we’re looking at five developments, what they actually mean for your business, and what you should check.

Yesterday the priority was to patch. Today, the priority is to patch and potentially investigate. The critical vulnerability fixed in WordPress 7.1.2 allows an attacker with no WordPress account to make WordPress load from outside the normal theme directories.

Under the right server and theme conditions, that can become remote code execution, and attackers move quickly. Researchers saw probing less than five hours after the WordPress update was released. Now attackers have progressed from simply testing the vulnerability to attempts to write PHP files onto servers, including files containing code for executing shell commands.

Think about this like an unlocked door. Updating WordPress locks the door. But if the door was unlocked while attackers were already outside, locking it now doesn’t tell you whether somebody came in earlier.

So first, verify the site is actually on WordPress 7.1.2 or the patch release for your WordPress branch. Then, if the website remained exposed after the vulnerability became public, check your logs. Look for unexpected PHP files and investigate anything that doesn’t belong there.

For Australian businesses, this lines up with the advice we’ve already had from the ACSC. Australian organisations have been caught in global campaigns where attackers scan CMS platforms for vulnerabilities and install webshells on compromised servers. So don’t stop at “the update button worked”. Patch first, then determine whether there is anything to investigate.

Next up is a completely new disclosure from yesterday, and it affects websites using WordPress as a single sign-on system. The plugin is called WP OAuth Server, and it allows a business to use WordPress identities to log people into other websites and applications. But versions before 6.4.0 have a problem with the identity tokens they issue.

Under the vulnerable conditions, a subscriber-level WordPress user can potentially receive a correctly signed identity token belonging to another user, and that other user could be an administrator. There’s an important distinction here. This doesn’t simply mean a subscriber automatically becomes a WordPress administrator.

The danger is in the connected applications. If another application trusts WordPress as its identity provider, the attacker may be able to authenticate to that application as the other user.

Imagine your office uses one security desk to issue identity cards for several different buildings. You ask for your card, but the desk accidentally hands you a valid card belonging to the boss. The card itself is genuine; it’s just been issued to the wrong person. That’s effectively the problem here.

The vulnerability was publicly disclosed on 23 September and affects versions before 6.4.0. If your business uses WP OAuth Server, especially for SSO into other business systems, update to 6.4.0 or later. Then check which applications trust your WordPress site for authentication, because the potential impact may extend beyond the WordPress website itself.

Next, your WordPress website can be completely updated while the server underneath it still has a security problem. The vulnerability in WP Toolkit, which affects 6.11.2 and earlier, allows somebody with a legitimate cPanel account to modify databases belonging to other accounts on the same server.

Think about shared hosting. You have your apartment, and another customer has their apartment. You’re supposed to have separate keys, and this vulnerability potentially lets one tenant interfere with something inside another person’s apartment.

The fix is WP Toolkit 6.11.3 or later. But there was another serious issue in the same cPanel security release. A separate vulnerability in cPanel’s CalDAV and CardDAV functionality could allow an authenticated cPanel account to execute code as the root user, and root means control of the underlying server.

That one is not a WordPress vulnerability, but that’s exactly why it matters. WordPress security doesn’t end at WordPress. Your website depends on WordPress core, plugins, themes, PHP, the database, the operating system, and the hosting control panel underneath all of it.

So if your WordPress sites run on cPanel, particularly shared or managed hosting, ask the provider whether these September security updates have been applied. Specifically, ask whether WP Toolkit is running 6.11.3 or later.

Next up, this isn’t a newly discovered WordPress vulnerability. It’s a newly published look at what can happen after a website is compromised. Researchers have analysed a particular persistent WordPress backdoor, and it hides somewhere many site owners never check: the must-use plugins folder.

Must-use plugins work differently from normal WordPress plugins. WordPress loads them automatically, and you can’t simply deactivate them from the normal plugins screen. This malware takes advantage of that, disguising itself as a legitimate must-use plugin and containing multiple mechanisms designed to survive removal.

Delete part of the infection and another component can restore it. One copy of its code can even be stored inside the WordPress database.

Instead of simply hard-coding the address of its command server, the malware uses an Ethereum smart contract to help determine where the attacker infrastructure is. That’s sometimes called EtherHiding. It makes taking down the command channel much more difficult than simply blocking a domain.

Here’s the practical takeaway. If you’re investigating a WordPress compromise, don’t assume “I checked the plugins screen” means “I checked the plugins”. Look at the actual file system: inspect wp-content/mu-plugins, check the database and check the administrator accounts.

And if multiple WordPress sites share the same hosting account, check all of those as well, because modern WordPress malware is increasingly designed to survive the first clean-up.

And finally this morning, we’ve got another group of Forminator vulnerabilities. These are different from the Forminator issues we’ve talked about already. Several new CVEs were published yesterday for versions before 1.57.2.1.

One vulnerability allows even a basic logged-in subscriber to trigger a process that can rewrite saved Forminator field configuration, and that includes forms used for payments. Another vulnerability affects the way Forminator determines a visitor’s IP address. An anonymous visitor can manipulate forwarding headers to bypass poll voting limits and influence the IP address recorded against submissions.

Another affects forms that allow visitors to submit content which becomes a WordPress post. An anonymous visitor can supply metadata the form wasn’t supposed to let them control.

There’s also an issue with saved draft notifications. An unauthenticated visitor can potentially make the WordPress website send an email to an address they control, containing a link they also control. That creates an interesting phishing opportunity, because the email comes through the legitimate website’s mail system.

The important version here is 1.57.2.1. That security update was actually released before these details became public, so if you’re already on a newer Forminator release, you’ve got the fixes. But if you manage a site using an older version, update it now.

Then check the features you actually use: payment forms, polls, post submission forms and save drafts. Understanding whether a vulnerability matters isn’t just about asking, “Do I have the plugin?” It’s asking, “Do I use a vulnerable feature?”

So today’s priority starts with WordPress core. If you’re still running a vulnerable version, patch it now. But because exploitation has already started, think beyond the update button.

If the site was exposed, look for evidence that somebody got there first. Then check WP OAuth Server, your cPanel and WP Toolkit versions, the must-use plugins folder, and Forminator.

And remember, a vulnerable website doesn’t automatically mean a compromised website, but an updated website doesn’t automatically mean a clean website either. Patch the vulnerability, then check the risk that existed before you patched it. That’s your WordPress security briefing.