CVE-2026-119422 in Hyperswitch
Summary
by MITRE • 10/30/2026
Juspay Hyperswitch before 1.128.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge payment status updates because the Worldpayxml connector's verify_webhook_source always returns true without enforced mTLS. Attackers knowing the merchant_id and Worldpay orderCode can POST unsigned XML with lastEvent SETTLED to the worldpayxml webhook endpoint, marking unpaid payments as charged or triggering refund, dispute and payout events.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Juspay Hyperswitch versions prior to 1.128.0 represents a critical authentication bypass within the payment processing infrastructure, specifically affecting the Worldpayxml connector module. This flaw stems from an improper implementation of webhook source verification mechanisms, where the verify_webhook_source function is hardcoded or logically flawed such that it invariably returns true regardless of the actual authenticity of the incoming request. In secure financial systems, webhooks are essential for asynchronous communication between payment gateways and merchant platforms to update transaction statuses. However, this particular implementation fails to enforce mutual Transport Layer Security (mTLS) or validate cryptographic signatures required by Worldpay standards, thereby stripping away the primary layer of trust verification that ensures messages originate from legitimate sources rather than malicious actors.
From a technical perspective, the core deficiency lies in the absence of strict input validation and source authentication for incoming webhook payloads. An attacker who possesses knowledge of specific merchant identifiers and associated order codes can exploit this gap by crafting unsigned XML requests. By targeting the worldpayxml webhook endpoint with POST requests containing forged data, specifically setting the lastEvent field to SETTLED, an adversary can manipulate the state machine governing payment transactions. This manipulation allows the system to incorrectly transition unpaid or pending payments into a settled status, effectively simulating successful financial transactions that never actually occurred through legitimate banking channels.
The operational impact of this vulnerability is severe and directly impacts financial integrity and data consistency within the e-commerce ecosystem. By forging settlement events, attackers can cause merchants to believe they have received payment for goods or services when no actual funds have been transferred. This discrepancy often leads to significant financial losses as merchants may ship products or provide digital content based on false confirmation of receipt. Furthermore, the vulnerability extends beyond simple fraud; it enables the triggering of unauthorized refund, dispute, and payout events. Attackers can manipulate these downstream processes to reverse legitimate transactions or initiate fraudulent payouts, compounding the financial damage and potentially disrupting the operational workflow of payment processors and merchants who rely on accurate real-time status updates for reconciliation and accounting purposes.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to adequately verify the identity of a claimed entity during communication. Additionally, it relates to CWE-345 Insufficient Verification of Data Authenticity, given that the webhook payloads are accepted without verifying their origin or integrity against expected cryptographic proofs. In terms of offensive security frameworks, this exploitation technique maps to MITRE ATT&CK T1078 Valid Accounts and potentially T1199 Trusted Relationship Exploitation if attackers leverage compromised credentials alongside this logic flaw to blend malicious activity with legitimate traffic patterns. The lack of mTLS enforcement further exacerbates the risk by allowing these forged requests to traverse network boundaries without additional cryptographic verification layers that would typically detect tampering or spoofing attempts.
Mitigation strategies must prioritize immediate patching to version 1.128.0 or later, where this logic flaw has been corrected and proper authentication checks are enforced. For environments unable to upgrade immediately, compensating controls should include implementing strict IP allowlisting for webhook endpoints if the payment gateway supports static source IPs, although this is less robust than cryptographic verification. Enforcing mTLS at the network perimeter ensures that only clients presenting valid certificates issued by a trusted authority can communicate with the Hyperswitch instance. Additionally, application-level validation must be strengthened to require and verify digital signatures on all incoming webhook payloads before processing any state changes. Monitoring systems should also be configured to alert on anomalous patterns of settlement events originating from unexpected sources or exhibiting unusual frequency relative to historical baselines for specific merchant IDs.