WordPress 7.1.4 fixes multiple vulnerabilities in the site engine

Exploitation is now confirmed during the upgrade window

CISA bases its 3 November addition on evidence of active exploitation. Its record describes a time-of-check/time-of-use race involving predictable, web-accessible staging paths during full-package core upgrades. NVD lists versions 4.7 through 7.1.3 and says no account is required. This does not mean any visit compromises a site outside that upgrade window.

The Canadian advisory gives 7.1.4 as the correction reference. Have the hosting-specific update path checked, along with relevant evidence if intrusion is possible. The Debian tracker now also references CVE-2026-119977 and identifies its fixed trixie package, detailed below. The KEV entry does not establish that every affected site was attacked.

The fix is for WordPress itself, not just its plugins

Advisory CERTFR-2026-AVI-1420 covers WordPress versions before 7.1.4 and points to the WordPress bulletin dated 28 October. It lists multiple risks, including remote code execution, denial of service, loss of confidentiality and cross-site scripting (XSS).

The CERT-FR summary does not give detailed conditions for every flaw. The exploitation confirmation above comes from CISA for CVE-2026-119977; it does not automatically extend to every vulnerability in that notice. Updating a theme or plugin does not establish that WordPress core itself was updated.

Check who is responsible for the update

If you manage the site, record its installed version and apply the security update through the route supported by that hosting setup. Before changing it, keep a recoverable backup of the files and database. A copy on the same site is not an independent recovery path.

If someone manages it for you, ask them to confirm the engine version and the outcome. Afterwards, check public pages, administrator login and important forms. These are practical recommendations, not tests SecuFocus performed on your installation.

• Self-hosting: plan maintenance and recovery↗
• PHP: check the server runtime too↗

A fixed version is not a clean bill of health

The initial version of this article uses the CERT-FR notice; the separate Debian section adds its source-package record and the cited NVD entry. We do not assign a CVE to an issue unless one of those documents identifies it. None of these readings is an inspection of your site or proof that its accounts, extensions and server have no other defects.

Unknown accounts, changed files or unexpected redirects need separate attention if you already observe them. Applying a patch and establishing what happened before it are different tasks.

Debian 13: a different package number

The Debian tracker for DSA-6596-1 now references CVE-2026-119977 alongside CVE-2026-66666. Its CVE-2026-119977 record marks wordpress 6.8.12+dfsg1-0+deb13u1 as fixed in trixie’s security repository. It still marks bookworm’s 6.1.9+dfsg1-0+deb12u1 as vulnerable. The original 29 October advisory names only CVE-2026-66666: the addition comes from the current tracker, not a rewrite of that message.

CVE-2026-66666 remains a separate sensitive-data disclosure issue; its NVD record describes upstream 6.8 through 6.8.10 among the affected branches. For WordPress installed through Debian packages, check the distribution and full package version. Do not reject a patched 6.8 package simply because its number is lower than 7.1.4, or assume this tracker proves every component of the site is current. This is not an inspection of your installation.

• GLPI: check which service branch needs its fix↗