liboauth2 flaws allow SSRF, DPoP bypass

Two vulnerabilities in the liboauth2 OAuth2/OIDC library allow SSRF via AWS ALB JWT verification and let forged DPoP proofs bypass proof-of-possession checks; fixed in 2.3.0.

CERT Polska coordinated disclosure of two vulnerabilities in liboauth2, an open-source OAuth2/OpenID Connect library. CVE-2026-54430 is a Server-Side Request Forgery flaw in the oauth2_jose_jwks_aws_alb_resolve() function: the AWS ALB token verifier reads the unverified 'signer' and 'kid' fields from a JWT header, and if the signer matches a configured ARN, appends the attacker-controlled kid value to the internal alb_base_url without encoding or sanitization before issuing an HTTP GET — and does this before any signature verification takes place. This allows an attacker to coerce the server into making arbitrary GET requests to internal-only paths, a classic SSRF primitive that could expose internal services or metadata endpoints.

CVE-2026-54431 affects the library's DPoP (Demonstrating Proof-of-Possession) verifier. RFC 9449 section 4.3 explicitly requires rejection of any DPoP proof whose JWK header contains private key material, but the oauth2_token_verify() function in liboauth2 was found to accept malformed proofs embedding a private EC key, returning a success result in violation of the spec. This undermines the security guarantee DPoP is designed to provide, potentially allowing token replay or impersonation scenarios the mechanism is meant to prevent.

Both issues were reported by Michał Majchrowicz and Marcin Wyczechowski of AFINE Team through CERT Polska's coordinated vulnerability disclosure process, and are fixed in liboauth2 version 2.3.0. There is no indication of active exploitation; organizations using liboauth2, particularly those relying on AWS ALB JWT verification or DPoP-based proof-of-possession, should upgrade promptly.

Source reporting: https://cert.pl/en/posts/2026/07/CVE-2026-54430