Software & Platforms

WordPress 7.1.4 Fixes an Upgrade Window Code Execution Bug and Updates Certificates After eMudhra Revocation

WordPress 7.1.4, released October 28 with backports to 4.7, fixes an unauthenticated upgrade-window race that Wordfence says attackers began probing within hours, along with stored XSS bugs and a root certificate update tied to the eMudhra revocation.

E-commerce 4 Internet Marketers Editorial

Man in a blue cardigan draws a padlock with a curved arrow on a whiteboard as neighbors on folding chairs watch at night.
At an evening neighborhood meeting, a man in a blue cardigan sketches a padlock and a looping arrow on a whiteboard while neighbors take notes, a fair stand-in for an update cycle that has to lock down cleanly.

WordPress 7.1.4, released October 28, fixes a flaw that could let an attacker with no account run code on a site during the few seconds a core update is being unpacked. Wordfence says attackers began probing for it within hours of the release. The same security release fixes a long list of stored cross-site scripting (XSS) bugs and updates the root certificates WordPress ships with, a change the release notes attribute to “the eMudhra revocation.”

Most sites will have received 7.1.4 through automatic background updates, but Wordfence recommends confirming that rather than assuming it. Stores that hold back core updates, or run an older branch, need the matching backport.

How the upgrade window flaw works

The flaw was reported by Umut Bayram. WordPress’s security advisory describes it as a race condition. During a core update that uses the complete WordPress package, affected versions extracted the new files into a predictable directory inside the upgrade folder, which the web server can reach. An unauthenticated attacker who won the race could reach remote code execution.

Wordfence adds that the temporary copy includes the WordPress installer, and that an attacker who requests that installer under wp-content/upgrade at the right moment can interact with the staged copy and work up to PHP code execution. In Wordfence’s lab tests, the staging directory usually existed for only seconds.

The two organizations rate the bug very differently. WordPress’s advisory labels it low severity. Wordfence, which assigned it CVE-2026-119977, scores it 8.1, or high, on the Common Vulnerability Scoring System (CVSS) version 3.1, while noting that attack complexity is high. Both agree it affects WordPress 4.7.0 through 7.1.3. According to Wordfence, the fix randomizes the staging directory, adds an index guard and blocks unsafe promotion of staged configuration data.

Wordfence reports probing within hours

Wordfence deployed a firewall rule for paying customers at 20:30 UTC on October 28, about three hours after the release, and says the first request matching it arrived nine minutes later. In the first 21 hours it recorded more than 18,500 requests aimed at staged setup-config.php installer paths. Two of the largest sources polled small groups of sites for roughly 14.5 hours, which Wordfence reads as attempts to catch a site mid-update.

Wordfence has not reported a confirmed compromise through the flaw. Its free users get the rule on November 27 after the usual 30-day delay. Because the attack calls a PHP file directly without loading WordPress, Wordfence says its firewall only helps when it is set up with Extended Protection, and that the rule is no substitute for updating.

Backports reach every branch back to 4.7

The release announcement said fixes would be backported to every branch still eligible for security fixes, currently through 4.7. The 7.1.4 documentation page now lists those releases, including 7.0.8, 6.9.11 and 6.8.12, down to 4.7.39. WordPress 4.6 and earlier get nothing, and the WordPress project reminds site owners that only the newest version is actively supported.

The release was led by Aaron Jorbin and Nik Tsekouras. WordPress 7.2 Beta 3 carries the same fixes, and 7.2 is planned for December 8.

The XSS and disclosure fixes

The release post credits outside researchers and members of the WordPress Security Team for the remaining issues. They include:

  • Stored XSS through crafted block markup and through Customizer selective refresh, both reported by Rafie Muhammad of Awesome Motive.
  • Stored XSS through personal data removal requests and through specially crafted user logins, both reported by Anthropic.
  • Several stored XSS issues and a stored denial of service issue in the Interactivity API, found by multiple researchers.
  • Stored XSS in the Categories block and in the Playlist and Image blocks, reported by Ben Bidner, and in the comments pagination blocks, reported by Alex Concha.
  • Unpublished Customizer changesets that unauthenticated visitors could discover, reported by Antonio Lorensius Silaban.
  • Notes readable by privileged users who lack permission to edit the post a note belongs to, reported by Ramon.

Wordfence notes that many of these require a Contributor, Author or Editor account, and some need a privileged user to view attacker-controlled content. That lowers the exposure for a store with few user accounts, but stored XSS viewed by an administrator can still lead to account takeover.

What the certificate update means for store integrations

WordPress keeps its own bundle of trusted root certificates in wp-includes/certificates/ca-bundle.crt, and its HTTP API uses that file by default for outgoing HTTPS requests. Plugins that call outside services through that API, such as payment gateways, tax calculators and shipping rate tools, depend on it. The release lists “an update to the bundled root certificates due to the eMudhra revocation” without further detail. eMudhra is an Indian certificate authority that issues certificates under the emSign name.

Most payment and shipping APIs use certificates from other authorities and should see no change. A store whose gateway or other API connection started failing right after the update, with a certificate verification error in the logs, has a reason to ask that provider which root its certificate chains to. EC4IM’s WooCommerce payment plugin checklist covers other ways to confirm a gateway connection after a core update.

Checks after the 7.1.4 update

Wordfence’s list for site owners starts with confirming the version under Dashboard > Updates. For sites that stayed unpatched for a while, it suggests reviewing logs for requests to PHP files under wp-content/upgrade and looking for unfamiliar administrator accounts, unexpected plugins or PHP files nobody put there, then running a malware scan.

Where WordPress 7.1.4 leaves store owners

WordPress 7.1.4 and its backports close a race in the core updater that, according to Wordfence, attackers began hunting for within hours of its release, even though winning it takes precise timing. The release also patches a batch of mostly authenticated XSS bugs and refreshes the trusted certificate bundle after the eMudhra revocation. The practical work for a store is short: confirm every site reached 7.1.4 or its branch’s fixed release, check upgrade folder requests on any site that lagged, and watch payment and shipping connections for certificate errors in the days after the update.

Sources