EN PT-BR
← Voltar ao feed
critical government

WordPress 7.1.4 fixes 22 flaws; Core upgrade race-condition RCE CVE-2026-119977 (CVSS 8.1) added to CISA KEV as exploited

5 fonte(s) · 7 atualização(ões) · publicado 28/10/2026 15:34 · coletado há 6 horas

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

Fontes: cisa.gov ↗ 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). It is tracked as CVE-2026-119977, named by gbhackers.com on 31 October. On 3 November 2026 CISA added it to its Known Exploited Vulnerabilities (KEV) Catalog as a Time-of-check Time-of-use (TOCTOU) race condition in WordPress Core, confirming active exploitation in the wild (cisa.gov). Since 30 October, Defiant (Wordfence) telemetry had shown 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. Earlier reports described these as attempted exploits with no successful compromises 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

CVE-2026-119977 (CVSS 8.1, AC:H) is a race condition (TOCTOU) in the WordPress Core upgrade process that can lead to unauthenticated remote code execution. It affects WordPress 4.7 through 7.1.3. An attacker needs no account and no user interaction, but must reach the staged installer while a full-package update runs. This requires public web and PHP execution access to wp-content/upgrade, a predictable or discoverable staging path, and enough time before cleanup. Fixed in 7.1.4, with backports 7.0.8, 6.9.11, 6.8.12, 6.7.11 and down to 4.7.39. CISA added it to KEV on 3 November 2026 as exploited in the wild.

Como funciona

When WordPress installs or updates with a full package, it extracts the new files 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 that runs first also deleted the index.php that prevents directory listing. For the few seconds the update runs, a complete WordPress copy is reachable, including wp-admin/setup-config.php, which starts without the site's configuration. A visitor who requests it in that window can interact with the temporary installation, and this can progress to PHP code execution. Once the update finishes, cleanup removes the files and the window closes.

Por que é vulnerável

The root cause is a time-of-check/time-of-use race: the update stages a full, executable WordPress copy in a web-served directory with a predictable name and weak protection, and the protective index.php was removed by cleanup. The exposure recurs on every update, including unattended ones, and the sink dates back to WordPress 2.8, per Patchstack. A PHP firewall cannot stop it because the extracted copy loads without any mu-plugins. 7.1.4 appends 16 random characters to the folder name, recreates index.php and no longer deletes it, and blocks unsafe promotion of staged configuration data. Patchstack also notes a change in update-core.php that stops wp-config.php being copied out of the working directory.

Onde está

The staging directory wp-content/upgrade/, the staged wp-admin/setup-config.php installer, and the cleanup logic in update-core.php (which now keeps wp-config.php from being copied out); no commit is named.

Como foi descoberta

Per gbhackers.com, citing a Wordfence advisory, the researcher Umut Bayram reported the flaw. WordPress fixed it on 28 October 2026 in 7.1.4, and the initial coverage said nothing about exploitation. Wordfence (Defiant) then reported attackers probing within hours: the first firewall rule match came nine minutes after deployment, and over 18,500 requests hit staged setup-config.php paths in 21 hours. Early articles said no CVE had been assigned. gbhackers.com named CVE-2026-119977 on 31 October, and CISA's KEV entry on 3 November confirmed it. Patchstack scored it AC:H and called it impractical to exploit; no successful compromise had been reported by Wordfence.

PoC existente, privada

O exploit existe, mas quem o tem não o publicou.

No article mentions a published proof of concept or exploit code. What exists is exploitation activity seen in the wild: Wordfence blocked tens of thousands of attempts (62,969 and 58,693 are both cited for 24 hours, and not reconciled). Two large sources polled small groups of sites for about 14.5 hours to catch the update window, and other sources tried many staging-directory and version-name variations. CISA confirmed exploitation in the wild. The window is short, but sustained polling makes patching urgent, especially on sites with automatic updates.

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

Detalhes técnicos

  • Upgrade race condition (unauthenticated RCE, TOCTOU): 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). CISA classifies the flaw as a TOCTOU race condition in WordPress Core that could grant attackers total control post-exploitation (cisa.gov). 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).
  • CISA urges applying available patches immediately and prioritizing publicly exposed assets. Under Binding Operational Directive (BOD) 26-04, Federal Civilian Executive Branch (FCEB) agencies must prioritize remediation on internet-facing assets and verify whether systems were compromised before patching. BOD 26-04 legally applies only to FCEB agencies, but CISA recommends that all organizations adopt risk-based vulnerability management and remediate promptly (cisa.gov).
  • 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). Check for signs of prior compromise before patching (cisa.gov).
  • 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 reported active exploitation attempts based on Wordfence telemetry, and cisa.gov (3 November) now confirms active exploitation in the wild by adding the flaw to KEV. securityweek.com and gbhackers.com stated that no successful compromise had been reported; cisa.gov does not give details of successful compromises but tells organizations to check for compromise before patching. cisa.gov is the most recent and authoritative source.
  • Severity and CVE: the earlier gbhackers.com text said no individual CVE identifiers or severity scores were assigned, and securityweek.com and thehackernews.com confirmed CVSS 8.1 but said no CVE was assigned. gbhackers.com (31 October) named CVE-2026-119977 (CVSS 8.1), and cisa.gov (3 November) now corroborates that identifier in its KEV entry, so the earlier "no CVE" statements are outdated. 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. cisa.gov's KEV listing confirming exploitation in the wild is the more recent and authoritative evidence of real-world exploitation; all sources 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. cisa.gov ↗ · pub. 03/11/2026 09:00 · coletado 03/11 19:00

    CISA Adds Actively Exploited WordPress Core TOCTOU Race Condition Flaw to KEV Catalog

    ler a análise desta fonte

    CISA has added CVE-2026-119977, a Time-of-check Time-of-use (TOCTOU) race condition vulnerability in WordPress Core, to its Known Exploited Vulnerabilities (KEV) Catalog after confirming active exploitation in the wild. Under Binding Operational Directive (BOD) 26-04, Federal Civilian Executive Branch (FCEB) agencies must prioritize remediation of this vulnerability on internet-facing assets that could grant attackers total control post-exploitation, and verify whether systems were compromised prior to patching. While BOD 26-04 legally applies only to FCEB agencies, CISA urges all organizations to adopt risk-based vulnerability management and remediate this flaw promptly given its confirmed exploitation.

    Remediation

    Organizations running affected WordPress Core installations should apply available patches immediately, prioritize this vulnerability on publicly exposed assets, and check for signs of prior compromise before patching, consistent with BOD 26-04 requirements.

  2. 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.
  3. 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.
  4. 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.

  5. 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.
  6. 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.
  7. 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.