WooCommerce APIWA AUTO WP Registry grade B. Medium-severity findings · 2 findingsWP RegistryMedium-severity findings · 2 findingsOpen the reportB

Medium-severity findings.

Audited release

1.1.0

Findings

2

Worst severity

medium

Content hash

4ae888eb2d1210789d16fe27… Copy

Findings

• medium WhatsApp API POST disables TLS verification while sending customer phone and name

  insecure_config

  WOOAWA_Send::send_message runs on woocommerce_order_status_changed (guest checkout, customer, or merchant status edits) and always calls WOOAWA_Api::send_message. That method wp_remote_post()s a JSON payload containing the billing phone, billing first name, order ID, wooawa_business_name, wooawa_brand_logo_url, and wooawa_phone_number to the hardcoded URL https://woo.tochat.be/send-template-message with 'sslverify' => false and no API key/signature. WordPress's default for wp_remote_* is to verify certificates; disabling it means any attacker who can MITM the store's outbound HTTPS (rogue DNS, compromised middlebox, local network on self-hosted shops) can read those fields and forge the JSON body that is logged via WOOAWA_Log::order_log and shown to administrators with wp_kses_post. There is no merchant credential on the request, so TLS is the only integrity control between the shop and the SaaS endpoint. This is not unauthenticated WordPress RCE/XSS; it is an insecure default on a PII-bearing integration that checkout itself triggers.

  includes/class-wooawa-api.php:84-103

  Recommendation

  Remove 'sslverify' => false (or set it true) so wp_remote_post uses WordPress's certificate verification. Authenticate to tochat.be with a per-site API key stored as an option and sent in a header. Fail closed on certificate errors instead of posting customer phone numbers over an unverified TLS session.

• low Admin log bulk-delete does not verify a nonce

  missing_nonce

  WOOAWA_Admin_Log_Table::process_bulk_actions() reads $_REQUEST['wooawa_log_ids'] and $_REQUEST['action'] (via current_action()) and, on action=delete, $wpdb->delete()s those rows from {$wpdb->prefix}wooawa_logs. There is no check_admin_referer(), wp_verify_nonce(), or current_user_can() in the method. WP_List_Table::display_tablenav() does emit a nonce field named bulk-{plural} ('bulk-Logs' in English), but this handler never checks it. The logs form in html-admin-logs.php adds no extra nonce. Reachability is limited: prepare_items() is only called from the wooawa-logs submenu callback, which add_submenu_page registers with manage_options, so subscribers cannot invoke it directly. A CSRF page visited by an already-authenticated administrator can still empty the WhatsApp send/error audit log. IDs are absint'd and the delete uses a %d placeholder, so this is not SQLi.

  includes/admin/tables/class-wooawa-admin-log-table.php:244-260

  Recommendation

  At the start of process_bulk_actions(), if $this->current_action() is set, call check_admin_referer('bulk-' . $this->_args['plural']) (the action WP_List_Table already prints) and current_user_can('manage_options') before deleting. Reject the request on failure.

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.