Back Mezha Wordfence blocks over 240000 requests targeting WordPress flaw | Межа
Hackers sent more than 240,000 requests targeting a WordPress core flaw as its security fix was released. The traffic does not confirm successful infections, but admins should patch promptly.
Hackers made more than 240,000 attempts to exploit a vulnerability in the WordPress core that, under certain conditions, allows malicious code to be executed without logging in. According to a Wordfence report, the attacks began on October 28, 2026 – the same day WordPress released a security update.
As reported by cybersecuritynews.com .
The vulnerability, CVE-2026-119977, is rated high severity, with a CVSS score of 8.1. It affects unpatched WordPress versions 4.7 through 7.1.3. The issue was discovered by researcher Umut Bayram.
How the WordPress vulnerability works
During a full WordPress update, WordPress extracts installation files to a temporary folder in the /wp-content/upgrade/ directory. On vulnerable sites, the names of these folders can be predicted, and the files can be accessed via a web request while the update is in progress.
The attack does not require a WordPress account or any user action. However, attackers must access the files at the right moment: this is a race condition attack, and the temporary installer must remain accessible for long enough. The files are deleted once the process is complete, so successful exploitation requires precise timing, even if hackers repeatedly check known URLs.
According to Wordfence’s analysis, access to an exposed installer may allow an attacker to complete the installation, create an administrator account, and upload malicious PHP code. The resulting access can be used to install a backdoor on the site, alter its content, or steal data.
The CVE entry describes the vulnerability as a race condition between checking and using a file. Its potential impact on the confidentiality, integrity, and availability of data is rated high. In its security release, WordPress confirmed that the issue during an update could lead to remote code execution.
More than 240,000 blocked requests
According to Wordfence, activity was highest from October 29 to November 1. It peaked on October 30, when the company’s firewall blocked more than 74,000 requests.
These figures represent blocked requests, not confirmed infections, successful code execution, or the number of targeted sites. Repeated automated checks can increase the chances of finding an exposed installer, but the number of requests alone does not prove that attackers completed an attack or maintained access.
Updates and signs of an attack
WordPress fixed the issue in its October 28 security release. Fixes are also available for older branches as backported updates. Administrators should install WordPress 7.1.4 or the corresponding patched release for their branch and verify that the automatic update completed successfully.
WordPress recommends updating as soon as possible and notes that only the latest release receives active support. Wordfence recommends restricting public access to PHP files in the /wp-content/upgrade/ directory before updating. This protection requires an advanced protection mode because temporary PHP files run outside the normal WordPress loading process.
Wordfence’s report lists the following indicators of compromise:
103.59.160[.]171 – IPv4 address.
2001:df1:e8c0[::]106b – IPv6 address.
51.89.103[.]78 – IPv4 address.
185.177.72[.]61 – IPv4 address.
195.3.220[.]7 – IPv4 address.
96.62.218[.]148 – IPv4 address.
20.217.186[.]29 – IPv4 address.
87.58.197[.]83 – IPv4 address.
154.26.238[.]8 – IPv4 address.
20.46.43[.]126 – IPv4 address.
Related paths and files include /wp-content/upgrade/ , setup-config.php , and this example installer URL: /wp-content/upgrade/wordpress-6.9.11/wp-admin/setup-config.php . Site owners should check their installed WordPress version and confirm that the fix for their branch has been applied.
Related news for you:
Hacktivists briefly defaced two US Army websites, replacing error pages with political messages; the Army removed the pages and launched an investigation into possible WordPress plugin vulnerabilities.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
