Array-valued JWT claims enable issuer-validation bypass in authlib joserfc

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.

• The CNA identifies authlib joserfc as affected for versions < 1.7.3.
• The GitHub advisory expresses the same boundary as <=1.7.2 and identifies 1.7.3 as the patched version.
• No additional product, parallel release branch, or deployment qualifier is established by the available evidence.

The flaw is in JWTClaimsRegistry, where configured claims with list values are checked using membership matching instead of consistently enforcing the expected value and type. Registered claims that are defined as single StringOrURI values, including iss, sub, jti, and nonce, can therefore be processed as lists. For iss, an array containing the expected issuer can pass a check that the application intended to be an exact equality comparison. Exploitation requires a token to reach a verifier using the affected validation path; the available evidence does not establish how an attacker obtains a valid signature in every deployment. The vendor advisory demonstrates the condition with a signed token and shows that attacker-controlled payload data can be accepted by the verifier. The fix separates validation for single-valued claims and preserves list handling for aud or claims explicitly documented as multi-valued.

The flaw is network-reachable when an application accepts JWTs and uses JWTClaimsRegistry for claim validation. The supplied assessment indicates that no special privileges or user interaction are required, while attack complexity is high because the attacker must still get a token through the other checks present in the deployment. The record marks public exploit as true, and the vendor advisory includes a proof of concept. This confirms publicly available exploit material, but it does not by itself establish exploitation in a named campaign, victim environment, or deployment.

The direct technical outcome is issuer-validation bypass when an array-valued iss containing the expected issuer is treated as a successful equality match. If an application uses issuer or subject to bind a token to a tenant, user, service, or permission set, an attacker may be able to cause attacker-controlled claims to be accepted and may then obtain unauthorized access or perform unauthorized actions. That result depends on the application's authorization logic and is not guaranteed in every deployment. The available assessment does not identify an availability impact.

An affected verifier may treat a token with a spoofed issuer or identity claim as valid. Depending on how the application uses issuer, subject, or related claims, this could enable unauthorized access, identity spoofing, or actions that affect data and session integrity. The amount of data exposed and the privileges reached depend on the relying application's authorization logic rather than on the library alone. The available record does not identify a specific victim, campaign, or incident.

1. Upgrade authlib joserfc to 1.7.3, which the CNA and vendor identify as the fixed version.
2. If an upgrade is not immediately possible, add validation that rejects list-typed values for the single-valued claims iss, sub, jti, and nonce; keep list handling limited to aud or claims explicitly documented as multi-valued.
3. Retest the complete authentication and authorization flow after the change, including valid issuers, incorrect issuers, and claims with invalid data types.
4. Do not infer that other release branches are safe merely because one version is fixed; verify the status of every branch currently deployed.

1. Inventory Python environments, lockfiles, and dependency trees that install authlib joserfc, then compare each installed version with the affected and patched boundaries in affected_summary.
2. Locate code paths that use JWTClaimsRegistry to validate iss, sub, jti, or nonce, especially in services that use those claims for identity or authorization decisions.
3. In a controlled test environment, verify that the application rejects single-valued registered claims when their values are represented as lists, while preserving the intended handling of supported multi-valued aud claims.
4. Review authentication telemetry and logs for accepted JWTs in which iss, sub, jti, or nonce have array types. Treat this as a review signal, not as a vendor-confirmed indicator of compromise.
5. Do not treat the absence of matching log events as proof of safety; combine dependency checks with code-path review and validation behavior testing.