A vulnerability in the Authlib library (CVE-2026-114615) allows an attacker to forge HMAC signatures 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 inspects the start of the key bytes. If the PEM public key or X.509 certificate includes a leading byte such as a newline, space, or UTF-8 BOM before the '-----BEGIN' marker, the check is bypassed, allowing an attacker with only the public key to create a valid HS256 token with arbitrary claims. This flaw affects versions >=0.11.11 and <0.23.1_2 of the mcp-atlassian Authlib package and has been fixed in version 0.23.1_2.
Authlib versions from 0.13 through 1.7.2 contain a vulnerability in the is_secure_transport() function where the loopback exemption for HTTP URLs can be bypassed by including a userinfo component in the URL. This causes the function to incorrectly treat certain cleartext HTTP URLs with non-loopback hosts as secure, violating OAuth 2.0 / OIDC TLS requirements. The flaw affects validation of redirect URIs and authorization server metadata endpoints, potentially allowing an attacker to register or use insecure URLs that bypass TLS enforcement. The severity is low and a fix is available in version 0.23.1_1.
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 lead to denial of service (DoS) in applications that handle untrusted DNS wire format messages. The issue is fixed in dnspython version 0.23.1_2. No workarounds are currently known.
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.
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.