We handle all your technical problems so you can focus on growing your business.
A laptop with a dark screen beside coffee, pencils and note paper on a wooden desk.
CybersecurityPractical insight for your business.

Attackers Are Targeting a WordPress Flaw. Here's How to Check Your Business Website

A critical WordPress flaw fixed on September 22 is already under attack, and CISA has added it to its exploited-vulnerabilities list. Five questions to answer about your business website this week.

Kevin R.

6 min read

Photo by Lauren Mancke on Unsplash

The takeaway

If your website runs on WordPress, confirm it is on 7.1.2 or the patched release for its branch, find out who is responsible for it, and ask that person to check for signs of compromise from September 22 onward.

If your business website runs on WordPress, now is a good time to check it.

On September 22, WordPress released version 7.1.2 to fix a critical flaw in WordPress itself, tracked as CVE-2026-87902 (WordPress.org). Patchstack, a WordPress security company, says it saw the first attack attempts that same day (Patchstack). On September 25, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its catalog of vulnerabilities known to be exploited in real attacks (CISA).

Most coverage is written for developers. This post is for the owner or office manager who doesn’t touch the website but is still responsible for it.

What happened

The WordPress security advisory describes a flaw that lets someone with no login trick WordPress into loading a program file it shouldn’t. “If relevant pre-conditions for both the server environment and the active theme are met, this can lead to RCE” (WordPress advisory). RCE, or remote code execution, means an attacker can run their own code on your web server. WordPress rates the flaw 9.2 out of 10. It affects every version from 4.7.0 through 7.1.1.

According to Patchstack’s timeline, attackers started by quietly testing which sites responded, then moved on to trying to write their own files onto servers. By September 23, Patchstack said, traffic against the flaw was running at “more than ten times the volume we saw on the first evening.” BleepingComputer reported the attacks on September 23, and SecurityWeek and The Hacker News followed on September 24.

There is some reason for calm. In a statement to The Hacker News, Ryan Dewhurst, founder and CEO of the security firm Previdian, said “certain preconditions make exploitation less likely.” He added: “Because WordPress has auto-updates enabled by default, we’re likely to see mass-exploitation attempts, but relatively few actual compromises.” We haven’t found a reliable public count of sites actually taken over.

The two conditions, in plain terms

According to the advisory, an attacker can run code only when both of these are true:

  1. The theme. Your theme controls how the site looks. The flaw needs a theme that contains a folder whose name starts with page-. The advisory names the older Twenty Twelve and Twenty Fourteen themes and the popular Neve, Hestia and Sydney themes. Other themes can have such a folder too. A “child” theme counts if its parent theme qualifies.
  2. The server. The web server needs a PHP file that an attacker can misuse. The advisory’s example is a file from PHP’s PEAR package tool, which becomes dangerous when a specific PHP setting is turned on. It says the official PHP image for Docker is affected, and so is the default cPanel setup when running PHP versions before 8.5. cPanel is a control panel that many hosting companies use.

You can check the first condition yourself. The second is your host’s or developer’s job. Either way, the answer is the same: update. The conditions affect how bad things get, not whether you need the fix.

Five questions for your business website

1. Is my site on WordPress, and who looks after it? Ask whoever built the site, or check your hosting invoices. Another quick test: add /wp-admin to the end of your web address. If a WordPress login page appears, you’re on WordPress. If your site runs on a different platform, this flaw does not apply to you. Then write down one name, whether that’s an employee, a freelancer, an agency or your hosting company, who is responsible for updates. “I think the agency does that” isn’t an answer.

2. Which version am I running? Log in to WordPress and go to Dashboard → Updates, or Tools → Site Health → Info and open the WordPress section. You want 7.1.2 or later. If you’re on an older branch, WordPress backported the fix to every branch back to 4.7. For example, look for 7.0.6, 6.9.9, 6.8.10 or 6.7.9. The full list is in the advisory. WordPress also notes that “only the most recent version of WordPress is actively supported,” so an old branch is a reason to plan an upgrade.

3. Did the automatic update actually run? WordPress installs security releases automatically by default (WordPress developer docs). That can be switched off in the site’s configuration, however, and it doesn’t happen by default on sites a developer manages through version control. WordPress normally emails the site’s admin address after an automatic update, so search that inbox for a message around September 22 or 23. If the site isn’t updated, ask the person responsible to update it today and tell you when it’s done.

4. Is my theme on the list? Go to Appearance → Themes to see the active theme. Tools → Site Health → Info → Active Theme also shows the parent theme if there is one. If you see Twenty Twelve, Twenty Fourteen, Neve, Hestia or Sydney, treat your site as a higher priority. Your developer can check whether any other theme has a page- folder.

5. Could someone already have gotten in? Updating closes the hole. It doesn’t remove anything an attacker planted before the update. If your site wasn’t updated promptly, especially with one of the named themes, ask your developer or host to:

  • Confirm the date and time the site was updated.
  • Check the server’s temporary folders (/tmp and /var/tmp) for unexpected PHP files. Patchstack published example file names in its write-up.
  • Search the web server’s access logs from September 22 onward for requests that mention pearcmd, and compare them with the other indicators on Patchstack’s list.
  • Confirm with the host whether the server’s PHP settings were in the vulnerable state.
  • Keep those logs and a backup made before September 22, rather than letting them roll off.

If they find something, treat it as an incident: don’t just delete the file and move on. If your site collects customer information through forms or a store, talk to counsel about whether you have any notification obligations.

The bottom line

For most sites, this is a five-minute check that ends with “yes, we’re on 7.1.2.” What matters is knowing who to ask and getting a clear answer this week. It’s riskier to assume someone else took care of it.

Do you know who updates your website? If not, NightSquawk Tech offers a free assessment that can help you sort out who is responsible for your systems.

Sources

Editorial note: This article was drafted with AI assistance from the linked advisories, documentation and reporting, and its facts were checked against those sources. NightSquawk Tech did not test the vulnerability or observe the attacks described.