Medium-severity findings.

Audited release

2.0.0

Findings

3

Worst severity

medium

Content hash

0f9db4b7eab3990d02365d14… Copy

Findings

• medium Unauthenticated AJAX search discloses non-public products and scans all product postmeta

  information_disclosure

  custom_product_search_ajax is registered on both wp_ajax_ and wp_ajax_nopriv_. After check_ajax_referer (nonce is localized to every frontend page as customSearch.nonce), it builds a LIKE term from $_POST['query'] with no minimum length, no $wpdb->esc_like, and no LIMIT. The SQL selects from wp_posts LEFT JOIN wp_postmeta with only post_type = 'product' — no post_status, no post_password check, and no meta_key. $meta_key = '_chemical_formula' is assigned and never used, so any product whose title or any meta_value contains the term matches, including draft, private, trash, auto-draft, and password-protected products. get_post() then loads the row; description falls back to full post_content (WooCommerce short description is post_excerpt, not _short_description). wp_send_json_success returns ID, title, permalink, _price, that description, and thumbnail. An empty query becomes '%%' and dumps the catalog. Observable: unauthenticated POST to admin-ajax.php with action=custom_product_search, a visitor nonce, and query=% (or omitted) returns unpublished product bodies and prices; LIKE wildcards also boolean-test secrets in product meta such as _downloadable_files.

  custom-search.php:199-292

  Recommendation

  Restrict the query to post_status = 'publish' (and skip post_password != ''), JOIN only the intended meta_key, wrap the user term in $wpdb->esc_like, add a LIMIT, and omit post_content of posts the current user cannot read. Keep the public nonce if the search is meant to be public, but do not treat the nonce as an authorization gate for private catalog data.

• medium Stored XSS in search results via jQuery.append of product title, link, and thumbnail

  xss_stored

  The [custom_product_search] shortcode builds result HTML with template-literal interpolation of product.link, product.thumbnail, and product.title, then inserts it with jQuery.append (HTML parse; event-handler attributes execute). Those values come from get_permalink, get_the_post_thumbnail_url, and post_title with no encoding for HTML context. WordPress does not kses post_title. A Shop Manager (edit_products, no manage_options) can set a product title or custom featured-image URL such as "><img src=x onerror=...> or a javascript: permalink filter result and have that script run for every visitor who searches and hits the product. Customer/Subscriber cannot write those fields on a default WooCommerce install. Consumer is the frontend search grid, not wp-admin.

  custom-search.php:155-163

  Recommendation

  Do not concatenate JSON fields into HTML strings. Create elements with jQuery/DOM APIs and set .text() / textContent for title and .attr('href', ...) only after verifying an http(s) URL. Encode on the server if you must emit HTML (esc_html / esc_url).

• medium GitHub plugin updater disables TLS verification and installs attacker-supplied zipball_url

  insecure_config

  check_for_plugin_update hooks pre_set_site_transient_update_plugins and calls wp_remote_get on the GitHub releases API with sslverify => false. The decoded JSON is trusted: tag_name is version-compared and release_info['zipball_url'] is copied into $transient->response[].package with no host allowlist. A network attacker who MITMs api.github.com can advertise a fake newer tag and a package URL on an attacker server. WordPress then downloads and installs that zip when an administrator clicks Update (or if plugin auto-updates are enabled). That is arbitrary PHP under wp-content/plugins. Exploitation needs a privileged network position plus an update install; it is not a Subscriber web probe. Related: fix_plugin_folder_name on upgrader_post_install moves $result['destination'] to WP_PLUGIN_DIR/Custom-product-search whenever the basename differs, without checking hook_extra for this plugin — scope that rename to this slug if the updater is kept.

  custom-search.php:305-334

  Recommendation

  Drop sslverify => false (WordPress defaults to verifying certificates). Allowlist package URLs to https://api.github.com/repos/hassan7303/Custom-product-search/ or https://github.com/hassan7303/Custom-product-search/. Restrict fix_plugin_folder_name so it only renames this plugin's install destination.

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.