On 3 November 2026, CISA added a WordPress Core flaw, CVE-2026-119977, to its Known Exploited Vulnerabilities catalog. That means CISA has evidence the flaw is being used in attacks, not just described in a researcher's write-up. What made us stop and read closely: the flaw lives in the moment most people assume is safe, when WordPress is updating itself.
If you run a shop, a cafe, or a small business catalog on WordPress, this piece is for you. We explain the technical terms, and every date can be checked at its source.
Timeline: from the patch release to the CISA deadline
On 28 October 2026, WordPress.org shipped version 7.1.4 as a security release. Among its fixes is one item now drawing attention: a weakness in the WordPress upgrade process that can lead to remote code execution, meaning an attacker could run code on your server from a distance. The item is credited to a researcher named Umut Bayram. WordPress.org also wrote that the security fixes were backported to every branch still eligible, currently through 4.7.
Once the details were out, Wordfence recorded more than 18,500 requests aimed at WordPress's temporary installer paths in the first 21 hours. That figure comes from a security vendor and was quoted by Qualys, not by WordPress itself.
On 3 November, CISA added CVE-2026-119977 to the catalog with a deadline of 6 November 2026. That deadline applies to US federal civilian agencies under directive BOD 26-04, so it is not a legal duty for your business in Indonesia. As a yardstick, though, it is a fair one: if the organisations running thousands of systems are told to finish in three days, your online shop does not need longer. Today is 4 November, so that deadline is two days away.
What actually happens during an upgrade
This flaw belongs to a category called time-of-check to time-of-use, or TOCTOU, a kind of race condition. Picture a shop that opens its back door briefly for a delivery. The door is locked again once the boxes are in, but between unlocking and locking there is a gap. Anyone who knows the timing can slip through.
In WordPress, that gap appears during a full upgrade. The installation files are unpacked temporarily and, according to Qualys, their paths are predictable and reachable over the web. The attacker needs no account. They only have to request those files at the right moment, and the result can be code running on your server. According to Wordfence, the flaw can only be exploited while a full core update is in progress.
Two things are worth keeping straight. First, this does not mean every WordPress site is being broken into right now. Second, "the window is narrow" is not a reason to relax: the window opens every time your site updates itself, and somebody is already knocking.
The numbers, read carefully
The coverage is full of figures, and some are easy to misread. Besides the 18,500 requests above, Wordfence reported 12,632 exploit attempts blocked in the 24 hours before the report was written. That counts attempts, not sites that were actually breached. The reports we read do not give a count of sites proven compromised.
Severity scoring is not uniform either. Some reports cite a CVSS score of 8.1 (the high band), but that number appears in press coverage, not in the CISA catalog entry we opened. CISA itself lists known ransomware use as "Unknown".
The most useful figures for you are the plainest ones. Affected branches run from 4.7 up to 7.1.3, and each branch has a fixed version. According to Qualys's version table, branch 7.1 is fixed in 7.1.4, branch 7.0 in 7.0.8, branch 6.9 in 6.9.11, and branch 6.8 in 6.8.12.
Why this is a business owner's problem, not only a developer's
Our view: what is exposed by this news is not WordPress itself but the habit of "updates run on their own, so it must be fine". The WordPress.org release post says sites that support background updates will begin updating automatically. In practice, the riskiest moment can pass at two in the morning with nobody looking at the result.
In many small businesses, the answer to "who makes sure the update finished cleanly?" is silence. The site was built by a freelancer two years ago, hosting is paid from the owner's credit card, and nobody keeps a record of the version. When news like this lands, the first question is not "what is TOCTOU" but "which version are we on, and who knows?"
One more thing: the WordPress.org backport list stops at branch 4.7. If your site is older than that, it sits outside the fixes named in this release.
What you can check today
You do not need an IT team. This takes about half an hour:
- Note your WordPress version. Open the dashboard, go to Updates, and read the version number. Compare it with the fixed version for your branch.
- If auto-updates are on, check the result. A schedule is not proof an update finished. A changed version number is.
- If a host or vendor looks after the site, ask in writing. Request three things: the current version, the date the update finished, and the name of the person who checked.
- Look for what you do not recognise. Admin accounts you never created, unfamiliar plugins, or unexpected PHP files are among the things PCQuest suggests checking, along with server access logs around recent upgrades.
- Ask for public access to the temporary installer folder to be restricted, and consider a properly configured web application firewall. That is work for a developer or your hosting provider, so ask for it rather than tinkering yourself.
Ask for one thing today
Ask whoever looks after your website for one thing: the WordPress version number and the date of the last update, in writing. If the answer takes more than a day, that is your answer.
If you would like company while checking your website or business systems, reach us on WhatsApp at +62 823 1499 5005 or at bisnis@xetup.id. Just describe the situation and we will help you read it.
Sources