WP Query Push WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

0.7.1

Findings

2

Worst severity

high

Content hash

952e81e5303bf1ef9b566c96… Copy

Findings

• high Subscriber-reachable curl SSRF posts query results to attacker-controlled URLs and stores the response in logs

  ssrf

  handle_post_connection (POST /wp-json/wp-query-push/v1/connections, permission_callback nonce_check) inserts name/type/config JSON including requestData.url and requestData.headers with no URL allow-list or protocol check. handle_send and cron wpquerypush_cron_hook call WP_Query_Push::process_task, which json_decodes that config, curl_init($url), sets CURLOPT_POSTFIELDS to json_encode($wpdb->get_results($query)), and curl_exec with attacker-supplied headers. There is no CURLOPT_PROTOCOLS restriction, no block on loopback/link-local/file, and no redirect policy. The HTTP body is stored in {$wpdb->prefix}wpquerypush_logs.response; GET /logs (same nonce-only gate) is SELECT * and returns that body, so cloud-metadata or internal-service responses are readable. Combined with finding 1, a Subscriber can create a connection to https://attacker.example, send SELECT user_login,user_pass FROM wp_users, and receive the dump even if they prefer not to use /query's JSON response; or probe http://169.254.169.254/latest/meta-data/ and read the curl body from /logs. handle_send itself returns empty JSON, so the log table is the response channel.

  includes/class-wp-query-push.php:58-95

  Recommendation

  Gate connection CRUD and /send on manage_options. Allow-list https URLs to public hosts; reject file/gopher/dict, loopback, RFC1918, and link-local (169.254.169.254). Disable redirects or re-validate Location. Do not log full upstream bodies to a table readable via REST. Prefer wp_remote_post() with a deny-list of internal IPs.

• medium No upstream maintenance path for the Subscriber SQL/SSRF holes

  unmaintained

  This tree is GitHub tag v0.7.1, published 2023-10-26; the latest commit on main is the same-day 'mark for auto-update' change. rest-api.php on main still uses nonce-only permission_callback with no current_user_can. PUC pulls https://raw.githubusercontent.com/zdmc23/wp-query-push/main/plugin.json and auto_update_plugin is forced true for slug wp-query-push, but there is no newer release that would actually patch the REST gate. A plugin whose purpose is arbitrary SQL plus outbound curl is unsafe to leave on production unpatched, and there is no in-tree remediation.

  wp-query-push.php:3-17

  Recommendation

  Do not run this plugin on production until REST routes require manage_options and SQL is restricted to SELECT. If you must keep the feature, replace it with a maintained, capability-gated reporting/export plugin or a server-side cron outside WordPress. Disable the forced auto-update filter until a real security release exists.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.