DPO Group for Wordpress Standalone WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

1.1.0

Findings

2

Worst severity

high

Content hash

bce5caa9bad42520d94bf55d… Copy

Findings

• high Unauthenticated payment-return IDOR: verified DPO token is not bound to post_id, so any paid transaction marks any order paid

  auth_bypass

  dpo_standalone_wp_payment_success is hooked to both admin_post_ and admin_post_nopriv_ (no capability, no nonce). It reads post_id, TransactionToken, and CompanyRef from $_REQUEST, calls Dpo::verifyToken with the site's Company Token plus the request TransactionToken, and if Result=='000' and the request CompanyRef equals the DPO response CompanyRef it update_post_meta's that post_id to dposa_order_status=paid (plus currency/amount/approval from DPO). It never loads the target post, never checks post_type==dpo_standalone_order, and never compares the request token/ref/amount to the values stored at token-create time (dposa_transaction_token, dposa_order_reference, dposa_order_data['paymentAmount']). CompanyRef is not a secret (DPO echoes it on the return URL and the success shortcode prints it). Observable attack: (1) pass reCAPTCHA and start a large-amount order A (wp_insert_post, token created, pay page not completed); (2) complete a small real payment B; (3) GET /wp-admin/admin-post.php?action=dpo_standalone_wp_payment_success&post_id={A}&TransactionToken={B's token}&CompanyRef={B's ref}. Order A's ledger is paid while DPO only collected B's amount. The same paid token can be replayed against every other post_id. This is not a full no-pay bypass (DPO must have returned 000 once) but it is unauthenticated payment-record tampering on the only WordPress state the plugin uses as a paid flag.

  dpo-standalone-wp-plugin.php:36-37,148-175

  Recommendation

  Load the order by post_id, require post_type dpo_standalone_order, and accept the callback only when request TransactionToken and CompanyRef (and verified amount/currency) match the stored dposa_transaction_token / dposa_order_reference / dposa_order_data. Reject already-paid orders (single-use token). Do not update arbitrary post IDs.

• medium Unauthenticated failure callback overwrites any post's dposa_order_status to failed

  missing_auth

  dpo_standalone_wp_payment_failure is also nopriv and takes post_id from $_REQUEST. After verifyToken, any parseable DPO XML (including an error body for a missing/invalid TransactionToken) causes update_post_meta($post_id, 'dposa_order_status', 'failed') with no check that the token belongs to that post, that the post is a dpo_standalone_order, or that the order is not already paid. The success handler's else branch does the same write when Result is not 000. Observable consequence: GET /wp-admin/admin-post.php?action=dpo_standalone_wp_payment_failure&post_id={n} (no auth, no valid token required as long as DPO returns XML) flips the payment ledger for that id to failed, including previously paid records. Same meta key as finding 1; blast is integrity/DoS of payment records rather than marking unpaid invoices paid.

  dpo-standalone-wp-plugin.php:38-39,176-182,199-216

  Recommendation

  Apply the same order-token binding and post_type check as the success handler. Do not mark an order failed unless the stored transaction token matches and the current status is still pending. Ignore unknown post_id values.

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.