# WordPress 7.1.4 Fixes a Core Flaw Under Active Attack, Update Now

- URL: https://usa-24.com/wordpress-7-1-4-update-rce/
- Publisher: USA 24
- Section: Cybersecurity
- Published: 2026-10-31T23:13:03.893Z
- Updated: 2026-10-31T23:13:03.898Z
- Topics: WordPress, Remote Code Execution, Web Security, Patch Management, Cybersecurity

> Attackers began probing WordPress sites within days of the October 28 release of 7.1.4, which patches an unauthenticated code-execution flaw in the core update process.

## Key takeaways

- WordPress 7.1.4, released October 28, 2026, fixes an unauthenticated code-execution flaw in WordPress Core versions 4.7 through 7.1.3.
- Wordfence reported 62,969 blocked attack attempts in the first 24 hours after the release, while a second write-up cites 60,471.
- Some attackers polled small groups of sites for about 14.5 hours, trying to catch an upgrade window that is typically only seconds long in lab conditions.
- WordPress versions 4.6 and earlier no longer receive security updates, so those sites cannot receive this fix.
- Wordfence has not reported any successful compromises tied to the flaw, so reviewing your logs is the next step.

Attackers began probing WordPress sites within days of the October 28 release, and by October 30 the security firm Wordfence had counted tens of thousands of blocked attempts. The count is still climbing. The target is a high-severity flaw in how WordPress installs its own core updates, and it is fixed in WordPress 7.1.4. If you run a self-hosted WordPress site, treat this as a same-day task.

## Why the WordPress 7.1.4 update is urgent

