63,000 Attacks in 24 Hours: What the New WordPress Core Vulnerability Means for Your Business

WordPress ships security releases all the time, and most of them come and go without much noise. The release that landed on 28 October 2026 is not one of those. Version 7.1.4 closes a hole in the platform's own update mechanism that can let a complete stranger run code on your server, and within the first 24 hours security firm Wordfence had already blocked almost 63,000 attempts to exploit it.

The flaw affects every WordPress version from 4.7 up to 7.1.3, which covers practically every WordPress site that existed before the patch. WordPress still powers roughly four out of ten websites on the internet, so this is not a story for security researchers only. If your company website, blog or online shop runs on WordPress, it concerns you directly.

In this post we will look at what the WordPress vulnerability actually is, why attackers jumped on it within minutes, what the attack numbers do and do not tell us, and what you should do this week to keep your site safe. Let's sink in!

What the WordPress vulnerability actually is

The bug sits in WordPress core itself, not in a plugin or a theme. When WordPress performs a full-package core update, it unpacks the new files into a temporary staging folder under wp-content/upgrade. The path of that folder was predictable, and on many servers it is reachable from the open internet while the update runs. The staged copy of WordPress includes the installer, so an attacker who requests the right file at exactly the right moment can walk through the temporary installer and, from there, get to PHP code execution on the server.

The issue was reported by security researcher Umut Bayram and is tracked under the advisory GHSA-4w3m-c66w-69mg, with a CVSS severity score of 8.1 out of 10. A CVE number had not yet been assigned when the first reports went out. WordPress fixed the flaw in version 7.1.4, released on 28 October 2026, and backported the fix to older branches all the way down to 4.7. Versions 4.6 and earlier no longer receive security updates at all.

The 7.1.4 release is worth installing for more than this one bug. It addresses 22 security issues in total, including several stored XSS bugs, an information disclosure affecting unpublished Customizer changesets and an authorisation weakness in the Notes REST API. The patched version also randomises the staging directory and blocks unsafe use of staged configuration data, which removes this whole class of attack.

How the attack works, in plain English

Picture your office building during a furniture delivery. For a few minutes the front door is propped open, and anyone who happens to walk past at that exact moment can step inside. That is roughly what happens here. During a core update, WordPress briefly leaves a working copy of its installer in a folder that outsiders can reach, then cleans it up seconds later.

The catch, for attackers, is timing. In Wordfence's lab tests the vulnerable window lasted only seconds, and it only exists while a full-package update is actually running. An attacker cannot simply exploit the flaw whenever they like. So they do the obvious thing instead: they poll. Automated scripts request files like setup-config.php under wp-content/upgrade over and over, around the clock, hoping to catch a site in the middle of an update.

That is exactly what the traffic data shows. Two of the largest attack sources kept hammering small groups of sites for about 14.5 hours straight, cycling through version names and staging paths. This is not a skilled, targeted operation. It is a numbers game played by bots, and any WordPress site on the internet is a potential ticket.

Who is actually at risk

Any site running WordPress 4.7 through 7.1.3 carries the vulnerable code. The practical risk is concentrated in the moment of updating: the flaw is only exploitable while a full-package core update is in progress and the staging folder is reachable over the web. Sites on hardened hosting that blocks direct access to wp-content/upgrade are in better shape, but plenty of shared hosting does not block it.

There is an uncomfortable irony here. The safest thing you can do for your site, updating it, is also the brief moment when this attack can land. That is not a reason to delay. The patched version removes the vulnerable behaviour altogether, while leaving your site on an old version gives the bots an unlimited number of chances. Wordfence reported no confirmed compromises so far, but blocked attempts only count the traffic that passed through their firewall. Sites without such protection do not show up in anyone's statistics.

One more group should pay close attention: owners of sites still on WordPress 4.6 or older. Those versions receive no security fixes anymore, for this flaw or any future one. If that is you, the real task is not this patch. It is a migration plan.

What the numbers really tell us

The headline figure is dramatic: 62,969 blocked exploit attempts in 24 hours. The more telling number is nine minutes. That is how long it took, after Wordfence switched on its protective firewall rule, for the first matching attack to arrive. Attackers now move from a public security advisory to live exploitation within hours, sometimes minutes, and they automate everything.

Another detail deserves attention. Wordfence shipped the firewall rule immediately to its paying customers, while free-tier users receive it after the standard 30-day delay, at the end of November. Security vendors have to fund themselves somehow, and the gap illustrates a point every site owner should understand: a free security plugin is not the same protection as a maintained, paid security setup, especially in the first weeks after disclosure, which is exactly when attacks peak.

And the attacks will continue well past the news cycle. Bots do not read headlines; they scan. Sites that remain unpatched in three or six months will still be probed by the same scripts, long after everyone has stopped writing about this flaw.

What you should do this week

First, check your WordPress version under Dashboard, then Updates, and install 7.1.4 or the matching patched release for your branch. Do it at a quiet time for your site, and take a backup first so you can roll back if anything in your theme or plugins misbehaves.

Second, do a short health check after the update. Look in wp-content/upgrade for leftover PHP files, review your access logs for odd requests to that folder, and scan the admin user list for accounts you do not recognise. Check the plugin list too. Updating closes the hole, but it cannot prove that nobody got in earlier, so ten minutes of checking is worth the effort.

Third, if you control your server or use a CDN, consider blocking direct HTTP access to wp-content/upgrade entirely. WordPress never needs that folder to be publicly readable, and the restriction costs nothing. If an agency or a freelancer maintains your site, ask them to confirm, in writing, that the update has been applied and the checks done. A one-line email is enough, and it tells you quickly whether anyone is actually maintaining the site.

The bigger lesson for business owners

Stories like this one rarely change what security professionals do. They should change how business owners think about their websites. A website is not a brochure you print once; it is software that runs on a server, and software needs maintenance whether or not anyone in your company is watching. The attacks started nine minutes after the defence went up. Nobody's manual Tuesday checklist competes with that.

That leads to a few practical conclusions for anyone running a digital product. Updates need to be someone's explicit job, whether an employee, an agency or a managed hosting provider, with a defined response time for security releases. Backups need to exist and be tested, because a backup you have never restored is a hope, not a plan. And staging environments matter: a business that can test an update safely applies it sooner, and speed is the whole game here.

If nobody in your organisation wants to own any of this, that is a legitimate answer too, as long as you draw the right conclusion from it: choose a platform or a hosting arrangement where patching is handled for you, rather than quietly leaving the job to nobody. We see both sides of this in client projects all the time. WordPress is a fine platform when it is looked after and a liability when it is not, and the difference is rarely the technology. It is whether maintenance has an owner.

Final notes

The WordPress team handled this one well: a responsibly disclosed flaw, a fix within a sensible timeframe, backports to old branches and a clear advisory. The attackers handled it exactly as expected too, which is the part worth remembering. The window between a patch being published and exploit attempts arriving is now measured in minutes, not weeks.

So treat this as a cheap fire drill. Update to 7.1.4, spend ten minutes on the checks above, and then ask the more useful question: if the next flaw is worse and nobody is watching your site, what happens? If you do not like the answer, fix the process, not just the version number.