GHSA-v238-c69x-9mmp: 
JavaScript vulnerability analysis and mitigation

Summary

usePayOS().open() loaded any CHECKOUT_URL into the checkout iframe and accepted postMessage events from any window on an allowlisted origin. The allowlist included development origins in production. The return URL was concatenated into the iframe query string without encoding. A page able to post messages from an allowed origin, or a merchant integration that passes an attacker-influenced CHECKOUT_URL, could trigger the merchant's onSuccess/onCancel/onExit callbacks or load a non-payOS page in the checkout frame.

Affected versions

Severity

Low — CVSS 3.1 base score 3.4, CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:L/A:N CWE-88, CWE-346, CWE-601, CWE-345.

Details

• C1 (CWE-88): RETURN_URL was appended to the iframe URL without encoding. A return URL containing &, ? or # could inject or truncate iframe query parameters.
• C2 (CWE-346): development and local origins were part of the production message-origin allowlist.
• C3 (CWE-601): CHECKOUT_URL was assigned to iframe.src without checking its origin, scheme or path.
• C5 (CWE-345): the message listener checked event.origin but not event.source. Any window on an allowed origin, not only the checkout iframe, could deliver payment_response events.

Fix

Version 1.0.9 makes these changes:

• CHECKOUT_URL must be an https://pay.payos.vn/web/<id> payment link; development origins are no longer accepted. For any other URL, open() logs Invalid CHECKOUT_URL and does nothing.
• The iframe URL is rebuilt from https://pay.payos.vn and the payment-link id, with redirect_uri set through URLSearchParams (encoded).
• Messages are accepted only when event.source is the library's own iframe and event.origin is https://pay.payos.vn.
• Only JSON objects are accepted as message data.
• payment_response events must reference the opened payment link.
• The listener is removed when the iframe closes. The public API (PayOSConfig, usePayOS(config) → { open, exit }) is unchanged. onSuccess is a UX signal only. It runs in the buyer's browser and can never prove payment. Merchants must confirm payment server-side through a verified webhook or the payment-link API before fulfilling an order.

Workarounds

Upgrade to @payos/payos-checkout@1.0.9. Until then:

• pass only checkoutUrl values returned by your own server's create-payment-link call;
• never fulfil an order from onSuccess; confirm payment server-side.

Credits

Vo Le Anh Tuan (Swinburne University of Technology), GitHub @tuankhongbietcode