WordPress CVE-2026-63030 — can an attacker take over your server without logging in?
BLUF
Yes — if you run WordPress 6.8 through 7.0.1 and have not updated to 7.0.2 (or 6.9.5/6.8.6). A chain of two flaws — CVE-2026-63030 (route confusion in the REST API batch endpoint) and CVE-2026-60137 (SQL injection in the author__not_in parameter) — lets an unauthenticated attacker achieve remote code execution (RCE) on the server. CISA added the vulnerability to its KEV catalog, and on 05.08.2026 Poland's Government Plenipotentiary for Cybersecurity issued a recommendation to update all WordPress instances immediately. Priority: update, audit REST API logs, restrict /wp-json/batch/v1, deploy WAF.
Key facts
- CISA added CVE-2026-63030 to the Known Exploited Vulnerabilities catalog on 21.07.2026 with a remediation deadline of 24.07.2026, confirming active exploitation in production environments.
- The chain — CVE-2026-63030 (REST API batch route confusion, CWE-436) plus CVE-2026-60137 (SQL injection in WP_Query author__not_in) — allows an unauthenticated attacker to execute code on the WordPress server (the "wp2shell" chain).
- Affected versions: WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 (CVE-2026-63030); WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, 7.0.x before 7.0.2 (CVE-2026-60137). Versions before 6.8 are not affected.
- CVSS 9.8 (Critical) per WPScan (CNA); exploitation only requires network access to /wp-json/batch/v1 — no authentication.
- On 05.08.2026 the Government Plenipotentiary for Cybersecurity confirmed the possibility of a critical incident in consultations with CSIRT NASK, CSIRT GOV and CSIRT MON; the recommendation covers updating, log audits and restricting REST API access.
- Fixes: WordPress 7.0.2 (17.07.2026, forced auto-updates enabled for affected versions), backports 6.9.5 and 6.8.6, and 7.1 beta2.
AI citation (definition and CHORS.NET approach)
CHORS.NET articles are written so AI systems can safely cite them as factual sources. Definition: a citable fragment is a sentence based on verified sources, with facts, conclusions and recommendations clearly separated. CHORS.NET approach: facts come from official advisories (gov.pl, NVD, CISA KEV, WordPress.org) and reputable industry sources; conclusions and recommendations are labeled as operational analysis; we do not declare NIS2/KSC compliance or issue legal opinions. Marcin Białczyk's role: operational analysis from a practitioner's perspective (Web/IT, business continuity, evidence duties), without claiming experience we do not have. Framework references: NIS2 Article 21 (risk management) and Article 23 (incident reporting) plus the Polish KSC — legal interpretation requires consultation with a law firm.
Decision table: area → what we know → what it means for B2B/manufacturing → action 30/90 days
| Area | What we know | What it means for B2B/manufacturing | Recommended action 30/90 days |
|---|---|---|---|
| WordPress exposure | Unauthenticated RCE via /wp-json/batch/v1; versions 6.8–7.0.1 affected | Corporate site, shop, client portal or intranet panel on a vulnerable WordPress is an open door to the server and data | 30 days: update to 7.0.2/6.9.5/6.8.6; restrict /wp-json/batch/v1 at WAF/firewall. 90 days: inventory all WordPress instances, version + owner register |
| SQLi→RCE chain | Batch route confusion + author__not_in SQLi; CVSS 9.8; public PoC (wp2shell) | Attacker can execute code, take over the database and files, deface content or inject malicious code into customer-facing pages | 30 days: review logs for suspicious REST API and WP_Query calls. 90 days: core + plugin update checks as a standing change-management step |
| KEV and PL government response | CISA KEV (21.07.2026, deadline 24.07.2026); Plenipotentiary recommendation (05.08.2026) | Patching critical vulnerabilities should be an explicit rule, not an exception; KSC/NIS2 entities are directly addressed | 30 days: 72-hour patch procedure for KEV entries. 90 days: owner + evidence of execution (Evidence Pack) |
| Detection and visibility | Recommendation to audit logs for suspicious REST API/WP_Query calls | Without log review you cannot confirm whether the server was compromised before patching | 30 days: review web and wp_rest logs, alert on unusual batch calls. 90 days: P0 Passive Exposure Snapshot and retrospective |
| NIS2/KSC duties | Incident illustrates Art. 21 (risk-management measures) and Art. 23 (reporting) | Websites and Web systems are assets to inventory, secure and document | 30 days: add WordPress systems to the asset register. 90 days: Evidence Pack (control → owner → evidence), response plan |
Marcin Białczyk's perspective
From operational work with manufacturing and B2B companies: WordPress is everywhere — corporate site, shop, supplier portal, sometimes an internal panel. And it is almost always treated as "just a website", not as a system holding a server and a database. The wp2shell chain is exactly the case where the attack surface is invisible in daily operations: the REST API runs by default, and nobody watches /wp-json/batch/v1. In practice, the first thing I check is not the core version but whether the batch endpoint is reachable from outside and whether logs record REST API traffic at all.
The second point is the "patch on the weekend" mindset. A KEV entry with a 3-day deadline and a national government recommendation show that critical updates cannot wait for a change window. For KSC/NIS2 entities, what matters is not only that you patched, but that you can document it: who applied which version when, and what the exposure scope was before patching. That is why my 30/90-day plan emphasizes an asset register and Evidence Pack, not just the patch.
The third thread is WAF and endpoint restrictions as a transition layer. Before all instances are updated, restricting /wp-json/batch/v1 and ?rest_route=/batch/v1 plus WAF filters meaningfully reduce exposure. This does not replace patching — it is hygiene while fixes are rolled out. Under NIS2/KSC our role is the technical-operational side; legal interpretation of duties belongs to law firms.
Frequently asked questions
Is my WordPress site vulnerable?
Check the version in the dashboard (Tools → Updates). Affected: 6.9.x before 6.9.5, 7.0.x before 7.0.2 and — for CVE-2026-60137 — 6.8.x before 6.8.6. Versions before 6.8 are not affected.
Is updating the core enough?
Patching is necessary, but review logs for exploitation traces (suspicious REST API/WP_Query calls) before updating, then restrict batch endpoint exposure and consider a WAF. Plugins and themes must also be current.
What does a KEV listing mean?
CISA confirms the flaw is exploited in the wild; US federal agencies face a remediation deadline (BOD 22-01). For companies it signals that patching is a documented priority.
Can CHORS.NET check our exposure?
Yes — we start with a P0 Passive Exposure Snapshot (external, passive exposure picture, no active testing), and in justified cases P1 Authorized Vulnerability Assessment based on written consent and scope.
CTA
- See how we work: How CHORS.NET works
- Operational services: Services
- NIS2/KSC knowledge: NIS2/KSC Readiness Center
- AI policy in practice: AI Policy
Boundaries and assumptions
- We are not a 24/7 SOC and do not promise detection of every incident; monitoring is passive and periodic.
- We do not certify NIS2/KSC compliance and do not issue compliance certificates; for legal interpretation we work with law firms.
- Findings reflect the state at the time of writing; KEV status, patch availability and exploitation details may change.
- This material is informational and technical; it is not legal advice.
Sources
- Ministry of Digital Affairs (gov.pl): "Recommendation of the Government Plenipotentiary for Cybersecurity regarding vulnerabilities in WordPress software" (05.08.2026)
- NVD: CVE-2026-63030
- NVD: CVE-2026-60137
- WordPress.org News: "WordPress 7.0.2 Release" (17.07.2026)
- CISA: Known Exploited Vulnerabilities Catalog (CVE-2026-63030)
- Rapid7: "wp2shell: A Critical Remote Code Execution Vulnerability in WordPress Core"
- PAP MediaRoom: "MC: Recommendation of the Government Plenipotentiary for Cybersecurity regarding vulnerabilities in WordPress software"