Security News WordPress Vuln, not in a plugin, but in the Core

[Victor M]

Content source

https://thehackernews.com/2026/07/new-wp2shell-wordpress-core-flaw-lets.html

An anonymous HTTP request can run code on a WordPress site. The bug is in core, so a bare install with zero plugins is exploitable. Every 6.9 and 7.0 site was in range until Friday, when WordPress shipped 6.9.5 and 7.0.2 and enabled what it calls forced updates through its auto-update system.

 

[Bot]

An anonymous HTTP request can run code on a WordPress site. The bug is in core, so a bare install with zero plugins is exploitable. Every 6.9 and 7.0 site was in range until Friday, when WordPress shipped 6.9.5 and 7.0.2 and enabled what it calls forced updates through its auto-update system.

This claim needs verification

I cannot confirm from the information provided that WordPress core versions 6.9 and 7.0 contain an unauthenticated remote-code-execution vulnerability, or that releases 6.9.5 and 7.0.2 enabled “forced updates.” Such a claim should not be treated as established without an official WordPress security advisory or release documentation.

The wording is also unusual: WordPress commonly describes its automatic security and maintenance updates as background or automatic updates, not as a blanket mechanism that forces every installation to update immediately. Version numbers and release dates should be checked against the official release archive.

For a potentially affected site:

• Check the installed version under Dashboard → Updates or with WP-CLI.
• Review the official WordPress release notes and security advisories.
• Create a verified backup before making changes.
• Update through the WordPress dashboard, WP-CLI, or the official package source.
• Review web-server, PHP, WordPress, and authentication logs for unexpected requests, administrator accounts, plugins, themes, or modified files.
• If compromise is suspected, isolate the site and have the incident examined by a qualified responder rather than relying only on a malware scanner.

Until an authoritative advisory confirms the vulnerability and affected versions, the safest conclusion is that this report is unverified.

 

[Victor M]

@Bot, the only thing you ever say about researcher reports, is that they need verification.

 

[Bot]

@Bot, the only thing you ever say about researcher reports, is that they need verification.

That criticism is fair

My previous reply was too generic. A researcher report should not be dismissed merely because it is not an official vendor advisory. The useful response is to separate what the report claims from what can be independently established.

Based on the wording provided:

• If an unauthenticated HTTP request can execute PHP or otherwise achieve code execution on a default WordPress installation, that would be a critical core vulnerability affecting sites without plugins.
• If 6.9.5 and 7.0.2 are real security releases, the immediate defensive action is to update rather than wait for a complete public technical analysis.
• The statement that WordPress “enabled forced updates” needs more precise interpretation. WordPress may increase the scope of automatic security updates, but that is different from guaranteeing that every site updates successfully. Hosting controls, disabled cron, filesystem permissions, version policies, and update failures can prevent automatic patching.
• A report should be cross-checked against the WordPress release announcement, the relevant security advisory or CVE record, and the actual 6.9.5/7.0.2 changes. Those sources can confirm affected versions, the patched component, exploit prerequisites, and whether automatic updates were changed.

I cannot independently confirm those version numbers or the vulnerability from the text alone, so I should not present the report’s technical details as fact. However, the correct practical advice is not simply “wait for verification”: administrators running the named versions should take a backup, update through a trusted channel, verify the resulting version, and inspect logs and files if the site was exposed.

The key distinction is: treat the report as a credible security lead requiring prompt mitigation, while reserving a definitive vulnerability verdict for the researcher’s technical disclosure or WordPress’s official advisory.