If your site runs WordPress anywhere from version 4.7 through 7.1.3, yes, it's exposed, and attackers are already using this flaw. CISA added it to its known exploited list on November 3, 2026. The fix is to confirm your version today, apply the WordPress team's patch the moment it's published, and have your host block web access to the folders WordPress uses while it upgrades itself. Everything below is how to do that without a security background.
What happened
On November 3, 2026, CISA flagged a WordPress core flaw tracked as CVE-2026-119977 as one attackers are actively exploiting. WordPress versions 4.7 through 7.1.3 put the files for a full core upgrade in predictable places that anyone on the web can reach. During that upgrade window, a stranger who isn't logged in can use those files to run their own code on your server.
That's the whole story so far. No long list of victims has been published, and I'm not going to invent one.
What this flaw means in plain words
The formal name is a race condition. Think of it as a timing gap. WordPress checks that the upgrade files are safe, then a moment later uses them. If someone can swap or add a file in that gap, WordPress runs the attacker's file instead of its own. The reason that's possible here is that the staging folder, the temporary spot where the new WordPress files sit before they're installed, is in a guessable location and reachable from the public internet.
Running your own code on a server is the worst category of flaw. It's rated CVSS 8.1, which is a high severity score on the standard scale. Once someone can execute code, they don't need your password. They can read your database, add an admin user, install a backdoor, or quietly sit there and skim WooCommerce orders. Compared with a leaked key in a frontend bundle, which I covered in API key in your frontend, this one gives an attacker the whole machine instead of one service.
Who should care
Anyone running a WordPress or WooCommerce site on version 4.7 through 7.1.3. That range is wide. It covers sites that haven't been touched in years and sites that were current a few weeks ago.
It matters most if the site updates WordPress itself. Automatic background updates and the one-click "Update Now" button both trigger a full core upgrade, which is exactly the window this flaw lives in. If a human never clicks update and auto-updates are off, the window still opens whenever someone does update, so the exposure isn't gone, it's just waiting.
Check one, find your version
Log in to your WordPress dashboard. In the left menu, go to Dashboard, then Updates. The page tells you what version you're on, and whether a newer one is waiting.
A safe answer is a version number outside the 4.7 through 7.1.3 range. An unsafe answer is anything inside it. If you can't log in, or you don't know who can, that's its own problem and the first person to ask is whoever built or hosts the site.
Don't rely on memory here. I've seen plenty of owners who were sure their site was "current" because a developer said so a year ago.
Check two, treat an affected version as exposed
If the number is anywhere from 4.7 to 7.1.3, stop treating the site as fine. Not "probably fine." Exposed.
That doesn't mean it's been breached. It means the door is unlocked and the people who try doors are already walking this street. The practical shift is that every other step below moves from "someday" to "this week," and you tell your host and developer the site is in scope.
Check three, apply the WordPress team's fix
Follow the WordPress team's own instructions for this issue and apply their fix as soon as it's published. Don't patch it with a plugin you found in a forum, and don't hand-edit core files based on a blog post, including this one. The official release is the mitigation CISA's guidance points to, and the NVD entry linked above is where the vendor reference will be tracked.
A safe answer is "we're on the fixed release and here's the version number." An unsafe answer is "we'll get to it" or "the host handles that," without anyone confirming the host actually did.
One caution. Updating is itself a core upgrade, which is the exposed window. Do check four first, or at the same time, so the upgrade folders aren't reachable while the patch goes in.
Check four, ask whether the upgrade folders are reachable from the web
This is the question most owners can't answer alone, and that's fine. Ask your host or developer, in these words, whether the folders WordPress uses while upgrading can be reached from the public web. If they can, have them block outside access to those paths at the web server level.
A safe answer is a specific one. "We've denied web access to the upgrade staging paths, here's the rule." An unsafe answer is a shrug, a "that's default WordPress," or a promise with no detail. Managed WordPress hosts may already do this. Cheap shared hosting with a default setup often doesn't. You don't need to know the config syntax, you need a named person to confirm it's done.
If you don't have a host contact or a developer anymore, that's the gap to fix before the patch, because someone has to do this work.
Check five, look for anything you don't recognize
Because this flaw is already being used, the last check is whether anything already happened. Go to Users in the dashboard and read the admin list slowly. Every account should belong to a person you can name. Go to Plugins and do the same. Then ask your developer to list files in the WordPress root and in wp-content that don't belong to a known plugin or theme, and to check file modification dates for anything recent that nobody did on purpose.
A safe answer is a boring list. An unsafe answer is a user you've never heard of, a plugin with a generic name nobody installed, or a PHP file sitting somewhere it shouldn't. Attackers who get code execution usually leave a way back in, and a stray admin user is the cheapest way back in there is.
What to do if a check fails
If the version is in range but checks three through five are clean, patch, lock the folders, and move on. Keep the user and plugin review as a habit for a few weeks.
If check five turns up something unknown, don't just delete it and hope. Change every admin password, rotate any API keys stored in the site, including payment and email keys, and take a full backup before cleaning so there's evidence of what was there. CISA's guidance on this flaw points to forensic triage for a reason. If you run a store, assume order data may have been read until someone proves otherwise. For sites where the person who built it is long gone, especially stores still on old PHP, Patch Watch is an early access service where a person applies security patches to WordPress stores for you.
What isn't known yet
I can't tell you how many sites have been hit, who the attackers are, or what they're doing once inside. CISA's listing confirms exploitation is happening, and that's the only hard fact about impact right now. I also can't tell you from here whether your specific host has the staging paths locked down. Only they can.
If you want a second set of eyes on the whole site, not just this flaw, a Ship Check is a pre-launch security review where I go through what's reachable from the outside and what shouldn't be. It's one option. The five checks above are free and you can run them today.