Juspay Hyperswitch EUVD-2026-113802

Exploitation requires the Hyperswitch deployment to use the Worldpayxml connector, whose verify_webhook_source returned true unconditionally so no signature check or mTLS was enforced on incoming webhooks. The attacker must additionally know a valid merchant_id AND the corresponding Worldpay orderCode to craft an event the system will accept and correlate - this knowledge requirement is the AC:H/AT:P gating factor and the main limiter on real-world exploitability. No account, credentials, or user interaction are needed (PR:N/UI:N). Deployments not using the Worldpayxml connector are not affected; upgrading to 1.128.0 (or 2026.10.01.0) is required as the vendor fix.

This is a credible, prioritize-this-week issue rather than a theoretical high-CVSS finding. The vulnerability is a hardcoded authentication bypass: the Worldpayxml connector's verify_webhook_source returned Ok(true) unconditionally (the vendor fix changes it to Ok(false)), so the webhook signature/mTLS check never actually ran. The supplied CVSS 4.0 vector (8.2) is AV:N/PR:N/UI:N, meaning network-reachable and unauthenticated, but AC:H/AT:P reflect a real gating precondition stated in the description: the attacker must know a valid merchant_id and the corresponding Worldpay orderCode to forge an accepted event. Impact is integrity-only (VI:H; VC:N/VA:N), consistent with forging payment-status transitions (marking unpaid payments as SETTLED/charged, or triggering refund, dispute and payout events) rather than reading data or taking the service down - but for a payment orchestrator that integrity impact is financial. Signals are partly missing: no EPSS score and no CISA KEV status were provided, so exploitation probability cannot be quantified and there is no evidence of active exploitation. A third-party research write-up (abraxaslabs) is referenced, indicating public analysis of the flaw, but the input does not confirm it as working, weaponized exploit code. The vuln.today decision label is 'this_week', aligning with a prompt-patch (not emergency) posture. Note the scope limit: only deployments that actually use the Worldpayxml connector are affected, which narrows real-world exposure considerably below what the raw 8.2 suggests.

An attacker who has learned a target merchant's merchant_id and a valid Worldpay orderCode (e.g. from an order they placed or from leaked references) sends an unsigned XML POST with lastEvent SETTLED to the merchant's worldpayxml webhook endpoint. Because verify_webhook_source always returned true, Hyperswitch accepts the forged event and marks an unpaid payment as charged, or triggers refund/dispute/payout flows - enabling payment fraud without any authentication. A public research reference describing the unsigned-webhook flaw exists, but the input does not confirm it as working exploit code.