The [WordPress 7.1.4 update](https://cybersecuritynews.com/wordpress-7-1-4-fixes-security-flaws/) shipped on October 28, 2026, and fixes 22 security vulnerabilities. The most serious is an unauthenticated remote code execution flaw, which means an attacker does not need a username or password to attempt it. The bug affects WordPress Core versions 4.7 through 7.1.3.

Millions of US sites run WordPress, including many small business pages, nonprofit sites, local government pages and personal blogs. That breadth turns a narrow timing bug into a volume problem. Automated tools can send the same request across a huge population of sites at almost no cost.

Researcher Umut Bayram is credited with reporting the update flaw in the official WordPress release notes. Patchstack counts 22 fixes across 17 advisories, so the release is bigger than the single bug drawing attacks. Administrators should read 7.1.4 as a full security release, not as a patch for one exploit.

## How the update flaw works

The weakness appears at one specific moment. When WordPress unpacks a core update, it writes the files into a temporary staging directory. According to the reporting, predictable folder names and leftover installer files can briefly expose a WordPress installer. An attacker who reaches that installer can run setup with a database the attacker controls, and that is the path to code execution.

The timing window is the hard part for attackers. Wordfence says it is typically only seconds long in lab conditions. Attackers compensate by polling vulnerable paths such as setup-config.php over and over, so a missed attempt costs them little.

Exposure depends heavily on hosting. The flaw needs the server to allow public access and PHP execution in the staging directory, according to [Ostorlab's write-up](https://blog.ostorlab.co/wordpress-core-upgrade-window-rce-cve-2026-119977.html). Alex Thomas, who leads the Wordfence Threat Response Team, said, as quoted by [The Hacker News](https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html): "Because the staging directory is web-accessible on many servers." A well-configured host that blocks direct PHP access in that directory lowers the risk, even on the same WordPress version.

## Attack volume and what the numbers show

Wordfence reported 62,969 blocked attack attempts in the first 24 hours after the release, according to The Hacker News. A separate [Cybersecurity News write-up](https://cybersecuritynews.com/60000-attacks-targeting-wordpress/) cites 60,471 blocked attempts over a 24-hour snapshot. The two figures differ, and USA 24 did not read the Wordfence post directly, but both describe the same scale of automated probing.

The duration matters as much as the total. Wordfence said two of the largest sources repeatedly polled small groups of sites for about 14.5 hours. That pattern suggests they were trying to catch the brief upgrade window rather than sweeping at random.

Speed is the other signal. One analysis cited by [Techaeris](https://techaeris.com/2026/10/30/wordpress-rce-flaw-nearly-63000-attacks/) says attackers began hunting for the flaw within nine minutes of a Wordfence firewall rule going live. Public defensive rules reveal where to look, so the gap between a rule and a patch can be measured in minutes.

Wordfence has not reported any successful compromises tied to this flaw. That is the best available news, but it is an absence of reports, not proof of safety. A site probed before it was patched may show no visible damage, so server logs matter more than the headline counts.

## Which WordPress versions are affected

The affected and patched versions, as named in the release documentation and third-party reporting, break down this way:

| Version or branch | Status |
|---|---|
| Core 4.7 through 7.1.3 | Affected by the flaw |
| 7.1.4 | Fixed, released October 28, 2026 |
| 7.0.8 and 6.9.11 | Patched branches named in the release documentation |
| 4.7.39 | Backport reaching the 4.7 line |
| 4.6 and earlier | No longer receive security updates, so no fix is available |

Sites on 4.6 or earlier are the hardest cases. WordPress has said those branches no longer receive security updates, so they cannot get this fix at all. Treat those sites as a migration project rather than a routine update.

Do not confuse this with the PHP problem. PHP itself fixed separate flaws on October 21, 2026, with versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, as [Codeable's guide](https://www.codeable.io/blog/php-vulnerability-cve-2026-109618/) explains. That fix required a PHP update, and WordPress updates alone did not close it. A site on WordPress 7.1.4 that still runs an unpatched PHP build has a separate gap, so check both.

## Severity, CVE numbers and open questions

Severity is contested. Ostorlab's write-up cites a CVSS score of 8.1, rated High, tied to a Wordfence CVE record. WordPress's own advisory reportedly rates the same race condition as Low. The disagreement matters for prioritization, but the fix is the same either way.

The CVE identifier is also unsettled. [The Hacker News](https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html) and [SecurityWeek](https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/) reported that no CVE had been assigned as of October 30. CVE-2026-119977 appears in two third-party write-ups from Rescana and Ostorlab, but USA 24 could not confirm it on an official CVE or NVD record. Treat that ID as provisional until a primary record confirms it.

CISA has not added this flaw to its catalog, as far as the sources reviewed show. Its [October 28 update](https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog) covered a VMware ESX logging flaw and a Linux kernel flaw, not WordPress. The pattern is familiar. USA 24 recently reported that a [Drupal Commerce flaw](https://usa-24.com/drupal-commerce-vulnerability-exploited/) is being exploited, and the time between a patch and mass probing keeps getting shorter.

## Steps to check and secure your WordPress site

Start with the update, then look for signs that someone got in first.

1. Update to WordPress 7.1.4 or the matching security branch. Confirm the installed version in the dashboard instead of assuming auto-updates finished.
2. Search your server logs for requests to PHP files under wp-content/upgrade. Repeated hits to setup-config.php or similar paths are the pattern to flag.
3. Review administrator accounts, installed plugins and PHP files for anything you do not recognize.
4. If your host allows it, block PHP execution in wp-content/upgrade. Hosting providers that manage many sites should apply this across their fleet.
5. If you find signs of compromise, rotate admin passwords and compare core files against a clean WordPress release before you trust the site again.

The same urgency applies to other software that touches your network. USA 24 recently covered a [TeamViewer flaw, CVE-2026-111585](https://usa-24.com/teamviewer-vulnerability-patch-now/), that lets remote hosts attack a PC, and the advice is the same: patch first, then audit.

## What to watch next

Two questions remain open. Nobody has published a count of unpatched WordPress sites, and Wordfence has described attempts rather than confirmed breaches. The next signals are an official CVE record, a CISA catalog entry if exploitation is confirmed, and any public compromise reports from hosts. If the attack counts keep rising past the first week, sites that delayed the update will carry the most risk.

## Frequently asked questions

### Which WordPress versions are vulnerable to the 7.1.4 flaw?

WordPress Core versions 4.7 through 7.1.3 are affected, according to the release documentation and third-party write-ups. The fix ships in WordPress 7.1.4, with patched branches 7.0.8 and 6.9.11 and a backport reaching 4.7.39. Versions 4.6 and earlier no longer receive security updates, so they cannot get this fix.

### How do I check whether my WordPress site has been hacked?

Look for requests to PHP files under wp-content/upgrade, unfamiliar administrator accounts, and plugins or PHP files you did not install. Wordfence has not reported any successful compromises tied to this flaw, so these checks confirm whether your site is clean. If you find signs of compromise, rotate admin passwords and compare core files against a clean WordPress release.

### Is CVE-2026-119977 the official ID for this WordPress flaw?

The ID appears in two third-party write-ups, from Rescana and Ostorlab, but USA 24 could not confirm it on an official CVE or NVD record. The Hacker News and SecurityWeek reported that no CVE had been assigned as of October 30. Treat the ID as provisional until a primary record confirms it.

### Does updating WordPress also fix the PHP2Shell problem?

No. PHP fixed separate flaws on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. That fix required a PHP update, and WordPress updates alone did not close it, so check your PHP version as well.

## Sources

1. [WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours](https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html)
2. [WordPress 7.1.4 Fixes 22 Security Flaws, Including an Unauthenticated RCE Vulnerability](https://cybersecuritynews.com/wordpress-7-1-4-fixes-security-flaws/)
3. [Hackers Launch Over 60,000 Attacks Targeting WordPress RCE Vulnerability in 24 Hours](https://cybersecuritynews.com/60000-attacks-targeting-wordpress/)
4. [Fresh WordPress Vulnerability in Attackers' Crosshairs](https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/)
5. [WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts](https://techaeris.com/2026/10/30/wordpress-rce-flaw-nearly-63000-attacks/)
6. [WordPress Core 7.1.4 Fixes an Unauthenticated Upgrade-Window Race RCE (CVE-2026-119977)](https://www.rescana.com/post/wordpress-core-7-1-4-upgrade-staging-race-rce)
7. [WordPress Core Upgrade-Window RCE, Fixed in 7.1.4 (CVE-2026-119977)](https://blog.ostorlab.co/wordpress-core-upgrade-window-rce-cve-2026-119977.html)
8. [PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do](https://www.codeable.io/blog/php-vulnerability-cve-2026-109618/)
9. [CISA Adds Two Known Exploited Vulnerabilities to Catalog (October 28, 2026)](https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog)