WordPress 7.1.4 Fixes 22 Flaws, and Attackers Are Already Probing One
On October 28, WordPress released version 7.1.4. It fixes 22 security flaws, and attackers are already probing one of them. News reports say Wordfence blocked roughly 59,000 to 63,000 attempts in one 24-hour period.
If you run a WordPress site, check your version today. This post explains the flaw in plain language and which versions fix it. It also gives you six steps to protect your site.
What WordPress fixed
WordPress calls 7.1.4 a security release. It fixes what WordPress counts as 22 vulnerabilities, and Patchstack groups them into 17 advisories. Patchstack also notes it is the seventh core security release since July. Many of the fixes address stored cross-site scripting flaws, and some date back to WordPress 4.7.
The affected range runs from WordPress 4.7.0 through 7.1.3. However, the most serious fix targets the update process itself.
The flaw attackers are probing
The flaw is CVE-2026-119977. It is a race condition in the way WordPress updates itself. During a full-package update, WordPress downloads the new version and unpacks it into a temporary folder. That copy includes the WordPress installer.
An attacker who requests that installer at exactly the right moment can run code on your server. That could let them take over the site. The window lasts only a few seconds, but attackers can automate requests and try again and again.
The ratings differ. WordPress rates the flaw Low, because an attacker must catch a site mid-update and reach the temporary folder. Wordfence rates it High, and one report cites a score of 8.1 out of 10. Both agree that you should update.
Why a security plugin may not stop it
Security plugins run inside WordPress. This attack asks for a file directly, so WordPress never loads, and the plugin never sees the request. Wordfence says its firewall can catch some attempts in Extended Protection mode, which runs before any PHP file. It also says the firewall does not replace the update.
That is why server-level protection matters. Your host can block public access to the upgrade folder. That closes the door while an update runs.
Which version to install
Your branch is the first two numbers of your version. For example, version 7.0.6 sits on branch 7.0, so you need 7.0.8. Install the fixed release for your branch:
- 7.1.4 for sites on WordPress 7.1
- 7.0.8 for sites on WordPress 7.0
- 6.9.11 for sites on WordPress 6.9
- 6.8.12 for sites on WordPress 6.8
- 5.9.20 for sites on WordPress 5.9
WordPress also says it pushed the fix to every branch that still gets security fixes, back to 4.7. However, the project says only its latest release receives active support. Plan to move to the current version.
Sites with automatic background updates may already have the fix. Check your version anyway, because automatic updates can fail.
Six steps to take today
- Open the Dashboard, then Updates, and check your WordPress version.
- Take a backup, then install the fixed version for your branch.
- Confirm that automatic security updates run on your site.
- Ask your host to block public access to the wp-content/upgrade folder.
- Remove old leftover folders inside that upgrade folder, after you take a backup.
- Check your access log for requests to setup-config.php or install.php inside upgrade paths.
If you use Wordfence, turn on Extended Protection as well. Treat that as a second layer, not a replacement for the update.
The window opens only during an update. A quick, well-tested update therefore gives attackers less time. Run updates when you can watch them finish, and confirm that the site loads afterward.
If you cannot update right away
Sometimes a plugin or theme blocks a core update. In that case, ask your host to block the upgrade folder first, because that removes the main way in. Then fix the conflict and update as soon as you can.
A site that stays on an old version for months keeps collecting risk.
Questions to ask whoever manages your site
If an agency or freelancer looks after your site, ask three questions.
- Which WordPress version does my site run today?
- Is the upgrade folder blocked from public access?
- Do you take a backup before each core update, and have you tested a restore?
A good answer arrives in minutes, not days. If you get silence, treat that as a warning.
Keep the bigger picture in view
This is one of several patches in recent weeks. We covered the October PHP flaw in critical PHP security update, and the plugin side in WordPress plugin security. Our guide to patching priorities shows how to sort the work without panic. Patching works best as a routine, not a reaction. Pick a day each month, and add an emergency path for flaws like this one.
FAQ
Is my site safe if I use a security plugin?
A plugin helps, but it may not see this attack. Update WordPress, and ask your host to block the upgrade folder.
Do I need to update if my site is small?
Yes. Attackers automate attacks like these, so site size gives no protection.
How do I know if my site was attacked?
Check your access log for requests to setup-config.php or other installer files under the upgrade path. If you find them, contact your host and change your passwords.
Will updating break my site?
Core security releases rarely change features, so the risk is small. Still, take a backup first, and check your key pages afterward.
Does WordPress update itself?
Sites that allow background updates may already be on 7.1.4. Check anyway, because automatic updates sometimes fail.
Getting started
We manage WordPress sites, including core updates, server rules, and monitoring. Book a Free Call, and we will check your version and your upgrade folder today.