{"uuid": "6ae4a811-0ff2-4bbd-ad77-df9ebf75c49d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-63030", "type": "seen", "source": "https://infosec.exchange/users/wdormann/statuses/116953344790464812", "content": "WordPress is used on plenty of websites these days. And unlike vulnerabilities in WordPress plugins, which seem to happen every hour of every day, a vulnerability in WordPress core is kind of a big deal.  This exploit must be doing something very clever, right?\nNo.\nThe endpoint reachable via /?rest_route=/batch/v1 simply takes an author_exclude argument and splats it into a SQL statement.  No need for fancy ' OR 1=1 -- stuff.  Just provide SQL to execute, and WordPress executes it.\nCVE-2026-60137 is this SQL injection stuff, which TBH would make WebGoat blush at. (Nobody would do this ITW)\nCVE-2026-63030 is the REST endpoint route confusion which allows an unauthenticated attacker to reach the vulnerable (to SQL injection) endpoint.\nAt the the point that you have anonymous SQL injection, there are a few steps to get RCE as the user that WordPress runs as.  Throw in any of the bazillion Linux LPEs out there and you can have an attack chain that compromises the entire system.\nOn the upside, the default install of WordPress has an auto-update mechanism enabled by default. And the check happens if it's been more than 12 hours since the last update check. And in the case of my vulnerable VM snapshot from the weekend, it will be updated automatically immediately on boot if it has internet connectivity.", "creation_timestamp": "2026-07-20T16:53:40.037128Z"}