CVE-2026-102275: Public/Private Key Identity Confusion in PyJWT OKP JWK Processing

The pyjwt library provides cryptographic signing and verification operations for JSON Web Tokens (JWT) and JSON Web Signatures (JWS) in Python environments. To process JSON Web Keys (JWKs), the library implements parsing functions to map JSON data to cryptographic key objects using the Python standard cryptography library. Under RFC 8037, Octet Key Pairs (OKP) are used for Ed25519 and Ed448 signatures, presenting a specific attack surface when untrusted clients present keys directly to the server.

This vulnerability belongs to the cryptographic identity confusion bug class (specifically CWE-345). It affects the deserialization phase of OKP JWK structures. When an application imports a JWK containing both public and private key parameters, pyjwt fails to mathematically validate the relationship between the two parameters. This flaw occurs within the algorithm-specific JWK parser, which assumes the underlying cryptographic engine validates key consistency implicitly.

In identity-bound authentication schemes such as Demonstrating Proof-of-Possession (DPoP, RFC 9449), the authentication framework extracts the client's identity using the JWK's public components. If the application processes client-supplied keys without validation, this implementation flaw allows an unauthorized entity to bypass cryptographic guarantees. An attacker can construct a hybrid key that maps to a legitimate user's identity but is cryptographically controlled by the attacker.

The root cause of CVE-2026-102275 resides in jwt/algorithms.py inside the OKPAlgorithm.from_jwk deserialization method. RFC 8037 defines OKP JWK payloads using three main parameters: the curve identifier (crv), the public key coordinate (x), and the optional private key scalar (d). Standard security requirements demand that if both x and d are supplied in a single JWK object, they must represent a mathematically coherent public/private key pair.

In affected versions of PyJWT, the algorithm checks for the presence of the private key parameter d. If d is absent, the parser instantiates a public key object strictly using the decoded bytes of x. If d is present, the parser bypasses the x parameter entirely and directly passes the bytes of d to from_private_bytes(). The library instantiates a private key object and immediately returns it to the calling application without verifying the relationship between x and d.

Because the Python cryptography library's from_private_bytes() function does not require or accept the associated public key bytes to initialize an OKP private key, the logic allows a severe discrepancy. The instantiated private key contains its own mathematically derived public key. However, the outer JWK object retains the mismatched public coordinate x specified by the attacker. Applications that rely on the parsed JWK for thumbprint-based identity binding but use the returned key object for signature verification are left vulnerable to identity confusion.

In vulnerable versions of PyJWT (2.1.0 to 2.14.0), the OKP JWK import routine executes the following path:

# Vulnerable Implementation in jwt/algorithms.py
x = base64url_decode(obj.get("x"))
if not obj.get("d"):
    if curve == "Ed25519":
        return Ed25519PublicKey.from_public_bytes(x)
    return Ed448PublicKey.from_public_bytes(x)
 
d = base64url_decode(obj.get("d"))
if curve == "Ed25519":
    # Vulnerable: Instantiates private key from d without validating x
    return Ed25519PrivateKey.from_private_bytes(d)
return Ed448PrivateKey.from_private_bytes(d)

The security patch applied in commit 3cd9ceec33ced359decbad75b413ad668ae6332c introduces strict cryptographic verification of the key pair before returning the parsed key:

# Patched Implementation in jwt/algorithms.py
            d = base64url_decode(obj.get("d"))
            private_key: Ed25519PrivateKey | Ed448PrivateKey
            if curve == "Ed25519":
                private_key = Ed25519PrivateKey.from_private_bytes(d)
            else:
                private_key = Ed448PrivateKey.from_private_bytes(d)
            
            # Verification Step: Derive the public key from the private key
            # and assert byte-level equality with the declared public parameter 'x'
            if (
                private_key.public_key().public_bytes(
                    encoding=Encoding.Raw, format=PublicFormat.Raw
                )
                != x
            ):
                raise InvalidKeyError("Public key does not match private key")
            return private_key

This fix is highly effective. By extracting the public key bytes directly from the newly initialized private key using private_key.public_key().public_bytes(...) and running a constant-time comparison against the user-supplied x, the parser guarantees that any discrepancy immediately raises an InvalidKeyError. This blocks hybrid key configurations before they can reach signature verification engines.

The primary threat vector for CVE-2026-102275 involves OAuth 2.0 frameworks implementing Demonstrating Proof-of-Possession (DPoP) under RFC 9449. DPoP prevents token theft by binding the access token to the client's private key. The client includes a DPoP HTTP header containing a JWS. The JWS header contains a jwk element representing the client's public key, and the server validates the signature against this public key.

An attacker who intercepts a valid access token bound to a victim's public key x_victim cannot normally use it because they lack the corresponding private key. To exploit this vulnerability, the attacker generates their own key pair (x_attacker, d_attacker) and crafts a malicious hybrid JWK. The attacker sets the public parameter `

The concrete security impact of CVE-2026-102275 is an authentication and sender-constraint bypass on services implementing Ed25519/Ed448 tokens. An attacker can hijack existing sessions, impersonate legitimate clients, and perform unauthorized API operations. The attack requires no prior privileges or user interaction, assuming the attacker has obtained a target token and has network access to the target API.

The CVSS v3.1 score is evaluated at 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N. The High Attack Complexity reflects the fact that an exploit requires the target system to accept private key parameters within client-supplied headers. Although standard implementations of DPoP explicitly reject private parameters, many API gateways and custom resource servers do not perform this check, parsing the JWK structurally without filtering.

EPSS scores show a low probability of exploitation in the wild (0.00137), primarily because the vulnerability relies on the intersection of OKP algorithms and loose input validation policies. However, inside enterprise architectures that rely heavily on decentralized JWT validation and trust-on-first-use models, this flaw constitutes a silent, critical security bypass.

The definitive remediation is upgrading the PyJWT installation to version 2.15.0 or later, which enforces key consistency out-of-the-box. If upgrading PyJWT is not immediately feasible due to legacy dependency constraints, applications must implement input-filtering middleware to inspect incoming JWK structures.

According to RFC 9449, clients must never transmit private key parameters within public headers. Implementing an explicit schema-validation layer that inspects client-provided JWKs for the presence of the private key parameter d mitigates this attack vector at the application boundary. If d is detected in a client-supplied token or header, the transaction must be blocked immediately.

# Defensive Validation Middleware
def enforce_public_jwk_only(jwk_payload: dict) -> None:
    forbidden_private_keys = {"d", "p", "q", "dp", "dq", "qi"}
    if any(param in jwk_payload for param in forbidden_private_keys):
        raise ValueError("Security Exception: Private key components detected in client-supplied JWK.")

Additionally, applications should restrict the supported signature algorithms (algorithms parameter in jwt.decode()) to the absolute minimum. If your environment does not strictly require Ed25519 or Ed448, omitting 'EdDSA' from the allowed algorithms list fully neutralizes the attack surface.