A vulnerability in setuptools on Windows allows an attacker to craft a wheel file with a specially crafted namespace_packages.txt that causes setuptools to create an __init__.py file outside the intended installation directory. This file is created at an attacker-influenced absolute path with fixed content and the permissions of the installing process. The issue arises because the path in namespace_packages.txt is not validated and can be interpreted as an absolute Windows path, leading to directory escape during legacy wheel installation.
Authlib versions prior to 1.9.0 contain a critical signature verification bypass vulnerability in the JsonWebSignature.deserialize_json() method. This method incorrectly accepts JSON Serialization JWS objects with an empty signatures array as valid without verifying any signature or requiring a cryptographic key. This flaw allows an attacker to forge payloads that are accepted as authenticated by any relying party using this method on untrusted input.
Authlib's implementation of the RFC 9101 JWT-secured authorization request (JAR) extension contains a security flaw where the attacker-controlled 'request_uri' parameter is passed to a fetch hook without validation at a pre-authentication endpoint. Although Authlib defines allowlists for 'request_uris' and requires registration, these controls are not enforced in the extension. The documented example implementation performs an unrestricted HTTP GET request on the 'request_uri', resulting in an unauthenticated Server-Side Request Forgery (SSRF) vulnerability. This flaw was verified in Authlib version 1.7.2 and the current main branch. The vulnerability allows attackers to induce the server to make arbitrary HTTP requests, potentially exposing internal resources.
Authlib's OpenID Connect implicit grant implementation contains a vulnerability where it checks the raw client-supplied 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 includes identity claims such as 'sub' and 'name', effectively bypassing intended scope restrictions. This issue affects deployments using the OpenID implicit grant and clients permitted 'id_token' response types but not the 'openid' scope. The vulnerability does not affect authorization code flow deployments or those where clients with 'id_token' response types are also allowed the 'openid' scope.
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.
Authlib's OpenID token parsing function improperly trusts the 'nonce_supported' claim inside the ID token payload to disable nonce validation. If this claim is set to the boolean false, nonce validation is skipped, allowing replay of a validly signed ID token from another session. This affects implicit and hybrid OpenID flows and direct calls to parse_id_token(), but not the authorization code flow. The vulnerability exists in Authlib version 1.8.0 and no fixed version is currently available.
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 arbitrary tokens 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 HMAC digest that anyone can reproduce. This flaw can lead to token forgery and authentication bypass in OAuth 2.0 resource servers and OIDC relying parties using Authlib when the HMAC key is empty at runtime.
A vulnerability in Authlib's Kaskade implementation allows an attacker to forge HMAC-signed JWT tokens by exploiting an incomplete fix for algorithm confusion. The issue 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 bytes such as newlines or spaces. This permits an attacker with only the issuer's public key to create valid HS256 tokens with arbitrary claims that are accepted as authentic.
Authlib's is_secure_transport() function incorrectly treats URLs with a userinfo component containing loopback prefixes as secure, allowing cleartext HTTP URLs with non-loopback hosts to bypass TLS enforcement. This affects OAuth 2.0 and OIDC endpoint and redirect URI validation, potentially allowing an attacker to register or use URLs that appear secure but actually point to external hosts over HTTP. The issue impacts Authlib versions from 0.13 through 1.7.2. The severity is low due to the nature of the vulnerability being a defense-in-depth and specification conformance failure.
A vulnerability in authlib's JWS implementation allows attackers to bypass signature verification by injecting a malicious JWK header. When key=None is passed to JWS deserialization functions, the library uses the attacker-controlled public key from the JWT header for verification, enabling forged tokens to be accepted as valid. This violates RFC 7515 specifications and can lead to complete authentication and authorization bypass.
A vulnerability in h11 versions up to 0.14.0 allows malformed HTTP/1.1 chunked-encoding bodies to be accepted due to lenient parsing of trailing line terminators. This can cause request smuggling when combined with a buggy reverse proxy that parses chunked bodies differently. The issue is fixed in h11 0.15.0. Exploitation requires both h11 and a proxy to have incompatible parsing bugs.
This release of Red Hat build of Quarkus 3.20.6 includes the following CVE fixes:
* netty-codec-http: Netty: Request smuggling via incorrect parsing of HTTP/1.1 chunked transfer encoding extension values [quarkus-3.20] (CVE-2026-33870)
* netty-codec-http2: Netty: Denial of Service via HTTP/2 CONTINUATION frame flood [quarkus-3.20] (CVE-2026-33871)
* plexus-utils: Plexus-utils: Directory Traversal in extractFile method [quarkus-3.20] (CVE-2025-67030)
* avro: Apache Avro Java SDK: Code injection on Java generated code [quarkus-3.20] (CVE-2025-33042)
* vertx-core: static handler component cache can be manipulated to deny the access to static files [quarkus-3.20] (CVE-2026-1002)
For more information, see the release notes page listed in the References section.