CVE-2026-54431
Received Received - Intake

DPoP Proof Verification Flaw in liboauth2

Vulnerability report for CVE-2026-54431, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-07-02

Last updated on: 2026-07-02

Assigner: CERT.PL

Description

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

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-02
Last Modified
2026-07-02
Generated
2026-07-02
AI Q&A
2026-07-02
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Showing 3 associated CPEs
Vendor Product Version / Range
openidc liboauth2 2.3.0
openidc liboauth2 to 2.3.0 (exc)
liboauth2 liboauth2 2.3.0

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-358 The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability exists in the liboauth2 library's implementation of Demonstrating Proof-of-Possession (DPoP) verification. Specifically, the DPoP verifier incorrectly accepts proofs whose JSON Web Key (jwk) header contains private key material, which violates RFC 9449 section 4.3 step 7 that requires such proofs to be rejected.

The function oauth2_token_verify() returns success even when the DPoP proof is malformed by embedding the private Elliptic Curve (EC) key in the header. This improper acceptance can lead to security risks because private key material should never be exposed or accepted in this context.

The issue was fixed by adding validation to ensure that the jwk header only contains public key information, rejecting any proofs that include private key data.

Impact Analysis

If exploited, this vulnerability could allow an attacker to bypass proper verification of DPoP proofs by submitting tokens that include private key material in the jwk header. This undermines the security guarantees of the Proof-of-Possession mechanism.

Accepting private key material in proofs could lead to unauthorized access or token misuse, as the verifier mistakenly trusts malformed proofs that should have been rejected.

This could result in compromised authentication flows or token validation processes, potentially exposing protected resources or allowing privilege escalation.

Detection Guidance

This vulnerability involves the liboauth2 library's DPoP verifier accepting proofs with private key material in the JSON Web Key (jwk) header, which should be rejected according to RFC 9449. Detection would involve inspecting DPoP proof tokens to verify if the jwk header contains private key data.

Since the issue is specific to malformed DPoP proofs accepted by the oauth2_token_verify() function, detection can be performed by capturing and analyzing OAuth 2.0 DPoP tokens in your network traffic or logs.

Commands to detect this vulnerability might include:

  • Using network packet capture tools like tcpdump or Wireshark to capture HTTP requests containing DPoP tokens.
  • Extracting and decoding the DPoP JWT tokens from captured traffic or logs.
  • Inspecting the 'jwk' header of the DPoP proof tokens to check for the presence of private key material, which should not be present.

However, no specific detection commands or scripts are provided in the available resources.

Mitigation Strategies

The vulnerability was fixed in liboauth2 version 2.3.0. The immediate mitigation step is to upgrade liboauth2 to version 2.3.0 or later, which includes validation to reject DPoP proofs containing private key material in the jwk header.

The fix involves a new validation function that ensures only public key information is accepted in the jwk header, preventing acceptance of malformed proofs.

If upgrading immediately is not possible, consider implementing additional validation on the DPoP tokens at your application level to reject proofs containing private key data in the jwk header.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-54431. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart