Critical WordPress wp2shell Vulnerability: Immediate Patching Required
CVE-2026-63030 is being reported by SecNews.gr as a critical WordPress vulnerability listed in CISA’s Known Exploited Vulnerabilities catalog and under active exploitation.
Cyber Daily separately reports that the issue, referred to as “wp2shell,” is a pre-authentication remote code execution flaw in WordPress core. For WordPress operators, this is an incident-response task, not a routine maintenance window: a remote, anonymous path to code execution changes the risk profile of every reachable installation.
Affected branches and patch target
According to Cyber Daily’s report, the exposed version ranges are WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. WordPress 6.8.5 and earlier are described as unaffected.
The stated remediation target is therefore branch-specific:
1. Update 6.9.x installations to 6.9.5.
2. Update 7.0.x installations to 7.0.2.
3. Treat sites on the reported affected builds as exposed until the installed core version is verified, not merely until a host or management platform reports that an update was scheduled.
Cyber Daily reports that the issue has no preconditions: an anonymous user can allegedly exploit it against a stock WordPress installation without plugins. That removes several common assumptions from the triage process. A minimal plugin inventory, no public registration flow, or a tightly controlled administrator account list does not establish safety if the affected core build remains online.
Temporary request controls
Where a core update cannot be completed immediately, the reported mitigation is to block anonymous access to the REST API entirely, or to block these request targets at the WAF layer:
/wp-json/batch/v1
?rest_route=/batch/v1This is a containment measure, not a substitute for the fixed release. Blocking the named routes can reduce exposure while the maintenance path is being completed, but it may also affect functionality that depends on REST API batch requests. Apply the rule deliberately, document the change, and remove or revise it only after the core version has been confirmed.
The useful operational distinction is simple: patching changes the vulnerable code path; a WAF rule constrains inbound traffic to a reported route. Both may be appropriate during an active-exploitation window. Only the former addresses the affected version state.
Post-patch verification is still required
Cyber Daily reports that proof-of-concept exploits were already circulating and that there were initial signs of exploitation. The source also advises defenders not to stop at patching, but to determine whether an attacker arrived before remediation and to detect or remove any backdoors that may have been deployed.
For site owners and managed WordPress teams, the immediate verification sequence is:
1. Record the installed WordPress version for every public instance.
2. Patch affected 6.9.x and 7.0.x branches to the reported fixed releases.
3. Confirm that temporary controls for the two reported REST API paths are active where patching is delayed.
4. Review the environment for evidence that remediation occurred after unauthorized access, rather than assuming an updated version proves a clean state.
5. Keep the incident open until the update state and any follow-up investigation have been recorded.
The baseline is not subjective: affected core versions must be absent, and any temporary WAF control must match the two reported request paths. The remaining question is whether patching happened before exploitation.