EN PT-BR
← Voltar ao feed
critical

WordPress 7.1.4 fixes 22 flaws; Core upgrade race-condition RCE (CVE-2026-119977 per one source, CVSS 8.1) under attack attempts

4 fonte(s) · 6 atualização(ões) · publicado 28/10/2026 15:34 · coletado há 1 dia

Matéria consolidada. Reúne 8 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que as 4 fontes trouxeram em 01/11/2026 00:02; os links antigos trazem para cá.

Fontes: gbhackers.com ×3 ↗ thehackernews.com ↗ securityweek.com ↗ patchstack.com ↗

WordPress 7.1.4, released on 28 October 2026, fixes 22 vulnerabilities across 17 advisories, compared with seven in 7.1.3 three weeks earlier (patchstack.com). Nearly all of them require an authenticated account, usually Contributor. The headline fix is a race condition in the core upgrade process that can lead to unauthenticated remote code execution, reported by Umut Bayram (gbhackers.com) via Wordfence. It affects WordPress 4.7 through 7.1.3 and is rated CVSS 8.1 (gbhackers.com, thehackernews.com, securityweek.com). A later gbhackers.com article (31 October) identifies it as CVE-2026-119977, while securityweek.com and thehackernews.com had reported that no CVE was assigned. Since 30 October, Defiant (Wordfence) telemetry shows attackers probing it within hours of the release: the first firewall rule match came nine minutes after the rule was deployed, and there were over 18,500 requests against staged setup-config.php paths in the first 21 hours (securityweek.com, gbhackers.com). Wordfence later reported blocking 62,969 attempts in 24 hours (thehackernews.com), and gbhackers.com on 31 October cites 58,693 blocked attacks in 24 hours. These are attempted exploits and no successful compromises have been reported (securityweek.com, gbhackers.com). Patchstack rated the flaw AC:H and did not consider it practical to exploit (patchstack.com). Backports shipped the same day for every supported branch down to 4.7.39.

Entenda a falha

A vulnerabilidade

The headline flaw is a race condition in the WordPress core upgrade process that can lead to unauthenticated remote code execution. It is rated CVSS 8.1 with high attack complexity. Only gbhackers.com names it CVE-2026-119977; securityweek.com and thehackernews.com said no CVE had been assigned. It affects WordPress 4.7 through 7.1.3. The attacker needs no account and no interaction, but needs web and PHP access to wp-content/upgrade during a full-package update and has only seconds to act. WordPress 7.1.4 (28 October 2026) fixes it, with backports to 7.0.8, 6.9.11, 6.8.12, 6.7.11 and down to 4.7.39. The same release fixes 21 other flaws, mostly needing a Contributor account (Interactivity API, XSS, Customizer preview disclosure, REST comments authorization).

Como funciona

When WordPress installs or updates, it extracts the package into wp-content/upgrade/, which the web server serves like any other directory. Before 7.1.4 the folder name came from the package, so it was predictable for admin uploads, and the cleanup routine that runs first also deleted the protective index.php. For the few seconds the update runs, a full WordPress copy is reachable, including wp-admin/setup-config.php, which starts without the site's configuration. A visitor who requests it in time can interact with the temporary installation, and this can progress to PHP code execution. Attackers therefore poll paths repeatedly to catch an update in progress.

Por que é vulnerável

The upgrade staging area was web-reachable, had a predictable name and was not protected while it held a runnable copy of WordPress. Cleanup even removed the index.php that blocks directory listing. Patchstack says the sink dates back to WordPress 2.8 and the window returns on every update, including unattended ones. The articles do not say why it went unnoticed. 7.1.4 appends 16 random characters to the folder name, recreates index.php and stops deleting it. It also adds wp-config.php to the files never copied out of the working directory, which blocks unsafe promotion of staged configuration data.

Onde está

The directory wp-content/upgrade/ (its extraction folder naming, cleanup routine and index.php) and the staged wp-admin/setup-config.php; Patchstack says a second change in update-core.php adds wp-config.php to the files never copied out of the working directory.

Como foi descoberta

