CVE-2026-75509 in joserfc
Summary
by MITRE • 08/24/2026
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to version 1.7.3, JWTClaimsRegistry applies membership matching to list-valued iss and sub claims, allowing an array-valued iss that contains the expected issuer to pass an intended equality check and enabling issuer-validation bypass. This issue is fixed in version 1.7.3.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The JSON Object Signing and Encryption (JOSE) standards define a set of specifications for creating encrypted and/or signed content using JSON, with JWT being one of the most widely adopted formats within this ecosystem. The joserfc library serves as a Python implementation of these standards, facilitating secure token handling in various applications. A critical security flaw was identified in versions prior to 1.7.3 regarding the validation logic employed by the JWTClaimsRegistry class. This component is responsible for verifying claims embedded within JSON Web Tokens against expected values provided by the application developer or configuration settings. The vulnerability specifically affects how list-valued claims, such as iss (issuer) and sub (subject), are processed during membership matching operations.
The technical root cause of this vulnerability lies in an overly permissive equality check mechanism for array-type claims. In a secure implementation, when validating an issuer claim that is expected to be a single string value, the system should strictly enforce type consistency or perform precise element-wise comparison if arrays are anticipated. However, the flawed logic allowed an attacker to supply an iss claim as an array containing multiple values, including one that matches the expected legitimate issuer. Because the validation routine checked for membership rather than strict equality of structure and content, it considered the token valid even though its format deviated from the standard expectation. This bypasses the intended security control designed to ensure tokens originate exclusively from trusted sources.
This flaw has significant operational implications for applications relying on joserfc for authentication and authorization decisions. An attacker can craft a malicious JWT where the issuer claim is an array rather than a simple string, yet still include the legitimate issuer within that array. When this token is presented to a vulnerable service, the validation logic accepts it as authentic because the expected issuer exists within the provided list. This effectively neutralizes issuer-based trust boundaries, allowing unauthorized entities to impersonate trusted services or users. In environments where microservices communicate via JWTs, such an attack could lead to privilege escalation, data exfiltration, or complete compromise of the authentication infrastructure if other validation steps are similarly weakened by this structural ambiguity.
The issue is categorized under CWE-20 Improper Input Validation and aligns with ATT&CK technique T1652 Impersonate Cloud Credentials, as it involves manipulating token claims to bypass access controls. It also relates to CWE-94 Improper Control of Generation of Code (Code Injection) in a broader sense if the parsed tokens are subsequently executed or used to drive dynamic behavior without further sanitization. The vulnerability highlights the importance of strict type checking and structural validation when processing cryptographic tokens, ensuring that expected data types match exactly rather than relying on loose containment checks for sensitive identity claims.
To mitigate this risk, organizations using joserfc must upgrade immediately to version 1.7.3 or later, where the membership matching logic has been corrected to enforce stricter equality checks for issuer and subject claims. Developers should also implement defense-in-depth strategies by validating token structure explicitly before passing them to higher-level business logic. This includes verifying that claim types match expected schemas, such as ensuring iss is a string rather than an array unless specifically designed otherwise. Regular security audits of authentication flows and the use of static analysis tools configured to detect JOSE-related vulnerabilities can further reduce exposure to similar implementation flaws in third-party libraries.