Juspay Hyperswitch CVE-2026-119421

Exploitation requires two concrete prerequisites: possession of the target merchant's publishable key (the client-authentication key, which is not a protected secret) and a valid payout_id for an existing payout. With those, the attacker calls POST /payouts/{payout_id}/confirm and supplies an arbitrary client_secret; the vulnerable code never checks the supplied client_secret against the payout's stored client_secret, so the confirmation is authorized and the attacker can overwrite amount, currency, connector, and routing. Limiting factors: the attacker must know or obtain a valid payout_id and the merchant publishable key (reflected in AC:H/AT:P); the source fix is gated on the v1 feature (#[cfg(feature = "v1")]), indicating v1 payout deployments are the confirmed-affected mode; fixed in build 2026.10.19.0 and versions after 1.128.0.

Signals are moderately consistent and point to a real but not emergency-level priority. The CVSS 4.0 base score is 8.2 driven by VI:H (integrity-only; VC:N, VA:N) - appropriate because the flaw lets an attacker tamper with payout parameters (amount, currency, connector, routing) to trigger unauthorized merchant payouts, a direct financial-integrity impact rather than data disclosure or outage. The vector's AC:H and AT:P indicate non-trivial prerequisites, which tempers raw severity: the attacker must possess the merchant's publishable key and a valid payout_id, so this is not trivially mass-exploitable. KEV status is not listed, so there is no confirmed active exploitation; EPSS is not provided in the input, so exploitation probability cannot be quantified here. A public technical write-up (abraxaslabs) and a VulnCheck advisory are referenced, so a public PoC reference exists but is not verified as working exploit code - do not conflate this with active exploitation. The vuln.today decision label is 'this_week', consistent with a high-impact, patch-available authorization flaw that has limiting prerequisites rather than drive-by exploitability. Net: a genuine priority for Hyperswitch operators handling payouts, but the publishable-key and payout_id prerequisites (AC:H/AT:P) argue for prompt patching rather than fire-drill urgency.

An attacker who has obtained a target merchant's publishable key (a client-side, non-secret key) and a valid payout_id submits POST /payouts/{payout_id}/confirm supplying any client_secret value; because the stored client_secret is never validated, the request is authorized and the attacker overwrites the amount, currency, connector, and routing fields to confirm a payout to attacker-controlled parameters. A public technical write-up describing the issue exists but is not verified as working exploit code. The CVSS 4.0 vector (AV:N, AC:H, AT:P) reflects that exploitation is remote and unauthenticated per the vector but conditioned on obtaining the publishable key and payout_id.