Medium-severity findings.

Audited release

1.3.2

Findings

2

Worst severity

medium

Content hash

2178db9b839c9fdb865a0172… Copy

Findings

• medium Unauthenticated init return updates orders without an order key or status guard

  missing_auth

  woocommerce_process_thawani_payment is hooked to init with no capability, nonce, or WooCommerce order_key check. Any front-end request that includes GET mode, oid, and status (status is required to be present then ignored) loads session_id from that order's post meta, authenticates to Thawani with the merchant secret, and mutates the order: payment_status=paid calls $order->payment_complete() and WC()->cart->empty_cart(); payment_status=unpaid calls add_order_note('The Thawani transaction has been declined.'). Order IDs are sequential. The handler does not verify the order is still pending/on-hold, that the payment method is thawani, or that client_reference_id/amount in the Thawani payload match the WooCommerce order. It cannot mark an unpaid Thawani session as paid (the API is consulted), but an unauthenticated caller or CSRF GET can still append decline notes on other customers' unpaid Thawani orders, replay payment_complete on a cancelled-but-paid order (WooCommerce core includes cancelled in woocommerce_valid_order_statuses_for_payment_complete), and wipe the current visitor's cart. process_payment mints the return URL as get_permalink(success_url)?mode=&oid=&status= with no secret.

  thawani-pay-woocommerce.php:387-467

  Recommendation

  Handle returns on a dedicated wc-api/webhook endpoint, not generic init. Require the WooCommerce order_key (or a signed token minted at process_payment) and refuse unless the order is pending/on-hold and payment_method is thawani. Compare Thawani client_reference_id and amount to the order. Do not add_order_note or empty_cart on unauthenticated GET. Prefer a server-to-server Thawani webhook over a guessable browser return.

• medium Unauthenticated payment callback emails the merchant and hangs on Thawani with no timeout

  dos

  The same init handler, when secret_key is empty, curl fails, or Thawani returns a non-2000 body, calls wc_mail() to admin_email or the developer_log setting with subject '[ERROR] Thawani Pay - Order #' plus attacker-controlled oid and a body that concatenates the raw API response. There is no capability, nonce, rate limit, or check that oid is a real thawani order before sending. CURLOPT_TIMEOUT is 0 and CURLOPT_FOLLOWLOCATION is true, so each unauthenticated hit also performs a merchant-authenticated GET to checkout.thawani.om/api/v1/checkout/session/{session_id} that can block a PHP worker indefinitely if the remote side stalls. Observable: curl 'https://site/?mode=1&oid=1&status=x' in a loop fills the merchant inbox and burns Thawani API quota/PHP workers. $order is not validated before the curl/mail path.

  thawani-pay-woocommerce.php:410-475

  Recommendation

  Do not send mail from an unauthenticated GET. Log to WooCommerce logs instead, rate-limit, and require a valid thawani order plus order_key before calling Thawani. Set a finite CURLOPT_TIMEOUT (and CURLOPT_SSL_VERIFYPEER true), disable FOLLOWLOCATION, and skip the API call when session_id or wc_get_order() is empty.

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.