Your Questions on the WordPress Update Window That Can Still Let Attackers Run Code, Answered

Patching an exploited WordPress flaw should close the door. For some sites, the act of installing that patch can open it one last time. Researcher Umut Bayram of Picus Security describes a short window during the update itself when an attacker who times it right can still run code on the server.

The walkthrough below follows The Hacker News summary of Bayram’s write-up and WordPress’s security advisory for the fixed releases.

Q: What flaw are we talking about?

CVE-2026-119977 affects WordPress 4.7 through 7.1.3. During a core update that uses a complete package, WordPress unpacks a copy of the new version into a temporary folder under wp-content/upgrade. That copy includes the installer, and the web server can usually reach it. An unauthenticated attacker who can learn the folder name and hit the installer before WordPress deletes the copy can end up running code. CISA added the flaw to its Known Exploited Vulnerabilities catalog earlier this week. Fixed releases shipped last week as 7.1.4 and matching updates for older branches back to 4.7.

Q: Why does installing the fix still leave a window?

The update that installs the fix still unpacks files using the site’s old, unpatched updater code. The fix itself randomizes the temporary folder name going forward, but on sites running 5.9 or later the old code names the folder after the downloaded file, so the name can be predicted one last time. Parts of the fix that stop a malicious wp-config.php from overwriting the live file already work during that update, because WordPress copies files into place with the new code. What remains, Bayram says, is an attacker setting up the temporary copy with their own database, logging into it, and running PHP with the web server’s permissions before the copy is deleted—enough to read or write files on the live site.

Q: Who is exposed during the update?

• Complete packages always include the installer files and create the risk window.
• Partial packages (typical for same-branch updates such as 7.1.3 to 7.1.4 in THN’s check) expose a site only if they happen to contain the installer files.
• Automatic background updates use the same updater steps.
• On 4.4 through 5.8, the old code adds random characters to the folder name, which hides it unless the site leaks the name another way (for example in an error message).
• Once 7.1.4 or a branch fix is installed, later updates use a random folder name and never copy a temporary wp-config.php over the real one.

Q: What should owners do before updating?

1. Block web access to wp-content/upgrade in the web server config (Nginx deny all, Apache Require all denied, or a root .htaccess RedirectMatch 403). WordPress talks to that folder on disk, so blocking HTTP does not break updates.
2. Do not put an .htaccess only inside wp-content/upgrade—the old updater deletes everything there before unpacking.
3. Confirm /wp-content/upgrade/ returns 403, then update to 7.1.4 or your branch’s fixed release.
4. Or update manually outside the web root: back up, unpack the new release where the web server cannot serve it, copy files into place, then restore ownership and permissions.

What this means for your company

WordPress powers a huge share of small-business sites, marketing sites and client portals. “We clicked Update” is not the same as “we were safe the whole time.” Before the next core update, lock down the upgrade folder at the web server, keep a tested backup, and prefer a maintenance window where someone can watch logs. If you already updated without that block, review access logs around the update for requests into wp-content/upgrade and treat unexplained PHP activity as an incident until proven otherwise.

Running WordPress for your company or clients and want the upgrade folder locked down before the next core update? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.

About The Author

L7 News

See author's posts