GHSA-fp4v-3mhm-pwjx: 
PHP vulnerability analysis and mitigation

Summary

When response signature verification is enabled, the SDK skips the check entirely if the API response carries no signature (or an empty one). An attacker who can modify API responses can strip the signature and substitute arbitrary response data, which the SDK then returns as verified.

Affected versions

Severity

Low — CVSS 3.1 base score 3.7, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N CWE-347 (Improper Verification of Cryptographic Signature), CWE-290 (Authentication Bypass by Spoofing).

Details

Response verification applies to payment-request create, get and cancel, and to invoice retrieval. The affected SDKs guarded the check with a condition equivalent to "if a signature is present and data is present, verify". A response with the signature removed therefore passed without any check:

• Node: if (resSignature && data) in the client response handler.
• Python (sync and async clients): the check was skipped when the signature was falsy.
• PHP: the check ran only when the signature header was present.
• .NET: the header lookup threw on absence instead of failing verification, and the surrounding logic skipped the check. The signature comparison also used a non-constant-time equality operator. Precondition: the attacker must be able to modify responses between the merchant server and the payOS API, for example through a compromised or malicious proxy or a TLS interception point the merchant trusts.

Fix

When response verification is enabled, a missing or empty signature now raises Missing response signature. A mismatch still raises Data integrity check failed. The comparison runs in constant time.

Workarounds

Until upgrading, re-fetch payment state with a separate verified call, or confirm payments only through verified webhooks, and ensure the HTTPS path to the payOS API does not traverse untrusted proxies.

Credits

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