Skip to main content

v26.3.7

v26.3.7​

An attacker who obtained a live consent verifier for another user's accepted flow could redeem it for a different OAuth 2.0 client. This could yield an authorization code for the attacker's client carrying the user's subject.

Exploitation required an accepted, unexpired, unconsumed consent verifier and the matching browser and CSRF context. An attacker could not use a verifier from their own flow. Obtaining the required verifier therefore depended on a separate compromise or leak in the trusted handoff between Hydra, the consent application, and the user's browser.

Hydra now binds the verifier to the OAuth 2.0 client resolved for the authorization request. Self-hosted Ory Hydra and Ory Enterprise License users should upgrade to a version containing this fix. The fix is deployed across the Ory Network, and Ory Network users do not need to take action.

Hydra also rejects a mismatched login verifier before recording authentication session state. The login-verifier path did not yield an authorization code because Hydra rejected the client mismatch later in the flow, but it could apply session or subject-mapping side effects before that rejection.

This change also allows POST authorization requests to carry all parameters in the URL-encoded request body. Hydra previously rejected such requests with invalid_client after a login or consent verifier was issued.