WordPress: critical bugs at the intersection of components

REST Batch API → route and validation-result desynchronization → bypass of REST schema validation and sanitization → string reaches author__not_in → WP_Query inserts it into SQL → SQL injection → RCE (under a suitable configuration) Researchers from Fullhunt presented a scanner for checking whether systems are vulnerable to WP2shell.

get_users([ 'meta_key' => '_temporary_login_token', 'meta_value' => $token, ]); The developers expected an exact token match. However, in WordPress, an empty meta_value disables value filtering, and WP_User_Query checks only the condition meta_key = '_temporary_login_token'. To bypass the check empty($_GET['temp-login-token']), it is sufficient to pass the parameter as an array. It is considered non-empty by empty(), but after sanitize_key() it becomes an empty string. As a result, the query returns any user with a _temporary_login_token set. The plugin treats the first user found as the owner of a valid token and passes that user to the WordPress Authentication API, which creates a fully authenticated session.