WordPress core was exploited twice in 2026. Here is how to check you are patched

WordPress core had a rare year in 2026. Two security releases, 7.0.2 on 17 July and 7.1.2 on 22 September, fixed flaws that the US Cybersecurity and Infrastructure Security Agency now lists as exploited in real attacks, and the September one was attacked on the day the fix came out. Most sites updated themselves automatically. This page explains what happened, who is still exposed, and the checks that tell you whether your site is one of them.

What happened, in date order

WordPress core had two critical security events in 2026, and attackers moved on both within days. Here is the sequence, with the source for each line.

Why this is news: before July 2026, CISA's catalog held no WordPress core vulnerabilities at all. The three older entries filed under WordPress are all plugins. We checked the full catalog on 23 October 2026. Our WordPress security statistics page puts this against the longer-run numbers.

Who is affected

Any site that has not taken the patched release for its branch. WordPress backported the CVE-2026-87902 fix "to all branches eligible to receive security fixes (currently through 4.7)", so the fix exists for old sites too. The question is only whether your site installed it.

• The July flaws (7.0.2): WordPress said 6.9 was affected by both vulnerabilities, 6.8 by the first only, and that versions before 6.8 were not affected.
• The September flaw (7.1.2): The Hacker News, quoting Previdian, lists the conditions an attacker needs: the active theme or its parent contains a top-level folder whose name starts with page- (for example page-templates), and a suitable readable PHP file exists on the server. Previdian's founder said those preconditions make exploitation less likely and expected relatively few actual compromises, because automatic updates are on by default.
• Sites at real risk: those with automatic updates switched off, blocked by file permissions or a host setting, or broken by a failed update that nobody noticed. Also anyone still running a vulnerable version of Elementor Pro or WooCommerce Wholesale Lead Capture.

Check your version in two minutes

The fastest check is the dashboard: Dashboard, then Updates shows your exact version. Compare it with the table below, which we took from the WordPress.org version API on 23 October 2026.

The "or later" versions in the last column are the patched releases The Hacker News listed for CVE-2026-87902: 7.1.2, 7.0.6, 6.9.9 and 6.8.10. Being on an old branch with backports is not the same as being safe in general. Old branches still require old plugins and often old PHP, which brings its own risks.

If you have shell access, WP-CLI gives a definite answer and confirms the core files have not been altered:

# exact version
wp core version

# is an update waiting?
wp core check-update

# compare every core file with the official checksums
wp core verify-checksums

Any file reported by verify-checksums as not matching is a reason to stop and investigate before doing anything else.

Make sure automatic security updates work

Automatic minor updates are what protected most sites this year, so confirm yours are not disabled. These lines in wp-config.php switch them off:

# look for settings that block updates
grep -nE "AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISALLOW_FILE_MODS" wp-config.php

• define( 'AUTOMATIC_UPDATER_DISABLED', true ); turns off all background updates.
• define( 'WP_AUTO_UPDATE_CORE', false ); turns off core updates, including security releases.
• define( 'DISALLOW_FILE_MODS', true ); blocks updates from the dashboard as well.

Some agencies set these deliberately and update by hand on a schedule. That is a reasonable choice only if a person actually applies security releases within a day or two. If nobody is doing that, remove the block or hand the job to someone who will. Also check Tools, then Site Health, which reports when background updates are not working.

Look for signs someone got in

Patching closes the door. It does not remove anyone who came in before you closed it. The reports name specific indicators worth checking.

For CVE-2026-87902

The Hacker News reported attackers writing PHP files into /tmp and /var/tmp, with file names including wp-pear-rce-flag.php, poc87902.php, luci_<random>.php and zeta_<random>.php, and abusing pearcmd.php.

# named files from the reports
find /tmp /var/tmp -maxdepth 2 ( -name 'wp-pear-rce-flag.php' -o -name 'poc87902.php'   -o -name 'luci_*.php' -o -name 'zeta_*.php' ) 2>/dev/null

# does your active theme have a top-level page-* folder? (one of the preconditions)
ls -d wp-content/themes/*/page-*/ 2>/dev/null

On shared hosting you may not see /tmp. Ask your host to run the search, or ask them for access logs from 22 September onwards.

For Elementor Pro (CVE-2026-32475)

BleepingComputer, citing the researchers, says a PHP file inside the Elementor forms upload folder is a strong sign of compromise:

find wp-content/uploads/elementor/forms -name '*.php' 2>/dev/null

For any compromise

# administrators you do not recognize
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# PHP files in uploads, which should hold none
find wp-content/uploads -name '*.php'

# scheduled tasks you did not create
wp cron event list

If any of these turn something up, do not just delete the file. The backdoor Sucuri analyzed this month keeps copies in at least eight places across files, the database and shared memory, and the report says the next page load restores the whole set. Follow the full process in how to fix a hacked WordPress site, or restore from a backup taken before the compromise, which is what BleepingComputer's sources recommended for the WooCommerce attacks.

The plugin flaws that ran alongside

Both are premium plugins, and both were attacked after the fix existed. That fits Patchstack's finding that premium components had three times more known exploited vulnerabilities than free ones in 2025. Premium plugins often update through a licence key, and an expired licence quietly stops updates. Check yours.

wp plugin list --fields=name,version,update_version,auto_update

Deadline checklist

Work down this list in order. The dates come from the sources linked on this page.

• Today: confirm you are on 7.1.3 or the latest release of your branch.
• Today: confirm automatic security updates are not disabled in wp-config.php.
• Today: update Elementor Pro to 4.2.2 or later and WooCommerce Wholesale Lead Capture to 2.0.3.2 or later if you use them.
• This week: run the indicator checks above, or ask your host or developer to.
• This week: renew any lapsed premium plugin licence so updates arrive again.
• This week: take a fresh off-site backup and test that it restores.
• Before 8 December 2026: plan for WordPress 7.2, which is scheduled for that date. See the 7.2 release guide.
• Before 31 December 2026: move off PHP 8.2 or older. See PHP 8.2 end of life.

US federal civilian agencies had a CISA deadline of 28 September 2026 for CVE-2026-87902. That deadline is binding only on those agencies, but it is a fair signal of how urgent the patch was for everyone else.

We will update this page when WordPress publishes another security release or CISA adds another WordPress core entry.

What this changes for site owners

It ends the idea that core can be ignored. For years the practical advice was to watch plugins and let core look after itself. Core was still mostly fine this year, but only for sites where the automatic updater was allowed to run.

Three lessons hold whatever happens next:

1. Patch speed is the control that matters. The first attempt on CVE-2026-87902 came the same day as the fix.
2. A patch is not a cleanup. If the site was exposed before the update, check for signs of entry.
3. Somebody has to own it. Disabled auto-updates, lapsed licences and failed updates are human problems. A maintenance plan exists so that a named person notices.