EUVD-2026-41277
GHSA-3pf6-g4x4-jm46
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network vector because DPoP proofs arrive over HTTP; PR:N since proof submission requires no prior authentication; C:L and I:L reflect private key disclosure risk and DPoP binding bypass respectively.
Primary rating from Vendor (CERT-PL).
CVSS VectorVendor: CERT-PL
Lifecycle Timeline
2DescriptionCVE.org
In liboauth2 the Demonstrating Proof-of-Possession (DPoP) verifier accepts a proof whose JSON Web Key (jwk) header contains private key material. RFC 9449 section 4.3 step 7 requires the verifier to reject such a proof but oauth2_token_verify() function returns success for a malformed DPoP proof that embeds the private Elliptic Curve (EC) key in the header.
This issue was fixed in version 2.3.0
AnalysisAI
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.
Technical ContextAI
DPoP (RFC 9449) is an OAuth2 proof-of-possession mechanism that binds access tokens to a client-held asymmetric key pair. A DPoP proof is a signed JWT whose header includes a jwk parameter containing the public key - the verifier uses this to confirm the presenter holds the corresponding private key. RFC 9449 §4.3 step 7 explicitly mandates that verifiers MUST reject any DPoP proof whose jwk header contains private key material, since the JWK header is intended to carry only the public component. The affected library, liboauth2 (CPE: cpe:2.3:a:openidc:liboauth2:*:*:*:*:*:*:*:*), is an OpenIDC C library for building OAuth2/OIDC resource servers and authorization servers. The root cause maps to CWE-358 (Improperly Implemented Security Check for Standard): a required validation step mandated by the RFC specification was not implemented, causing a compliant-looking but invalid proof to pass verification. The elliptic curve (EC) key format is specifically implicated, suggesting the JWK parsing logic did not distinguish between public-only and private-key-bearing EC JWK structures.
RemediationAI
Upgrade liboauth2 to version 2.3.0 or later, which contains the fix per commit c0b57152ed6a0af33aeb04a60bd7f5bff5ab8800 (https://github.com/OpenIDC/liboauth2/commit/c0b57152ed6a0af33aeb04a60bd7f5bff5ab8800). The CERT-PL advisory at https://cert.pl/en/posts/2026/06/CVE-2026-54430 (note: URL references CVE-2026-54430, potentially a related sibling CVE from the same report - verify applicability) and the upstream repository at https://github.com/OpenIDC/liboauth2 are the authoritative sources. If immediate upgrade is not possible, a compensating control is to disable DPoP support at the application layer if it is not operationally required - this eliminates the affected code path entirely, though it removes the token-binding security benefit DPoP provides. Alternatively, deploy an API gateway or reverse proxy that pre-validates DPoP proof JWTs and rejects any containing private key material in the JWK header before they reach the liboauth2-based backend, though this adds architectural complexity and requires the proxy to implement RFC 9449 §4.3 step 7 correctly.
Same technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today