Post #3921218
2026-07-18 22:15 UTC
Replies (2)
-
@Slater450413@infosec.exchange 2026-07-19 13:12
@wdormann@infosec.exchange Just had a quick squiz at some servers I run with WordPress on based on the URLs mentioned in the article egrep -ir "rest_route=/batch/v1|wp/v2/categories|wp/v2/users" /var/log/apache2/* 21 requests starting 18/07/2026 05:30 UTC None of the requests have anything in common. Seems mostly like people poking around rather than spraying at this stage. #WordPress #CVE-2026-63030 #CVE-2026-60137 #wp2shell
-
@wdormann@infosec.exchange 2026-07-20 16:53
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? No. The 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. CVE-2026-60137 is this SQL injection stuff, which TBH would make WebGoat blush at. (Nobody would do this ITW) CVE-2026-63030 is the REST endpoint route confusion which allows an unauthenticated attacker to reach the vulnerable (to SQL injection) endpoint. At 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. On 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.