High-severity findings.

Audited release

8.6.14

Findings

2

Worst severity

high

Content hash

ffa58256ae6bcc738a90a6ac… Copy

Findings

• high REST routes with __return_true dump all order meta and write extra-config executed as checkout JS

  missing_permission_callback

  Three routes (logs, configController, api) use permission_callback __return_true. Auth inside the callbacks is a loose ==/!= of the URL `secret` to pagantis_private_key or pagantis_private_key_4x (query string can override the path secret). /api joins wp_posts (all shop_order) to wp_postmeta and returns every meta_key/meta_value for the date window — billing emails, addresses, and third-party payment tokens, not just Pagantis orders. The SELECT runs even when the secret is wrong. POST /configController/{secret} writes any defaultConfigs key (PAGANTIS_SIMULATOR_DISPLAY_TYPE_CHECKOUT, PAGANTIS_SIMULATOR_DISPLAY_SKIN, PAGANTIS_SIMULATOR_DISPLAY_TYPE, PAGANTIS_URL_OK/KO, PAGANTIS_ALLOWED_COUNTRIES, CSS selectors, PAGANTIS_PROMOTION_EXTRA, …) into pagantis_config. Those values are then: (a) echoed unquoted into checkout <script> as `type: <?php echo $simulator_type; ?>` / `skin : <?php echo $pagantisSimulatorSkin; ?>` in templates/checkout_description.php and checkout_description4x.php; (b) eval()'d on product pages in assets/js/pg-product-simulator.js (eval(simulatorData.simulator_type/skin/position)); (c) unserialize()'d on is_available/payment_fields. Combined with the sibling unauthenticated SQLi (which can steal the private key from woocommerce_pagantis_settings) this is an unauthenticated stored checkout skimmer / object-injection write. The secret itself lives in the URL, so server access logs and Referer also leak it.

  WC_Pagantis.php:672-808

  Recommendation

  Remove these REST routes from the storefront or gate them with a capability plus a high-entropy HMAC that is not the payment private key and is not placed in the URL. If a merchant-to-Pagantis channel is required, bind the client IP/signature, use hash_equals, and never return all shop_order postmeta. Escape extra-config as JSON/JS (wp_json_encode / esc_js) and stop eval()'ing simulator type/skin/position; do not unserialize attacker-writable rows.

• high Payment notify confirms any same-amount WooCommerce order when a valid Pagantis token is presented

  auth_bypass

  pagantisNotification is unauthenticated. getPagantisOrderId looks up the Pagantis order solely by $_GET['token'] (`SELECT order_id FROM {prefix}cart_process WHERE token='…'`). The WooCommerce order that is payment_complete()'d is $_GET['order-received'], independently. The `key` query argument (the WC order key placed on the callback URL) is never verified, and wc_order_id stored next to the token is never compared. validateAmount only checks that the Pagantis AUTHORIZED amount equals the chosen WC order total. An attacker who has a token for an AUTHORIZED payment of amount X (their own return URL, a leaked notification URL, or access logs) can replay /?wc-api=wcpagantisgateway&order-received={victim_or_attacker_order}&token={stolen} and mark a different pending/on-hold/failed order of total X as paid. Sequential order IDs plus common catalog prices make same-amount substitution practical. GET origin=redirect (customer return) takes this path; POST notifications do too.

  controllers/notifyController.php:119-173,376-402

  Recommendation

  Require the callback to present the WooCommerce order key and verify it with hash_equals against the loaded order. Look up the cart_process row by token AND wc_order_id (the order-received value) so a token cannot confirm a different order. Verify a Pagantis webhook signature in addition to the token. Refuse GET for payment confirmation; only accept signed POST notifications.

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.