gbhackers.com, citing the official advisory and a Wordfence advisory, says researcher Umut Bayram reported the flaw. The articles do not say how he found it or when he reported it. It became public with the 7.1.4 release on 28 October 2026. Wordfence deployed a firewall rule at 20:30 UTC that day and saw its first match nine minutes later, then over 18,500 requests against staged setup-config.php paths in 21 hours. It later reported 62,969 blocked attempts in 24 hours (thehackernews.com), while gbhackers.com cites 58,693; the figures are not reconciled. Two sources polled small groups of sites for about 14.5 hours. These are attempts, and no successful compromise has been reported. Patchstack rated it AC:H and not practical to exploit.

Explicação gerada por IA a partir da matéria e dos artigos, em 01/11/2026 00:17.

Detalhes técnicos

  • Upgrade race condition (unauthenticated RCE): during installs and updates WordPress extracts the package into wp-content/upgrade/, which the web server serves. Before 7.1.4 the extraction folder name was predictable for admin uploads, and the cleanup routine also deleted the protective index.php. For the few seconds an update runs, a full WordPress copy is reachable and browsable, including wp-admin/setup-config.php, which can run the installer against an attacker-controlled database. An unauthenticated attacker who reaches the staged setup-config.php before cleanup can interact with the temporary installation and potentially achieve PHP code execution (gbhackers.com). The sink dates back to WordPress 2.8, and the window recurs on every update, including unattended ones. A PHP firewall cannot block it because the extracted copy loads without any mu-plugins (patchstack.com). It is distinct from the earlier page-template path-traversal flaw (gbhackers.com, thehackernews.com).
  • Exploitation conditions: the attacker must win a race and meet four conditions: a full-package update containing the installer files, public web and PHP access to the staging tree (PHP execution within that directory tree), a predictable or discovered staging path, and enough time before WordPress cleans up the temporary files. The window lasts only seconds in lab environments, hence the high attack complexity (thehackernews.com, securityweek.com, gbhackers.com).
  • Observed attacker activity: repeated polling of paths such as setup-config.php and many staging-directory and version-name variations. Two of the largest sources polled small groups of sites for about 14.5 hours, consistent with trying to catch the brief upgrade window. Wordfence noted that not every request used the exact vulnerable path, but the sustained polling and exact-layout probes show attackers quickly understood the race (thehackernews.com, gbhackers.com). Exploitation requests PHP files directly without loading WordPress (gbhackers.com).
  • Interactivity API (7 advisories): KSES allows any data-* attribute, and every Interactivity directive is a data-* attribute, so a Contributor can store directives that pass filtering and are acted on by the client runtime. This enables javascript: URL bindings, bindings onto on* handlers, __proto__ keys in the context merge (prototype pollution) and bindings on object elements. A CSS parser flaw causes a denial of service that hangs the visitor's browser tab, not the server. The client runtime shipped in 6.4 and the PHP class in 6.5, so both versions are listed as affected (patchstack.com). Separately, the Interactivity Router mishandles uploaded text files, an Author-level flaw (gbhackers.com).
  • Script module data shadowing: getElementById() returns the first element with the ID, so stored content can supply the runtime's state ahead of the real data block (patchstack.com). Post content can no longer shadow Script Module data through matching element IDs (gbhackers.com).
  • Selective refresh: post content could declare partials whose selector went to jQuery $(), which builds HTML for strings starting with < (patchstack.com).
  • Customizer preview: a request without a changeset UUID adopted the latest unpublished changeset with no capability check, exposing the UUID and rendered preview to anonymous visitors (patchstack.com). Unauthenticated visitors can no longer discover unpublished Customizer changes (gbhackers.com).
  • Block fixes: the Categories block expanded format directives after wp_kses_post() through sprintf(). The Image and Playlist blocks used preg_replace() with attacker-influenced replacement text. The Comments Pagination and Post Navigation Link blocks printed labels unescaped (patchstack.com).
  • Block delimiter whitespace: PHP and JavaScript disagree on what counts as whitespace, so a delimiter can be an inert comment to PHP and a real block with attacker-controlled attributes to the editor, leading to stored XSS (patchstack.com, gbhackers.com).
  • REST comments controller: moderate_comments alone allowed reading, editing and deleting notes on posts the user could not edit, mainly relevant with custom roles (patchstack.com, gbhackers.com).
  • Reports credited to Anthropic: an editor-level stored XSS tied to personal data erasure requests, and a username escaping issue on multisite Network Users screens (gbhackers.com).
  • Certificates: root certificates were bundled following the eMudhra revocation (gbhackers.com, securityweek.com).

