WordPress flaw actively exploited: what operators must check
The US cyber agency CISA has added CVE-2026-87902 to its catalogue of actively exploited vulnerabilities. For WordPress operators, what counts now is not only the update but also a check for traces of an earlier attack.
Am I affected? In the WordPress dashboard, check the core version actually installed under “Updates”. Unpatched version branches from 4.7 to 7.1 are affected. Anyone running 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9 or the corresponding security release for their older branch has the published fix. Automatic updates alone are no proof – what matters is the version displayed.
The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-87902 to its catalogue of known exploited vulnerabilities on 25 September. This confirms that the flaw is not merely described in theory but is being used in real attacks. The WordPress core is affected – and with it potentially a very large number of websites, including those of Swiss companies, associations and public authorities.
The warning does not, however, mean that every WordPress site has already been compromised or can be taken over under all configurations. What matters is the installed version, the active theme and the server environment. It is precisely this differentiation that makes fast but orderly action necessary.
What CISA actually confirms
CISA lists the vulnerability under the name “WordPress Core Remote File Inclusion Vulnerability”. Inclusion in the Known Exploited Vulnerabilities Catalog, KEV for short, requires reliable evidence of active exploitation. The entry does not name details of individual victims or the scale of the attacks.
For the civilian federal agencies covered by the US directive, remediation is scheduled by 28 September 2026. Swiss companies are not subject to this deadline. The unusually short requirement does, however, show how high CISA rates the operational priority.
The most important distinction lies between vulnerability and incident: CISA confirms the active exploitation of the flaw, not a break-in at a specific Swiss website.
How a path problem can turn into an attack
Under certain conditions, an unauthenticated attacker can cause the resolution of page templates to include a readable local PHP file outside the active theme directories. If further conditions are met, this can lead to code execution on the server.
The official advisory names two key preconditions: the active parent or child theme has a top-level directory whose name begins with page-, and a suitable PHP file that the web server can read exists on the server. Certain structures of older default themes as well as the Neve, Hestia and Sydney themes can be affected. However, using one of the named themes alone proves neither an immediately exploitable installation nor that an attack has taken place.
A patched version rather than automatic updating merely switched on
WordPress 7.1.2 closes the vulnerability. Security updates have also been released for older branches: 7.0.6, 6.9.9, 6.8.10 and 6.7.9 are among the current fix versions; further backports reach as far as WordPress 4.7.37. WordPress also points out that only the latest major version is actively supported.
Operators should therefore not merely check whether automatic background updates are enabled. The dashboard must actually show a patched version. The update should be carried out via the regular WordPress administration, the hosting provider or an official WordPress source. A reliable backup of the database and files is part of the standard beforehand.
An update closes the door but does not erase traces
If the flaw has already been exploited, updating afterwards does not automatically undo a change. Administrators should additionally check whether new user accounts have been created, administrator rights changed, unknown files uploaded or plugins and themes unexpectedly modified. Web server logs, scheduled tasks and outgoing connections can also provide clues.
Simply deleting a conspicuous file is usually not enough in a confirmed compromise. Attackers can leave several access routes behind. Restoring from a demonstrably clean backup and closing the original point of entry are then more reliable. If there is suspicion, the website should be isolated and expert help called in before logs or other evidence are overwritten.
A core flaw, not a single plugin
For prioritisation, it is crucial that the entry names the WordPress core. The problem therefore cannot be fixed by deactivating a plugin alone. Plugins and themes nevertheless remain part of the check: they can influence the attack preconditions, contain additional vulnerabilities or have been modified after a break-in.
A rarely visited website is not an unattractive target either. Automated scanners search the web continuously for vulnerable versions. Those responsible should therefore clarify who monitors updates and who decides in case of suspicion – even if the technical operation has been outsourced to an agency or a host.
Five steps for operators
- Check the installed WordPress version in the dashboard.
- Apply the patched security version of the branch in use.
- Check administrators, plugins, themes and the most recently modified files.
- Renew credentials if there is suspicion or unknown accounts appear.
- If there are traces of a break-in, isolate the website and call in experts.
WordPress is used for online shops, member portals and company websites. A compromised site can endanger data, redirect visitors or serve as a starting point for further attacks. Anyone who now checks the specific version, updates and then looks for traces is therefore addressing both risks: the attack that is still possible and the one that has already happened unnoticed.
