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.
Multiple security vulnerabilities affecting Apache Tomcat in Red Hat Enterprise Linux 10.0 Extended Update Support have been addressed. These include security constraint bypass, access control bypass due to an off-by-one error, improper authentication, authentication bypass via replay attack, unauthorized resource access via FORM authentication bypass, and denial of service via HTTP/2 allocation leak. A bug fix for stalled TLS handshake issues is also included. The update is rated as important by Red Hat Product Security.
CVE-2026-115355 is a vulnerability in the Mistune Markdown parser's Include directive that allows path traversal and cross-site scripting (XSS). The directive does not properly validate file paths, enabling attackers to read arbitrary files via '../' sequences. Additionally, error messages and included file contents are rendered without HTML escaping, causing XSS even when escaping is enabled. This vulnerability affects Mistune versions from 1.8.0 up to but not including 1.10.1. The Include plugin must be explicitly enabled for the vulnerability to be exploitable. A fix is available in version 1.10.1.
Jiratui's GitPython integration has a vulnerability where the create_submodule function clones a submodule into the .git/hooks directory before validating the path, allowing an attacker to plant a malicious executable hook. This hook executes on subsequent git operations, enabling arbitrary code execution. Versions from 3.1.x through 3.2.0+ are affected, with 3.1.x silently planting the hook and 3.2.0+ raising a ValueError only after the malicious hook is already written. The vulnerability requires an attacker-controlled submodule path and an empty or minimal .git/hooks directory.
GitPython's Submodule.move() API does not properly validate intermediate symlinks in the destination path, allowing an attacker-controlled symlink to redirect a submodule move operation outside the parent repository worktree. This can cause the submodule checkout to be moved to an attacker-chosen directory outside the repository, corrupting the parent repository's index and configuration. The issue affects GitPython 3.1.62 and current main branch. No code execution or confidentiality impact is demonstrated.
GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method where an attacker-controlled branch name can be used to perform an arbitrary file read. This occurs because the branch name is passed as a positional argument to git checkout without proper sanitization or argument separation, allowing injection of git options such as --pathspec-from-file. An attacker who can cause the application to clone a repository they control with a malicious default branch name can exploit this to read any file accessible to the application process, such as /etc/passwd. The vulnerability is a partial regression of previous fixes and affects all published releases up to 3.1.62 and the main branch at commit 4905b4af.
GitPython's Remote.pull() method improperly handles the positional refspec argument, allowing an attacker controlling this input to inject a --upload-pack option that bypasses the unsafe-option guard. This leads to arbitrary command execution with the privileges of the calling process when pulling from local-path or SSH transports. The vulnerability arises because the unsafe-option check only inspects keyword arguments, not positional ones, and git pull forwards the refspec to git fetch without a protective '--' separator. Exploitation requires attacker control over the refspec and use of a vulnerable transport, but no additional privileges or user interaction are needed.
GitPython versions >=1.3.0 have three wrapper methods that omit critical unsafe protocol and option checks, leading to potential command injection and remote code execution (RCE). The ls_remote method forwards URLs without checking for unsafe protocols, allowing RCE if the victim's git transport policy permits the 'ext' transport. The merge_base and IndexFile.move methods forward caller arguments without checking for unsafe options, creating latent injection surfaces. These issues are verified on the main branch as of 2026-09-21 and remain unpatched in the latest release 3.1.62. The vulnerability is rated high severity with a CVSS score of 7.5.
Jiratui's GitPython integration has a vulnerability in the parse_actor_and_date() function causing quadratic backtracking on malformed author/committer/tagger lines missing or having malformed trailing epoch or timezone data. This leads to CPU exhaustion when processing crafted commit or tag objects. The issue persists in version 3.1.62 despite a prior fix in 3.1.60 for a related regex. Accessing affected commit or tag fields on malicious objects can cause significant delays, impacting CI tooling, repository scanners, and code-hosting integrations.
GitPython's Repo._clone() method improperly expands environment variables in the separate_git_dir parameter derived from attacker-controlled .gitmodules submodule names. This leads to leakage of environment variable values as directory names on disk and in debug logs when cloning and updating submodules from a malicious repository. The vulnerability arises because Git.polish_url() is called without disabling variable expansion on untrusted input, contrary to other similar call sites. This can expose sensitive environment variables persistently on disk and in verbose logs.
A vulnerability in setuptools on Windows allows a crafted wheel's namespace_packages.txt to cause legacy wheel installation to create an __init__.py file outside the intended installation directory. The attacker can control the destination path of this file but not its contents. This occurs due to improper validation of absolute paths in namespace_packages.txt during installation. The issue affects setuptools versions >=1.38.0 and <2.30.0_1 and is fixed in version 2.30.0_1.
The Model Context Protocol (MCP) Python SDK client versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 validate tool output schemas by fetching external $ref URLs, including http, https, and file URLs, from the client's network position. This can cause the client to make unintended network or local file requests and stall if the remote endpoint is unresponsive. The issue affects clients calling tools on servers they do not fully control.
The Model Context Protocol (MCP) Python SDK versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where their HTTP client transports follow cross-origin HTTP redirects, sending custom headers and, on 307/308 redirects, the request body to the redirected host. This can expose sensitive headers such as X-API-Key to unintended origins if an attacker can cause a trusted endpoint to redirect to a malicious host. The Authorization bearer header is not exposed due to existing HTTP library protections. The issue affects SDK clients using HTTP with follow_redirects enabled. Fixed in versions 1.30.0 and 2.2.0, the SDK now restricts redirects to the same origin or http to https upgrades on the same host, failing otherwise.
Authlib's implementation of the RFC 9101 JWT-secured authorization request (JAR) extension allows an unauthenticated Server-Side Request Forgery (SSRF) vulnerability via the unvalidated request_uri parameter. The extension passes the attacker-controlled request_uri directly to a fetch hook without validating against the existing allowlist or performing recommended checks such as media type validation or timeouts. This flaw exists in Authlib version 1.7.2 and the current main branch. The vulnerability arises because the documented example implementation encourages an insecure fetch method that blindly performs HTTP GET requests on attacker-controlled URIs before any authentication occurs.
Authlib's OpenID Connect implicit grant implementation contains a vulnerability where the authorization request validation checks the raw client-supplied scope instead of the filtered allowed scope before issuing ID tokens. This allows a registered OAuth client, which is not permitted the 'openid' scope but allowed other scopes like 'profile', to receive a signed ID token if the user consents. The issue affects deployments using the OpenIDImplicitGrant and clients permitted 'id_token' response types without 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.
A vulnerability in dnspython's dns.name.from_wire_parser() function can cause excessive CPU usage when processing maliciously crafted DNS messages. This can degrade application performance or cause denial of service (DoS) in applications that handle untrusted DNS wire format messages using dnspython. The issue is fixed in dnspython version 2.9.0. No known workarounds exist.