Remediação

  • Update to WordPress 7.1.4 as soon as possible via Dashboard → Updates → Update Now, and verify that automatic background updates actually completed rather than assuming they did (gbhackers.com, thehackernews.com).
  • 7.1.4 randomizes the staging directory, adds an index guard and blocks unsafe promotion of staged configuration data (securityweek.com, gbhackers.com).
  • Patched branches: 7.0.8 and 6.9.11 fix all 22 issues; 6.8.12 and 6.7.11 fix the 20 that affect them. Legacy releases are patched down to 4.7.39, but only the latest version is actively supported (gbhackers.com, patchstack.com).
  • Do not defer remediation until WordPress 7.2, scheduled for December 8, 2026 (gbhackers.com).
  • Hunt for suspicious requests to PHP files under wp-content/upgrade, check for unfamiliar administrator accounts, plugins or PHP files, and scan for unauthorized files (thehackernews.com, gbhackers.com).
  • A successful update or blocked-attack statistics do not prove that a previously exposed server escaped compromise; suspicious findings require incident response (gbhackers.com).
  • Wordfence Premium, Care and Response received a protective rule on 28 October at 20:30 UTC; free users receive it on 27 November. Enable Extended Protection (verify firewall optimization), since exploitation requests PHP files directly without loading WordPress; filtering does not replace patching (gbhackers.com).
  • Patching is the primary control: Patchstack states a PHP firewall running through mu-plugins cannot mitigate the upgrade race condition (patchstack.com).

Relatos divergentes

  • Exploitation status: the earlier version of this record, based on gbhackers.com and patchstack.com, said neither source reported exploitation in the wild. That is outdated. gbhackers.com (30 and 31 October), securityweek.com and thehackernews.com now report active exploitation attempts based on Wordfence telemetry. The attempts are probes and no successful compromise has been reported (securityweek.com, gbhackers.com); the later Wordfence-based reports are the more recent.
  • Severity and CVE: the earlier gbhackers.com text said no individual CVE identifiers or severity scores were assigned. securityweek.com and thehackernews.com confirm CVSS 8.1 but no CVE assigned. The most recent gbhackers.com article (31 October) names CVE-2026-119977 (CVSS 8.1). This identifier appears in only one source and is not corroborated by securityweek.com or thehackernews.com, which stated that no CVE had been assigned; gbhackers.com is the more recent. patchstack.com rates it AC:H (high attack complexity).
  • Exploitability of the RCE: patchstack.com does not consider it practical to exploit, while securityweek.com acknowledges high attack complexity but Wordfence observes ongoing attacker polling. The observed activity is the more recent evidence of real-world interest, though no compromise is confirmed; both recommend patching.
  • Volume of attempts: gbhackers.com and securityweek.com cite over 18,500 requests against staged setup-config.php paths in the first 21 hours, thehackernews.com cites 62,969 blocked attempts in 24 hours, and the later gbhackers.com article (31 October) cites 58,693 blocked attacks in 24 hours. The figures cover different windows and measures, all attributed to Wordfence; the 58,693 and 62,969 figures are not reconciled, and gbhackers.com's is the most recent dated figure.
  • Firewall mitigation: patchstack.com says a PHP firewall cannot block the flaw, while gbhackers.com says Wordfence delivered a rule and advises enabling Extended Protection because requests hit PHP files directly. The Wordfence approach operates before WordPress loads; patching remains the reliable fix.

