A WordPress Core time-of-check time-of-use (TOCTOU) flaw was exploited in the wild and was added Nov. 3 to the known exploited vulnerabilities (KEV) list by the Cybersecurity and Infrastructure Security Agency (CISA).
The high-severity CVSS 8.1 flaw — CVE-2026-119977 — could let unauthenticated attackers execute code on the server during the upgrade process because of predictable, web-accessible staging paths used by WordPress during full-package core upgrades.
CVE-2026-119977 was publicly disclosed and published on Oct. 31, although the underlying WordPress Core 7.1.4 patch was released on Oct. 28 and the actual CVE record lists Oct. 28 as the disclosure date.
“When a high-severity core vulnerability moves from disclosure to active exploitation in days, it exposes the relentless pressure on security teams,” said Shane Barney, chief information security officer at Keeper Security. “Threat actors are aggressively scanning for CVE-2026-119977 because remote code execution gives them immediate, unauthenticated control at the server layer.”
Barney said the real danger here isn't just a compromised web page: it’s what attackers do once they gain that initial server foothold. Web servers routinely sit adjacent to production databases, internal service accounts and API keys, said Barney. So, when an adversary executes arbitrary code, they can harvest local secrets and pivot deeper into enterprise infrastructure.
“Remediation cannot stop at applying the patch,” said Barney. “Upgrading to WordPress Core 7.1.4 is non-negotiable and must happen immediately, but security teams must also verify whether exploitation occurred during the window of vulnerability. If a compromise is suspected, organizations must immediately rotate any database passwords, API keys or service credentials that were stored locally on or accessible to that web server.”
Sina Chehreghani, head of threat intel and threat research at Securonix, said the flaw operates as a TOCTOU race in WordPress Core’s full-package update process. Here's how it works: During an update, WordPress extracts new files into a predictable directory under the web-accessible upgrade folder. An unauthenticated attacker who reaches that staging area before the files are moved or removed may be able to invoke PHP code there and execute commands with the web server’s privileges.
“The window is brief, but exposed sites can be targeted while an update is in progress, including an automatic update,” said Chehreghani. “Patching closes the vulnerable update path, but teams should also check web server logs for requests to files under wp-content/upgrade/ during update windows, especially requests followed by unexpected PHP processes or outbound connections.”
Waseem Ahmed, head of engineering at Secure.com, explained that we’re seeing another example of how attackers exploit operational blind spots that traditional vulnerability management and periodic pentests can miss. A patch doesn't necessarily mean a vulnerability has been closed: the process of installing the patch can itself create a brief exposure that attackers can automate and repeatedly probe.
“Attackers don't need a large window of opportunity,” said Ahmed. “Even a few seconds of exposure can be sufficient when automated tools continuously monitor vulnerable targets.”
Ahmed said SOC teams should monitor the entire vulnerability remediation process, not simply whether a patch has been applied. Treat software updates as potential attack windows, not automatically safe maintenance activities.
Here are five remediation recommendations:
- Patch strategically: Before upgrading to WordPress 7.1.4, block external web requests to PHP files under /wp-content/upgrade. The final update from a vulnerable version can otherwise expose the flaw one last time.
- Monitor update activity: Look for repeated requests to setup-config.php and other PHP files within upgrade directories, particularly requests returning HTTP 200 responses.
- Hunt for evidence of compromise: Check for unauthorized administrator accounts, unfamiliar plugins, unexpected PHP files and modifications to wp-config.php.
- Correlate suspicious activity: Connect unusual web requests with the affected asset, its owner, and any associated endpoint or server activity. Pay particular attention to PHP-FPM or Apache spawning shell commands or utilities such as curl, wget or Python.
- Validate remediation: Don't close a vulnerability ticket simply because the software version has changed. Retest externally to confirm that attackers can’t access the vulnerable path.
