Fix unauthenticated SQL injection on the push REST endpoint (CVE-2026-15162)

[paulsheldrake]

Fixes #571.

The vulnerability (CVE-2026-15162)

The /wp-json/object-sync-for-salesforce/push REST route is exploitable by unauthenticated callers. Its permission callback, Object_Sync_Sf_Rest::can_process(), only checks the HTTP method for the push (and pull) classes — no capability or nonce check:

case 'push':
    if ( ! in_array( $http_method, array( 'POST', 'PUT' ), true ) ) {
        return new WP_Error( 'rest_forbidden', ... );
    }
    break;

The wordpress_object_type body parameter then flows, unsanitized, through:

process() → Object_Sync_Sf_Salesforce_Push::manual_push() → Object_Sync_Sf_WordPress::get_wordpress_object_data() → get_wordpress_table_structure()

where, for post / attachment / custom-post-type objects, it is concatenated directly into the post_type WHERE clause:

'where' => 'AND ' . $this->wpdb->prefix . 'posts.post_type = "' . $object_type . '"',

That where string is later executed without $wpdb->prepare() in object_fields():

$select_meta = ' ... WHERE ' . $meta_table . '.meta_key != "" ' . $where . ' ';
$meta_fields = $this->wpdb->get_results( $select_meta );

Result: an unauthenticated request with a crafted wordpress_object_type and any valid wordpress_id yields blind SQL injection / data exfiltration.

The fix

1. Root cause — bind the object type as a %s parameter via $wpdb->prepare() in all three post-type WHERE clauses in get_wordpress_table_structure(). The user-controlled value can no longer break out of the string literal.
2. Defense in depth — reject any wordpress_object_type that is not a registered WordPress object type (get_object_types()) at the REST boundary in process(), returning 400, so untrusted input never reaches the database layer on this unauthenticated endpoint.

Legitimate callers are unaffected: real object types (user, post, registered CPTs, etc.) pass the allow-list, and $wpdb->prepare() produces the same query for valid post-type names.

Verification

• php -l clean on both changed files.
• Runtime check: $wpdb->prepare( 'AND ' . $wpdb->prefix . 'posts.post_type = %s', 'cpt" OR 1=1 -- -' ) produces AND wp_posts.post_type = 'cpt\" OR 1=1 -- -' — the payload is an inert quoted literal.
• With the REST guard, POST /wp-json/object-sync-for-salesforce/push carrying an injection string as wordpress_object_type returns 400 Invalid WordPress object type instead of executing SQL.

Happy to add a changelog.md / readme entry or adjust the approach (e.g. tightening can_process() instead of / in addition to the allow-list) if you'd prefer.