WordPress core flaw: why automatic updates matter right now

An actively exploited flaw in WordPress Core strikes during the update itself. What CEOs and CISOs need to know, and what to do this week.

An update is the moment you feel safest. The new version is ready, the box is ticked, the job is done. Yet for WordPress, those few seconds were exactly when the door stood ajar. Since 3 November, CVE-2026-119977 has been on the US CISA catalogue of actively exploited vulnerabilities. And this time it isn't some obscure plugin. It's the core of WordPress itself.

That distinction matters more than it sounds. For years the WordPress security story was simple: the core is solid, the plugins are the problem. Keep your plugins current and you could sleep at night. This week, that comfort expired.

What's going on

The flaw lives in the WordPress Core update process, in versions 4.7 through 7.1.3. During a full update, WordPress unpacks a complete copy of itself into a temporary folder that is reachable from the web. An attacker who finds that folder at the right moment can run code on your server without an account. In industry terms: remote code execution, the most serious class of bug there is. Its CVSS score, the standard severity scale, is 8.1 out of 10.

The window is short. Wordfence says that in lab conditions it lasts only seconds. Hardly a threat, you might think. But attackers don't wait for the right moment; they simply keep knocking. In the first 21 hours after disclosure, Wordfence logged more than 18,500 requests aimed at the affected installer files, and it has blocked over 12,600 exploit attempts in a single day. CISA has given US federal agencies until 6 November to patch, and the Centre for Cybersecurity Belgium urges organisations to update with the highest priority.

The fix has been out since 28 October: WordPress 7.1.4, with backports to older branches down to 4.7.39.

Why this belongs in the boardroom

Your website stopped being a brochure long ago. It runs on a server, talks to your CRM, collects form data and carries your brand. Whoever takes over that server gets more than a defaced homepage: they get a trusted address on the internet that your customers already believe in. Under NIS2, boards must show they manage risks like this, and leaving a known, actively exploited vulnerability open is hard to defend. Vulnerability management and patch management aren't IT housekeeping here. They're liability.

Through the attacker's eyes

At XPOSE, we think like the other side. What follows are scenarios, not a reconstruction of specific attacks and certainly not a how-to.

The update is an appointment. Most WordPress sites update automatically, at largely predictable times. An attacker doesn't need to guess the window. They can watch thousands of sites at once and wait for one to open. The irony: the update to 7.1.4 runs the old, vulnerable code one final time.

Your security plugin is looking the other way. The weakness sits in a temporary copy of WordPress, not in the live site. The plugin that reassures you sees little or none of it. Protection has to come from the web server or the firewall.

The forgotten site is the real target. Every organisation has them: the 2021 campaign microsite, the event page on a marketing subdomain, the agency's staging environment. Nobody owns them, nobody checks the version. To an attacker, that isn't a side issue. It's the easiest way in, with your name on the door.

The website is a stepping stone. Web servers often hold credentials for databases, mail servers or integrations with internal systems. From one compromised site to your internal network is, in practice, often a shorter hop than you'd like.

Your own site as bait. A patient attacker doesn't break in to vandalise. They quietly plant malicious code on pages your customers, partners or staff visit, the so-called watering hole. Or they use your domain to make phishing emails convincing. Your brand becomes the weapon.

And the plugins haven't gone anywhere. Since early October, the Bricksforge plugin has been actively exploited through CVE-2026-85097, rated 9.8 to 10 for severity. Core and plugins: bet on only one and you lose on the other.

What to do this week

1. Check every WordPress install is on 7.1.4 or the patched release for its branch. Don't blindly trust automatic updates; they can fail silently.
2. Start with an inventory. Have someone map every WordPress site running under your domains, including marketing and agency subdomains.
3. Block public access to wp-content/upgrade/ at web server or firewall level, and switch off directory listing. Do it before you update.
4. Turn on automatic updates, and monitor them. An alert for a failed update matters as much as the update itself.
5. Review your logs for suspicious activity around the upgrade folder. A patch closes the door; it says nothing about who's already inside.
6. Separate your web server from your internal network and keep shared credentials off it.
7. Pin your web agency down in writing: who patches, how fast, and who reports incidents.

Final thoughts

This vulnerability makes clear something many executives hadn't quite registered: website security doesn't start with plugins, but with accepting that even the update itself is an attack moment. The question isn't whether your website is interesting. It's which of your sites you've forgotten about.

XPOSE Security tests your environment the way real APT attackers would: from the forgotten marketing site to the jump into your internal network. Better we find it than they do. Get in touch and strengthen your security posture structurally with our CISO as a Service.