joserfc version range >=2.14.0_4 <2.15.0_5 has a vulnerability where the compact JWS size guard allocates attacker-controlled segments before rejecting them, causing unnecessary memory allocation. This occurs because the library calls bytes.split() on the input before validating its size, leading to a copy of the payload being made even if it will be rejected. The issue is fixed in version 2.15.0_5.
The joserfc library's decrypt_json() function for JWE General JSON Serialization does not limit the number of recipients in the 'recipients' array. An attacker can supply a JWE with an unbounded number of recipients, causing the library to perform a costly RSA private-key decryption operation for each recipient. This leads to a CPU exhaustion denial-of-service (DoS) condition. The library's documented mitigation option verify_all_recipients=False does not reduce CPU usage, as all recipients are decrypted unconditionally before this flag is checked. A fix is available in version 2.15.0_3.
CVE-2026-116672 is a vulnerability in Authlib's implementation of the OAuth 2.0 Dynamic Client Registration Management Protocol (RFC 7592). The provided example code for the ClientConfigurationEndpoint fails to bind the registration_access_token to the specific client being accessed, allowing an attacker with any valid token and knowledge of a client_id to bypass authorization and modify or delete client registrations. This flaw arises because the example implementations do not verify that the token belongs to the client targeted by the request. A fix is available in version 2.15.0_5.
Authlib versions prior to 2.15.0_5 contain a critical signature verification bypass vulnerability in the JsonWebSignature.deserialize_json() method. This flaw allows an attacker to submit a JSON Web Signature (JWS) object with an empty signatures array, which is incorrectly accepted as valid without any cryptographic verification. This results in an attacker-authored payload being accepted as signed, enabling complete authentication bypass without requiring any key material.
The Model Context Protocol (MCP) Python SDK versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 contain a vulnerability where the client fetches server-chosen external $ref URLs during tool result validation. This can cause the client to make network or local file requests synchronously without timeout, potentially freezing the client session. The issue is fixed in versions 1.30.0 and 2.2.0 or later.
The Model Context Protocol (MCP) Python SDK versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1 have an issue where their HTTP client transports follow cross-origin HTTP redirects and send custom headers and, on 307 or 308 redirects, the request body to the redirected host. This can expose sensitive headers such as API keys to unintended origins if the trusted endpoint redirects to a different host. The SDK's OAuth client providers are similarly affected. The lone Authorization bearer header is not exposed due to existing HTTP library behavior. The issue is fixed in MCP SDK versions 1.30.0 and 2.2.0, which restrict redirects to same-origin or scheme-upgrade only and fail otherwise.
The Model Context Protocol (MCP) Python SDK versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability in server-side bearer-token authentication. The SDK does not verify that a token's audience matches the intended server, allowing tokens issued for different services by the same authorization server to be accepted. This can lead to unauthorized access. Fixed in versions 1.30.0 and later for 1.x, and 2.2.0 and later for 2.x, with a new setting to enforce audience validation.
Authlib's RFC 9101 (JAR) extension contains a server-side request forgery (SSRF) vulnerability due to unvalidated use of the attacker-controlled request_uri parameter. The extension forwards this parameter to a fetch hook without validating against the existing allowlist or performing recommended checks, allowing unauthenticated SSRF attacks. This affects versions from 2.1.0 up to but not including 2.15.0_5. A fix is available in version 2.15.0_5.
Authlib versions from 2.1.0 up to but not including 2.15.0_5 contain a vulnerability in the OpenID Connect implicit grant implementation. The function validate_authorization_request incorrectly checks the raw requested scope instead of the filtered allowed scope before issuing ID tokens. This allows a registered OAuth client that is not permitted the 'openid' scope but allowed other scopes like 'profile' to obtain a signed ID token if the user consents. The ID token contains identity claims such as 'sub' and 'name', effectively bypassing the intended scope restrictions. The issue does not affect deployments using only the authorization code flow or where clients with implicit response types are also allowed the 'openid' scope. A fix is available in version 2.15.0_5.
Authlib's default implementation of the RFC 7523 JWT bearer grant does not properly validate the audience ('aud') claim in JWT assertions. Instead of verifying that the 'aud' claim matches the authorization server's token endpoint, it only checks for the presence of the claim. This allows an attacker with a valid JWT for any audience to obtain an access token from a different authorization server sharing the same signing key. A fix is available in Authlib version 2.15.0_5.
Authlib versions from 2.1.0 up to but not including 2.15.0_5 contain a vulnerability in the OpenID ID token nonce validation. The ID token's nonce validation can be disabled if the token includes a boolean false nonce_supported claim, allowing an attacker to replay a valid signed ID token with a mismatched nonce and authenticate as the victim. This affects implicit and hybrid flows and direct calls to parse_id_token(), but not the authorization code flow. A fix is available in version 2.15.0_5.
Authlib versions up to 1.7.2 accept an empty HMAC key for JWS/JWT signature verification using HS256, HS384, and HS512 algorithms. This allows an attacker to forge tokens with arbitrary claims that pass signature verification if the application verifies tokens with an empty key. The vulnerability arises because the library does not reject zero-length keys, resulting in a deterministic, publicly reproducible HMAC digest. This flaw can lead to token forgery and authentication bypass in OAuth 2.0 resource servers and OIDC relying parties using Authlib. A fix is available in version 2.15.0_5.
CVE-2026-114615 is a vulnerability in the mcpm product's use of authlib.jose where an incomplete fix for an algorithm confusion issue allows an attacker to forge HMAC signatures. The flaw arises because the check preventing asymmetric public keys from being used as HMAC secrets only matches keys starting exactly at byte 0, while the loader accepts keys with leading whitespace or comments. This discrepancy allows an attacker with only the issuer's public key to create a forged HS256 token that is accepted as authentic. The vulnerability affects versions >=2.1.0 and <2.15.0_5 and was fixed in version 2.15.0_5.
Authlib's is_secure_transport() function incorrectly treats URLs with a userinfo component containing loopback prefixes as secure, allowing cleartext HTTP URLs with external hosts to bypass TLS enforcement. This affects OAuth 2.0 / OIDC flows that require secure redirect and endpoint URIs. The vulnerability exists in Authlib versions from 0.13 through 1.7.2. It can lead to acceptance of non-TLS URLs in contexts that require TLS, violating specification requirements. The severity is low due to the nature of the flaw being a defense-in-depth and spec conformance issue.
A vulnerability in dnspython's dns.name.from_wire_parser() function allows a maliciously crafted DNS message to cause excessive CPU usage during DNS name decompression. This can degrade application performance or lead to denial of service (DoS) when processing untrusted DNS wire format messages. The issue is fixed in dnspython version 2.15.0_5. No known workarounds exist.
The pydantic-settings library's NestedSecretsSettingsSource component improperly follows symbolic links inside a configured secrets directory that point outside this directory. This allows reading files outside the intended secrets directory into application settings, bypassing the configured maximum size limit for secrets loading. The vulnerability requires the ability to place symlinks inside the secrets directory and is not remotely exploitable by itself. It affects versions from 2.9.0_2 up to but not including 2.15.0_2. The issue is fixed in version 2.15.0_2.
Starlette's request.form() method does not enforce configured limits on max_fields and max_part_size for application/x-www-form-urlencoded content types, allowing unauthenticated attackers to send requests with extremely large numbers of fields or very large field sizes. This leads to denial of service by blocking the event loop or causing excessive memory allocation. The issue is fixed in version 2.15.0_1 by properly enforcing these limits during parsing.
Starlette versions from 1.0.3 up to but not including 2.15.0_1 have a vulnerability where an unvalidated HTTP request path can alter the reconstructed request URL's hostname. This occurs because the path is concatenated directly after the host without ensuring it begins with a '/', allowing an attacker to craft a path that shifts the authority boundary and controls request.url.hostname. This can mislead code relying on request.url.hostname for security decisions. The issue is mitigated by upgrading to version 2.15.0_1 or later, which properly validates the path to prevent this behavior.
The joserfc library versions up to 1.6.7 accept attacker-forged HMAC-signed JWT tokens when the verification key is empty or None. This occurs because the library does not reject zero-length HMAC keys, allowing an attacker to forge tokens without secret knowledge if the configured secret is empty or unset. This vulnerability is a cross-language sibling of CVE-2026-45363 affecting ruby-jwt. No patched release existed at the time of this report, but a fix is available in version 2.15.0_1. The vulnerability requires no authentication and can be triggered if the JWT secret is sourced from an unset environment variable, missing database entry, or similar misconfiguration.
The joserfc library version 1.6.5 and earlier allow oversized RFC7797 b64=false JWS payloads to bypass the configured payload size limit during deserialization. This occurs because the payload size validation is not applied to unencoded payloads as specified by RFC7797, unlike normal base64url-encoded JWS payloads. This flaw can lead to moderate availability or resource exhaustion risks in applications that rely on joserfc to enforce payload size limits for security.