Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-24T20:17:19.183Z",
  "pubdate": "2026-08-24T20:17:19.183Z",
  "executiveSummary": "A vulnerability exists in the joserfc Python library prior to version 1.7.3, specifically within the JWTClaimsRegistry component.\nThe vulnerability type is improper validation of array-valued claims, which leads to an issuer-validation bypass.\nThis security flaw impacts applications utilizing joserfc to validate JSON Web Tokens (JWTs), allowing unauthorized entities to successfully authenticate by manipulating claim structures.\nThe risk implications include potential unauthorized access to protected resources and services, as tokens with improperly formatted issuer or subject claims bypass standard validation checks.\nAn attacker possessing the capability to forge or manipulate a JWT can supply a list-valued iss or sub claim containing the expected legitimate value within the array.\nNo complex exploitation requirements are noted beyond the ability to present a crafted JWT to the vulnerable system.\nThe issue is fully resolved in version 1.7.3 through the implementation of strict equality checks for string-based claim validation.",
  "technicalDetails": "The root cause of the vulnerability resides in the JWTClaimsRegistry component of the joserfc library.\nPrior to version 1.7.3, JWTClaimsRegistry incorrectly applies membership matching logic instead of strict equality checks when processing list-valued iss (issuer) and sub (subject) claims.\nWhen a JSON Web Token is evaluated, the validation logic verifies whether the expected issuer matches the claim present in the token payload.\nDue to the flawed membership matching implementation, if an attacker supplies an array-valued iss claim containing the expected issuer string as a member of the array, the validation routine evaluates the condition as true.\nThis erroneous behavior permits an array-valued iss to successfully pass an intended equality check that expects a scalar string value.\nConsequently, this enables an attacker to bypass issuer-validation controls enforced by the library.\nThe vulnerable component is the claim validation module within joserfc affecting all versions prior to 1.7.3.\nThe attack flow involves the adversary crafting a malicious JWT containing an array for the iss or sub claim, inserting the targeted legitimate string within that array, and presenting the token to the application endpoint.\nUpon receipt, the vulnerable joserfc library processes the token, executes the flawed membership check, and falsely validates the claims.\nThis grants the attacker unauthorized access or elevated privileges depending on how the application utilizes the validated identity.\nNetwork exposure depends on the application architecture, but any service utilizing the affected library for token validation over a network vector is susceptible.\nAuthentication and privilege requirements for exploitation are minimal, as the attack functions precisely to subvert the authentication boundary itself."
}