Notifications
Clear all
Topic starter
02/08/2026 9:46 am
TL;DR: WordPress 7.0.2 and 6.9.5 fix an unauthenticated remote code execution flaw in core that chains from REST API batch-route confusion and SQL injection, with forced auto-updates enabled for affected sites, according to Aikido. The incident shows how anonymous attack paths still defeat assumptions that core web security problems are “solved.”
NHIMG editorial — based on content published by Aikido: unauthenticated RCE in WordPress core via SQL injection
Questions worth separating out
Q: What breaks when unauthenticated SQL injection exists in WordPress core?
A: A single anonymous request can become a full application compromise if the vulnerable path reaches database logic and then chains into code execution.
Q: Why do unauthenticated web flaws matter even when sites are auto-updating?
A: Auto-updates reduce delay, but they do not eliminate the exposure window before the patch lands everywhere.
Q: How can security teams reduce the impact of pre-auth application flaws?
A: Prioritise version verification, edge blocking for known exploit paths, and runtime inspection of anonymous requests.
Practitioner guidance
- Verify patched WordPress versions immediately Confirm that public sites are on 7.0.2, 6.9.5, or the fixed 6.8.6 release where relevant.
- Block the vulnerable batch route at the edge Add temporary WAF rules for /wp-json/batch/v1 and the rest_route=/batch/v1 parameter if patching is delayed.
- Treat unauthenticated REST endpoints as exposure hotspots Review every public endpoint that accepts anonymous input and map where it reaches the database, file system, or execution layer.
What's in the full analysis
Aikido's full post covers the operational detail this post intentionally leaves for the source:
- Exact affected and fixed WordPress branches, including the 6.8 and 7.1 beta edge cases.
- Temporary mitigation options for teams that cannot patch immediately, including WAF and must-use plugin approaches.
- Runtime protection details for blocking the SQL injection pattern while updates roll out across the fleet.
- Aikido Intel coverage of the vulnerability feed and how new WordPress advisories appear in its workflow.
👉 Read Aikido's analysis of the unauthenticated WordPress core RCE →
WordPress core RCE via SQL injection: are your controls keeping up?
Explore further
02/08/2026 12:38 pm
Unauthenticated core flaws are governance failures, not just coding bugs. When a stock installation can be turned into code execution by anonymous input, the issue is no longer limited to secure development. It becomes a control problem across release management, runtime filtering, and emergency patch execution. For web platforms, the blast radius of one request path can exceed the patch cycle that is supposed to contain it.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Who is accountable when a public web platform is exposed to unauthenticated RCE?
A: Accountability is shared across application owners, platform operators, and security teams because the failure spans code, configuration, and patch governance. Frameworks such as NIST CSF and NIST SP 800-53 both expect rapid risk response, change control, and continuous monitoring for internet-facing services.
👉 Read our full editorial: Unauthenticated WordPress RCE shows how SQL injection still breaks core
