How do I find out which WordPress version my site runs?

Log in to the site's admin and open the Updates page under the Dashboard menu, where the current version is shown. The safe version is 7.1.2, or your branch's fixed release if the site is on an older branch, such as 7.0.6, 6.9.9 or 6.8.10. If you don't have admin access, ask the developer or host for the version in writing.

Is it enough that automatic updates are on?

Usually enough to get the fix installed, since WordPress says sites that support automatic background updates start updating automatically. But automatic updates can be switched off in the configuration file or by the host, and the fix does not remove anything an attacker planted before it arrived. Check the version yourself, and ask for a server scan if the update landed well after 22 September.

Is my site exposed if its theme isn't one of those named?

The biggest risk, code execution on the server, requires according to the WordPress advisory and researchers that the active theme contains a folder whose name starts with page-, with register_argc_argv switched on in PHP and pearcmd.php present. But the flaw itself exists in every version from 4.7.0 to 7.1.1, and the named themes are examples rather than a complete list, so the fix is the same in every case: update.

My developer keeps postponing the update because of our customised theme. What should I do?

This is a security update, and WordPress pushed it to every branch back to 4.7 so you can install it without moving to a whole new version. Test it on a staging copy of the site, then apply it to the live site. If that can't happen immediately, Patchstack says blocking directory-traversal attempts in the pagename parameter or switching off register_argc_argv breaks the attack chain for now, but it does not replace the update.

WordPress's Fix Became the Attackers' Map: First Attack Within Hours, 30,000+ IPs in Five Days

On 22 September 2026, the eve of the National Day holiday, WordPress released security update 7.1.2 to close CVE-2026-87902. The flaw isn't in a plugin or a theme. It is in WordPress core, and it affects every version from 4.7.0 through 7.1.1. The same day, at 11:49 UTC (2:49 pm Riyadh time), the security firm Patchstack saw the first attempt to exploit it, and less than four hours later the first attempt to write a file onto a site's server.

Then it spread. According to CrowdSec's report published today, 28 September, its network logged 322,680 attack signals matching the flaw from 30,813 distinct IP addresses between 23 and 27 September, peaking on 27 September at 124,154 signals. Saudi Arabia's National Cybersecurity Authority issued a Critical alert, no. 2026-7873, on 23 September, and the US agency CISA added the flaw to its catalog of known exploited vulnerabilities on 25 September.

What the flaw does, in plain terms

When a visitor requests a page, WordPress decides which theme template file to use to display it. The bug is in that step: an attacker who isn't logged in can point it at a PHP file sitting on the server outside the theme folder, and WordPress will run it. WordPress rates the flaw 9.2 out of 10; CISA rates it 8.1.

It turns into control of the site when conditions named in the WordPress advisory and in researchers' reports line up:

The theme: the active theme contains a folder whose name starts with page-. The advisory lists Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney among the themes that do.
A PHP setting: register_argc_argv is switched on, which CrowdSec says is the default in the official PHP Docker images and on cPanel servers running PHP older than 8.5.
A helper file: PEAR's pearcmd.php is present on the server. Attackers use it to write new PHP files, in other words a backdoor that survives the update.

So the flaw doesn't hit every site equally, but Security Affairs sums it up this way: code execution needs the server's setup to line up, and a lot of servers do. A business owner usually doesn't know which theme is active or how the server is configured, so the safe assumption is that the site is exposed until proven otherwise.

Why the attack came in hours, not weeks

A security update reveals where the bug is by its nature, because the code change is public. Patchstack says the first payloads matched the exact pattern the fix closed, meaning whoever wrote them worked from the fix itself rather than from independent discovery. The first attempts requested ordinary WordPress core files, such as wp-login.php and wp-cron.php, to see how sites responded, and then moved on to writing files.

The traffic also carries the fingerprints of automated scanners and published proof-of-concept code. For a business owner, that means nobody is choosing your site in particular. The tools sweep every WordPress site they can reach, and the difference between a compromised site and a clean one is whether the update landed before they did.

Does your site update itself?

Probably, but don't assume it. WordPress has had automatic background updates since version 3.7, and since 5.6 new installations auto-update both minor and major releases. The 7.1.2 announcement says sites that support automatic background updates will start updating automatically.

But automatic updates can be switched off with one line in wp-config.php. Some developers turn them off on purpose so an update doesn't break a customised theme, and some hosts manage updates on their side. A site a freelancer built years ago, whose contract has since ended, can sit on an old version nobody notices. To check:

Log in to the site's admin, open the Updates page under the Dashboard menu, and you will see the current version there.
The safe version is 7.1.2 or later. If your site is on an older branch, the fix reached every branch back to 4.7, including 7.0.6, 6.9.9, 6.8.10 and 4.7.37; the full list is in the WordPress advisory linked in the sources.
Note that WordPress says only the most recent version is actively supported. A site left on an old branch got this fix, but it is living on borrowed time. We covered what the new version adds for a company site in WordPress 7.1: the key new features.

Elementor too: one link is enough

In the same week, Elementor, the popular WordPress page builder, fixed a flaw in versions 4.3.0 and 4.3.1 only. If a site administrator opens a crafted link while logged in, an attacker can create an administrator account they control, and the link can arrive by email, chat or a comment. According to BleepingComputer, those versions run on up to 2 million sites. The fix shipped in 4.3.2 on 24 September, and the site reported no active exploitation at the time it published.

Make sure Elementor is on 4.3.2 or later, and make it a team rule: don't open links from messages or comments while logged in to the site's admin.

If your site hasn't been updated since 22 September

Update it now: if the developer is worried the update will break something, Patchstack says the path can be closed temporarily by blocking directory-traversal attempts in the pagename parameter, or by switching off register_argc_argv. That is a job for the host or developer, and it does not replace the update.
Assume your site has been probed: ask the developer or host to look for PHP files nobody added, especially in /tmp and /var/tmp, where Patchstack names files such as poc87902.php and wp-pear-rce-flag.php as signs of successful code execution.
If something turns up: treat it as an incident, not an update. Change the passwords for admin accounts, the database and hosting, restore the site from a clean backup, then update it.
If the site holds customer data: store orders, contact forms or accounts, then SDAIA's guide to personal data breach incidents requires the controller to notify the competent authority within 72 hours of becoming aware of a breach that could harm the data or the people it belongs to.

The Origami view

Many company websites are built on WordPress and then treated like a printed brochure: the developer hands it over, the owner pays, and nobody asks who keeps it updated. This flaw is a reminder that a website is a live system on an internet-facing server, and that the gap between a fix being published and an attacker arriving is now measured in hours. The real question isn't whether WordPress is secure, since it fixed the bug and pushed the fix to every branch back to 4.7. It is who in your company is responsible for installing it.

That is why we think a website maintenance contract should set a maximum time for installing critical security updates, require a staging copy where updates are tested before the live site, and keep regular backups stored off the server itself. And if updates keep getting postponed because the theme is customised in a way that breaks with every update, that is a problem with how the site was built, not with WordPress, and it deserves fixing before the next flaw.

The bottom line: three steps

Today: open the admin and confirm the version is 7.1.2 or your branch's fixed release, and that Elementor is on 4.3.2 or later.
This week: ask the developer or host to scan the server for unfamiliar PHP files and to confirm in writing that automatic updates are on.
This month: add a maximum time for installing security updates to the maintenance contract, and name the person responsible for it.

WordPress's Fix Became the Attackers' Map: First Attack Within Hours, 30,000+ IPs in Five Days