Critical findings.

Audited release

1.2.5

Findings

2

Worst severity

critical

Content hash

6ef585c4a4421cb510b73b5c… Copy

Findings

• critical Unauthenticated FastSpring webhook HMAC fail-open marks arbitrary orders paid

  auth_bypass

  WC_Gateway_FastSpring_Handler::listen_webhook_request is hooked to woocommerce_api_wc_gateway_fastspring and is reachable by anyone at /?wc-api=wc_gateway_fastspring. Authentication is solely is_valid_webhook_request(). That function computes HMAC-SHA256 of php://input against webhook_secret, then reads $_SERVER['HTTP_X_FS_SIGNATURE']. If the header is missing or empty, it logs 'No secret provided by FastSpring webhook' and returns true — even when a secret is stored. Only a present-but-wrong signature fails closed. FastSpring's own docs treat HMAC as optional on the sender; a receiver that has a secret must fail closed on a missing X-FS-Signature. After the bypass, handle_webhook_request dispatches on attacker-controlled type: order.completed calls payment_complete() on wc_get_order(data.tags.store_order_id) with no check that the order used FastSpring or that amounts match, so sequential WooCommerce IDs for any gateway can be fulfilled; return.created sets refunded; subscription.canceled/activated/deactivated set cancelled, active, or on-hold. Observable: a pending order becomes processing/completed (stock, emails, downloads) from a single unauthenticated POST. Upstream README states the plugin is not maintained (last code 2021), so there is no patch to wait for.

  includes/class-wc-gateway-fastspring-handler.php:352-374

  Recommendation

  Reject the request unless X-FS-Signature is present and hash_equals() the computed HMAC. Require a non-empty webhook_secret; do not treat a missing header as valid. Verify event payload (order is FastSpring, amounts/currency, data.completed) before payment_complete() or status changes. Until a maintained fork exists, disable this gateway — the GitHub README states it is not currently maintained.

• high Checkout receipt AJAX trusts client FastSpring order IDs to complete payment

  auth_bypass

  wc_ajax_wc_fastspring_get_receipt (ajax_get_receipt) is a public WooCommerce AJAX action. Auth is only wp_verify_nonce(payload->security, 'wc-fastspring-receipt'). payment_scripts() localizes that nonce in woocommerce_fastspring_params on any frontend page while the gateway is available (is_available() short-circuits the is_checkout() guard). A guest or customer who has started checkout has WC()->session['current_order'] set by get_cart_customer_details(). The JSON body fields reference and id are attacker-controlled. When api_username/api_password are set, get_order_status($payload->id) GETs https://api.fastspring.com/orders/{id} with the merchant Basic auth and, if that FastSpring order has completed===true, payment_complete($payload->reference) runs on the session order. There is no check that the FastSpring order matches the WooCommerce total, currency, or customer, or that the FastSpring id was not already applied to another order. A customer can pay a cheap FastSpring order, reuse that id/reference on a second expensive cart, and get fulfillment. Without API credentials the same call only forces pending and returns the thank-you URL, which is not payment_complete.

  includes/class-wc-gateway-fastspring-handler.php:97-144

  Recommendation

  Do not mark the WooCommerce order paid from client-supplied FastSpring ids. If API verification is used, look up the FastSpring order, require completed=true, and bind it to this WooCommerce order (matching total/currency and a unique fs_order_id). Prefer the signed webhook as the only payment_complete path. Restrict the receipt nonce/script to the checkout/order-pay pages.

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.