Linha do tempo

  1. gbhackers.com ↗ · pub. 31/10/2026 04:03 · coletado 31/10 05:00

    WordPress Core unauthenticated RCE CVE-2026-119977 under active attack, 58,693 attempts blocked by Wordfence in 24 hours

    ler a análise desta fonte

    Attackers are actively attempting to exploit CVE-2026-119977 (CVSS 8.1), an unauthenticated remote code execution flaw in WordPress Core that affects versions 4.7 through 7.1.3. Wordfence reports 58,693 blocked attacks within 24 hours. These are attempts, not confirmed compromises. WordPress 7.1.4, released on October 28, 2026, fixes the flaw along with 21 other vulnerabilities. Exploitation depends on a brief timing window during full-package Core upgrades, so attackers poll repeatedly to catch it.

    Technical Details

    • During full-package Core upgrades, vulnerable installs extract files into predictable directories under wp-content/upgrade. These can remain reachable over the web while the update runs.
    • An unauthenticated attacker who reaches the staged setup-config.php before cleanup can interact with the temporary installation and potentially achieve PHP code execution.
    • Exploitation requires installer files, publicly reachable staging paths, PHP execution within that directory tree, and enough time to finish the attack. The window reportedly lasts only seconds in lab observations, hence the high attack complexity.
    • Wordfence saw its first firewall-rule match nine minutes after deployment and more than 18,500 requests targeting staged installer paths in the first 21 hours. Two major sources polled small groups of sites for about 14.5 hours.
    • The fix randomizes staging directories, adds an index guard and prevents unsafe promotion of staged configuration data. Fixes were backported to older branches, although WordPress identifies only its latest version as actively supported.
    • Exploit requests can reach staged PHP files without loading WordPress, so Wordfence Extended Protection matters for coverage.

    Remediation

    • Install WordPress 7.1.4 or the corresponding patched branch release (Dashboard > Updates).
    • Wordfence deployed its firewall rule on October 28 at 20:30 UTC for Premium, Care and Response customers. Free users receive it on November 27. Verify firewall optimization (Extended Protection); filtering does not replace patching.
    • Inspect logs for unexpected requests beneath wp-content/upgrade. Investigate unfamiliar administrator accounts, unauthorized plugins and suspicious PHP files.
    • A successful update or blocked-attack statistics do not prove that a previously exposed server escaped compromise. Suspicious findings require incident response.
  2. thehackernews.com ↗ · pub. 30/10/2026 11:08 · coletado 30/10 15:00

    WordPress Core unauthenticated RCE race condition (versions 4.7-7.1.3) draws nearly 63,000 exploit attempts in 24 hours

    ler a análise desta fonte

    Threat actors are actively attempting to exploit a high-severity (CVSS 8.1) remote code execution flaw in WordPress Core versions 4.7 through 7.1.3. The flaw has no CVE identifier, and patches shipped on October 28, 2026 in version 7.1.4. Wordfence reported blocking 62,969 attack attempts in 24 hours. Two of the largest sources repeatedly polled small groups of sites for about 14.5 hours, consistent with trying to catch the brief upgrade window.

    Technical Details

    • During full-package Core upgrades, WordPress unpacks the new files, including the WordPress installer, into a predictable directory under wp-content/upgrade.
    • On many servers this staging directory is web-accessible. An unauthenticated attacker who requests the installer at the right moment can interact with the staged WordPress copy and progress to PHP code execution.
    • Exploitation requires winning a race condition and meeting four conditions: a full-package update containing the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time before WordPress cleans up the temporary files.
    • The window lasts only seconds in normal lab environments. Attackers are repeatedly polling paths such as setup-config.php and testing many staging-directory and version-name variations.
    • Wordfence noted that not every request used the exact vulnerable path, but the sustained polling and exact-layout probes show attackers quickly understood the race condition.

    Remediation

    • Update to WordPress 7.1.4 as soon as possible.
    • Look for suspicious requests to PHP files under wp-content/upgrade.
    • Check for unfamiliar administrator accounts, plugins or PHP files.
  3. securityweek.com ↗ · pub. 30/10/2026 09:04 · coletado 30/10 10:00

    Attackers probe unpatched WordPress Core update race condition hours after 7.1.4 release

    ler a análise desta fonte

    Defiant (Wordfence) reports that threat actors began attempting to exploit a newly patched high-severity WordPress Core vulnerability within hours of the WordPress 7.1.4 release on October 28. The flaw is an unauthenticated race condition in the Core update process that can lead to remote code execution, though attack complexity is high. No CVE has been assigned yet. Wordfence telemetry logged the first firewall rule match nine minutes after deployment and more than 18,500 requests against staged setup-config.php installer paths in the first 21 hours. No successful compromises have been reported so far.

    Technical Details

    During a full-package Core upgrade, WordPress unpacks new files into a predictable, web-accessible staging directory. An attacker with public web and PHP access to the staging tree, knowledge of the path, and the ability to hit the seconds-long window before cleanup can reach installer files such as setup-config.php and achieve code execution. Exploitation requires no account on the target site. Observed activity consists of repeated polling of the vulnerable staging paths to catch the narrow window.

    Remediation

    Update to WordPress 7.1.4, which randomizes the staging directory, adds an index guard, and blocks unsafe promotion of staged configuration data. Fixes were backported through branches down to WordPress 4.7. The release also patches 22 security defects in total, including XSS issues, interactivity API bugs, an unauthenticated information disclosure flaw and an authorization weakness, and updates bundled root certificates following the eMudhra revocation.

  4. gbhackers.com ↗ · pub. 30/10/2026 04:15 · coletado 30/10 06:00

    WordPress 7.1.4 patches 22 flaws including actively exploited unauthenticated RCE in Core upgrade staging

    ler a análise desta fonte

    WordPress 7.1.4, released October 28, 2026, fixes 22 vulnerabilities, including an unauthenticated remote code execution flaw in the Core upgrade process that is already under active exploitation attempts. Reported by researcher Umut Bayram via Wordfence, the issue (CVSS 8.1) affects WordPress 4.7 through 7.1.3 and abuses predictable staging directories under wp-content/upgrade that contain the WordPress installer. If the server allows public access and PHP execution in that directory, an attacker can request the staged setup-config.php and execute code without credentials. Wordfence reported the first matching exploit attempt nine minutes after deploying a protective rule, and over 18,500 requests against staged setup-config.php paths in the first 21 hours, with two prominent sources polling small groups of sites for ~14.5 hours. These are attempted exploits, not confirmed compromises.

    Technical Details

    Full Core package updates unpack files into predictable paths beneath wp-content/upgrade, temporarily exposing the installer. Exploitation requires locating the staging directory and acting before cleanup — a window measured in seconds in lab testing, favoring sustained automated polling. Unlike earlier WordPress path-traversal RCE issues, this depends on temporary upgrade artifacts rather than theme-template resolution. Other fixes cover stored XSS, information disclosure, authorization weaknesses and denial of service.

    Remediation

    • Verify WordPress 7.1.4 via Dashboard > Updates rather than assuming background auto-updates completed; patched branch releases extend back to 4.7, but only the latest branch is supported.
    • 7.1.4 randomizes staging directories, adds an index guard and blocks unsafe promotion of staged configuration data.
    • Wordfence Premium/Care/Response received the rule on Oct 28 at 20:30 UTC; free users on November 27. Enable Extended Protection, since exploitation requests PHP files directly without loading WordPress.
    • Review logs for unexpected PHP requests under wp-content/upgrade, check for unfamiliar admin accounts and plugins, and scan for unauthorized files.
  5. gbhackers.com ↗ · pub. 29/10/2026 02:35 · coletado 29/10 03:00

    WordPress 7.1.4 patches 22 vulnerabilities, including an RCE race condition in the core update process

    ler a análise desta fonte

    WordPress released version 7.1.4 on October 28, 2026, fixing 22 vulnerabilities across core components, including remote code execution, stored cross-site scripting (XSS), information disclosure and authorization weaknesses. The most serious fix is a race condition during core updates that could lead to RCE, reported by Umut Bayram. The advisory does not state exploitation prerequisites or whether the flaw has been exploited in the wild. No individual CVE identifiers or severity scores were assigned. Administrators are advised to upgrade immediately.

    Technical Details

    • Upgrade-window RCE: a race condition in the core update process, exploitable during the upgrade execution window. It is distinct from the earlier page-template path-traversal flaw.
    • Stored XSS: several flaws are reachable by Contributor-level accounts or higher. They involve crafted whitespace in block delimiters, unsafe JavaScript URLs in Interactivity API bindings, and malicious event-handler bindings.
    • Interactivity API: prototype pollution in context namespaces and bindings can cause stored XSS or denial of service.
    • Author-level flaw: the Interactivity Router mishandles uploaded text files.
    • Other fixes: Customizer selective refresh, format-string injection in the Categories block, labeling issues in the Comments Pagination and Post Navigation Link blocks, and hardened replacement handling in the Image and Playlist blocks. Post content can no longer shadow Script Module data through matching element IDs.
    • Anthropic reports: an editor-level stored XSS tied to personal data erasure requests, and a username escaping issue on multisite Network Users screens.
    • Access control: unauthenticated visitors can no longer discover unpublished Customizer changes. Custom roles with comment-moderation permissions could read, edit or delete notes on posts they cannot edit.
    • Certificates: root certificates were bundled following the eMudhra revocation.

    Remediation

    • Update via Dashboard → Updates → Update Now, and verify that automatic background updates completed.
    • Patched branches: 7.0.8 and 6.9.11 fix all 22 issues; 6.8.12 and 6.7.11 fix the 20 that affect them. Legacy releases are patched down to 4.7.39, but only the latest version is actively supported.
    • Do not defer remediation until WordPress 7.2, scheduled for December 8, 2026.
  6. patchstack.com ↗ · pub. 28/10/2026 15:34 · coletado 28/10 16:01 primeiro registro

    WordPress 7.1.4 patches 22 flaws, including a race-condition unauthenticated RCE in the upgrade process

    ler a análise desta fonte

    WordPress 7.1.4, released on 28 October 2026, fixes 22 vulnerabilities across 17 advisories, compared with seven in 7.1.3 three weeks earlier. Nearly all of them require an authenticated account, usually Contributor. The exception is a race condition in the upgrade process that can lead to unauthenticated remote code execution. Patchstack rated it AC:H and does not consider it practical to exploit. Backports shipped the same day for every supported branch down to 4.7.39. The article does not report exploitation in the wild.

    Technical Details

    • Upgrade race condition (unauthenticated RCE): during installs and updates WordPress extracts the package into wp-content/upgrade/, which the web server serves. Before 7.1.4 the extraction folder name was predictable for admin uploads. The cleanup routine also deleted the protective index.php. For the few seconds an update runs, a full WordPress copy is reachable and browsable. It includes wp-admin/setup-config.php, which can run the installer against an attacker-controlled database. The sink dates back to WordPress 2.8, and the window recurs on every update, including unattended ones. A PHP firewall cannot block it because the extracted copy loads without any mu-plugins.
    • Interactivity API (7 advisories): KSES allows any data-* attribute, and every Interactivity directive is a data-* attribute. A Contributor can store directives that pass filtering and are acted on by the client runtime. This enables javascript: URL bindings, bindings onto on* handlers, __proto__ keys in the context merge, and bindings on object elements. A CSS parser flaw causes a denial of service that hangs the visitor's browser tab, not the server. The client runtime shipped in 6.4 and the PHP class in 6.5, so both versions are listed as affected.
    • Script module data shadowing: getElementById() returns the first element with the ID, so stored content can supply the runtime's state ahead of the real data block.
    • Selective refresh: post content could declare partials whose selector went to jQuery $(), which builds HTML for strings starting with <.
    • Customizer preview: a request without a changeset UUID adopted the latest unpublished changeset with no capability check, exposing the UUID and rendered preview to anonymous visitors.
    • Block fixes: the Categories block expanded format directives after wp_kses_post() through sprintf(). The Image and Playlist blocks used preg_replace() with attacker-influenced replacement text. The Comments Pagination and Post Navigation Link blocks printed labels unescaped.
    • Block delimiter whitespace: PHP and JavaScript disagreed on what counts as whitespace, so a delimiter can be an inert comment to PHP and a real block with attacker-controlled attributes to the editor.
    • REST comments controller: moderate_comments alone allowed reading, editing and deleting notes on posts the user could not edit. This matters mainly with custom roles or plugin-granted capabilities.
    • A change in update-core.php, not mentioned in the release post, adds wp-config.php to the files never copied out of the working directory.

    Remediation

    • Update to WordPress 7.1.4, or to a backport: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, and so on down to 4.7.39. Sites on 4.6 or older receive no fix.
    • Deny web access to wp-content/upgrade/ at the web server level and confirm the directory is not listable.
    • Review who holds Contributor and above, since all but two of the issues start there.