GHSA-v5hc-3j8r-9h37: 
PHP vulnerability analysis and mitigation

For endpoints whose response signature is carried in the body (payment-link create, get and cancel, and invoice retrieval), the SDK verifies the signature over a key=value&key=value string built from the response data without encoding the values. A string value containing a &key= sequence can therefore be re-split, so a validly signed response can be presented with different field values. Nested objects, unsupported keys and non-finite or unsafe numbers were also accepted and collapsed into the signed string.

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-88 (Improper Neutralization of Argument Delimiters in a Command).

Details

Precondition: the attacker must be able to modify responses between the merchant server and the payOS API, and the signed response must contain a string value the attacker influenced (for example a payment description). This is separate from the missing-signature issue: the SDK may require a signature and still accept a re-split one.

Fix

Before verifying a body signature, the SDK rejects response data containing a &key= sequence inside a string value, keys outside [A-Za-z0-9_], nested objects or arrays beyond a list of flat objects, and non-finite numbers or integers outside ±(2^53-1). Such responses raise the SDK's invalid-signature error.

Workarounds

Until upgrading, confirm payment state through verified webhooks, and ensure the HTTPS path to the payOS API does not traverse untrusted proxies.

Credits

Found by the payOS security team.