Liboauth2
Monthly
DPoP (Demonstrating Proof-of-Possession) proof verification in OpenIDC's liboauth2 C library incorrectly accepts malformed proofs that embed private Elliptic Curve (EC) key material in the JWK header, directly violating RFC 9449 §4.3 step 7. The `oauth2_token_verify()` function returns success instead of rejecting such proofs, subverting DPoP's core token-binding security guarantee and enabling information disclosure of private key material. No active exploitation is confirmed (not in CISA KEV), no public exploit code has been identified, and a patch is available in liboauth2 2.3.0.
Server-Side Request Forgery in liboauth2 prior to version 2.3.0 allows an unauthenticated attacker to force any application using the AWS ALB JWT verification path to issue GET requests to arbitrary internal network paths. The vulnerability exists because the `oauth2_jose_jwks_aws_alb_resolve()` function reads the unverified `kid` JWT header field and appends it directly to the configured `alb_base_url` - without URL encoding or path sanitization - before any cryptographic signature check occurs. No public exploit code has been identified at time of analysis, but the low attack complexity and zero privilege requirement make this a meaningful risk for AWS-integrated deployments where liboauth2 handles ALB token verification.
DPoP (Demonstrating Proof-of-Possession) proof verification in OpenIDC's liboauth2 C library incorrectly accepts malformed proofs that embed private Elliptic Curve (EC) key material in the JWK header, directly violating RFC 9449 §4.3 step 7. The `oauth2_token_verify()` function returns success instead of rejecting such proofs, subverting DPoP's core token-binding security guarantee and enabling information disclosure of private key material. No active exploitation is confirmed (not in CISA KEV), no public exploit code has been identified, and a patch is available in liboauth2 2.3.0.
Server-Side Request Forgery in liboauth2 prior to version 2.3.0 allows an unauthenticated attacker to force any application using the AWS ALB JWT verification path to issue GET requests to arbitrary internal network paths. The vulnerability exists because the `oauth2_jose_jwks_aws_alb_resolve()` function reads the unverified `kid` JWT header field and appends it directly to the configured `alb_base_url` - without URL encoding or path sanitization - before any cryptographic signature check occurs. No public exploit code has been identified at time of analysis, but the low attack complexity and zero privilege requirement make this a meaningful risk for AWS-integrated deployments where liboauth2 handles ALB token verification.