Technology & security · · 8 min read · By Alexander
WordPress 7.1.4: What the update vulnerability means for your website
WordPress released version 7.1.4 on 28 October 2026 and recommends installing it immediately. It fixes a race condition in the core updater, meaning an error in the timing of the update process. During this process, a temporarily unpacked copy of WordPress may be accessible via the web. Under the right conditions, this could allow third-party code to be executed without a WordPress account. According to Patchstack, the window for an attack is short; the sources reviewed provide no evidence that this specific vulnerability is being actively exploited.
What happened in WordPress 7.1.4?
During a core update, WordPress unpacks the new version under `wp-content/upgrade/`. Before the fix, the working directory name could be derived from the package name. According to Patchstack, an attacker could connect the installer accessible there via the web to their own database and execute third-party code if they reached the path in time and the installer was executable.
The attacker does not need a WordPress account for this. This does not give them permission to trigger a core update themselves. The described attack requires an update already in progress. Patchstack refers to a few seconds; no fixed duration has been established.
The patch adds 16 random characters to the working directory name, creates or retains an `index.php`, and excludes any `wp-config.php` created there from being copied. Other fixes address injected browser code (XSS), denial of service (DoS), information leaks and permissions. The sources count these issues differently.
How dangerous is the update vulnerability really?
Patchstack shows a CVSS score of 9 while also stating “Low priority / No impactful threat”. WPScan gives a score of 8,1 and rates it “high”. The relevant CVSS version and the complete scoring parameters remain unspecified. The research did not confirm a CVE or GHSA identifier.
The technical ratings and Patchstack’s practical priority should be considered separately. Patchstack attributes the low priority to the short time window: an attacker would have to reach the correct path at the decisive moment. This makes an attack more difficult but does not rule it out.
As of 29 October 2026, the sources reviewed provide no evidence of either successful exploitation or a verified, public and executable attack demonstration (Proof of Concept). This does not prove that no attacks have occurred. Suspicious requests, blocked attempts and successful HTTP retrievals alone do not prove a breach. Install the security update promptly.
Which WordPress versions are secure?
Here, “secure” means only that the fixes provided by this release for the relevant version branch are included. The following security releases were published on 28 October 2026. Older patch versions within the same branch must be updated. An appropriate backport, meaning a security update for an older branch, is sufficient for these fixes.
- 7.1.4, 7.0.8, 6.9.11, 6.8.12
- 6.7.11, 6.6.11, 6.5.14, 6.4.14
- 6.3.14, 6.2.15, 6.1.16, 6.0.18
- 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24
- 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31
- 4.9.35, 4.8.34, 4.7.39
Only the latest major WordPress version is actively supported. Backports do not promise ongoing maintenance of old installations. WordPress 4.6 and older branches did not receive a backport with this release; their historical exposure has not been fully assessed. For such legacy versions, plan a controlled move to a supported version with your support provider.
How can I check whether my website is affected?
Check the version in the backend under “Dashboard → Home → At a Glance”, or under “Tools → Site Health → Report/Info → WordPress”. Available core updates are listed under “Dashboard → Updates”. Back up the files and database first. Even after automatic updates, check the version that is actually installed; enabled background updates do not confirm successful completion.
In Plesk, if available, open WP Toolkit under “WordPress”, select the installation and its core update. Leave the offered restore point enabled. In cPanel, if activated, the tool is under “Domains → WP Toolkit”. Availability in Shared Hosting depends on the hosting configuration. If it is not available, use the WordPress backend or ask your Hoster to handle it.
For administrators: In the directory of the correct installation, `wp core version` shows the current version; after the backup, `wp core update --minor` updates within the branch. Setting an explicit target version requires a deliberate branch decision. If the update fails, contact your support provider.
What should I write to my Hoster?
You can copy and complete this template as a single message:
“Subject: Please check the WordPress core security update and upgrade directory. Hello, please check my WordPress installation at [Domain] regarding the security release of 28 October 2026. Which core version is installed? When was the last core update started and successfully completed, including the time zone? Did it run automatically or manually? If an older branch remains in use: Which backport version is installed, and does it contain the fix for the upgrade race condition? Is `wp-content/upgrade/`, including its subdirectories, accessible or browsable via the web? Are direct PHP requests there also blocked on the origin server, meaning the actual web server behind any upstream security service? Please check access and error logs around the update time for requests to unpacked installation files and suspicious subsequent activity. Distinguish between blocked attempts, successful HTTP retrievals and verified changes. After failed updates, please also check for unpacked directories left behind and whether they are accessible. Which current backup of the files and database is available, how can it be restored, and which data state would it provide? If the update is still pending: When can you carry it out, and what temporary access restriction can you put in place? Afterwards, please confirm the version and functional test. Thank you and kind regards, [Name / customer number]”
What should I do if the update cannot be installed immediately?
The patch remains the primary measure. In the meantime, Patchstack recommends blocking web access to `wp-content/upgrade/` at server level and preventing directory listing. An empty directory view does not prove that direct file retrieval is blocked. The Hoster should also check subdirectories, PHP requests and direct origin access. A protection file placed only in the temporary directory is unreliable because cleanup may remove it. The block should be configured outside this deletion area.
An explicitly configured path block in Cloudflare or another Web Application Firewall (WAF) may help. Automatic protection against this vulnerability has not been established; a directly accessible origin can bypass upstream protection. According to Patchstack, the unpacked copy does not load the PHP firewall that runs as a WordPress plugin on the main website. This cannot be applied generally to server-side security systems.
These additions to the server block are technical inferences, not officially tested WordPress configuration guidance. If neither an update nor an effective block can be implemented promptly, discuss taking the site temporarily offline with the Hoster as a last resort. This editorial assessment entails an interruption to your website’s availability.
What should I test after the update?
Open the homepage, important subpages and the navigation. Test the login, editor, media and forms. For online shops, check the basket, checkout and notifications in a suitable test workflow. Check the WordPress version again and, if there are display errors, review the cache in use.
Also check that a current backup of the files and database is available. Clarify how it can be restored and which data state it would restore.
Administrators can run `wp core verify-checksums`. Comparing the core files with WordPress.org does not prove that the entire website is clean: the database, custom configuration and all extensions are not checked conclusively. Any anomalies require a broader investigation.
Frequently asked questions about the WordPress update vulnerability
My plugins are up to date – is that enough?
No. The fix concerns the WordPress core updater. Up-to-date plugins and themes remain important, but they do not replace this core patch.
Does Cloudflare protect my website?
Using it alone does not demonstrate protection against this vulnerability. An effective path block can help if the origin server is not directly accessible. A server-side block remains advisable.
Am I affected if I use a static website export?
A purely HTML website with no accessible WordPress or PHP installation does not have this core update attack path. If the WordPress backend remains publicly accessible, that installation must be checked separately.
Do I have to move to 7.1.4, or is a backport sufficient?
The appropriate backport contains the fixes provided by this release for its branch. In the long term, the installation should move to the actively supported major version.
Has my website already been hacked?
Neither the version number nor a single log entry proves this. Have suspicious files, unexpected users, configuration changes and logs reviewed together. An update does not automatically remove an earlier compromise.
What should I test after the update?
Use the checklist above, including forms and, where applicable, shop functions. Then check the installed version and clarify the backup and restore process.