GHSA-h4qh-3qph-xfm6: 
PHP vulnerability analysis and mitigation

Summary

Webhook verification hashes the data object as unencoded key=value pairs joined by &, with null and nested values coerced to strings, and performed no type or shape validation on the received payload. An attacker who already holds one validly signed webhook can derive a structurally different payload that verifies under the same signature, for example a different orderCode, or an object substituted for a string field.

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.

Details

The signed string is built by sorting the top-level keys of data and joining key=value with &, without encoding. Values null, undefined and the literal strings "null"/"undefined" all become empty, and nested objects are stringified (in JavaScript, to [object Object]). Because verification accepted any keys, any value types and any characters:

• Delimiter smuggling. When a merchant reflects user input into description and a signed (data, signature) pair is exposed, a value containing & and = can be re-split into different fields. This moves orderCode (or another field) to a different integer under the same HMAC.
• Null-literal collisions. null and "null" hash identically.
• Type confusion. A signed string field whose value is [object Object] can be replaced by an arbitrary JSON object. Remote unauthenticated exploitation without a previously signed payload was not demonstrated.

Fix

The legacy signing format is unchanged, so existing webhooks keep verifying. Before hashing, the SDK now validates the received data:

• it must be a JSON object;
• keys must be non-empty ASCII [A-Za-z0-9_];
• the core payment fields must be present with the correct types;
• integers must be within ±(2^53 − 1);
• every value must be a string, a safe integer or null, and must not contain =;
• duplicate keys are rejected where the SDK parses the JSON text itself;
• the signature comparison runs in constant time. Invalid payloads raise an error starting with Invalid webhook data. Unknown string fields are still accepted and remain covered by the signature. A03 is partially mitigated for payment webhooks through required-field/type validation and rejection of delimiter-bearing values. Delimiter ambiguity remains possible for signatures over original values containing =. This release does not replace the legacy signing format or authenticate outer webhook metadata. Known limitation. The legacy signing format maps null, an empty string and the literal strings "null" and "undefined" to the same value, so they share one signature. Someone holding a signed webhook can swap a text field between these values, for example description: "null" to description: "". Integer fields such as orderCode and amount, nested objects and values containing = are rejected, so no other change is possible this way. Removing this needs a new signing format; until then, confirm the order's status and amount through the payment-link API before fulfilling it.

Workarounds

Upgrade. Until then, verify webhooks server-side only, and before fulfilling an order, confirm its status and amount through the payment-link API (GET /v2/payment-requests/{id}) instead of trusting webhook fields alone.

Credits

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