Authlib versions including 1.8.0 contain a vulnerability in the OpenID ID token validation process. The parse_id_token() function reads the nonce_supported claim from the ID token payload. If this claim is the boolean false, nonce validation is disabled by setting the expected nonce to None, 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. No fixed versions are 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 tokens with arbitrary claims that pass signature verification if the application verifies tokens with an empty key. The vulnerability arises because empty keys produce deterministic, publicly reproducible HMAC digests, and no check rejects zero-length keys in the affected versions.
A vulnerability in the kimi-cli product's use of authlib allows an attacker to forge HMAC-signed JWT tokens by exploiting an incomplete fix in the key import validation. 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 craft HS256 tokens with arbitrary claims that are accepted as authentic. The issue affects versions >=0.40 and was confirmed in authlib 1.8.0 and main branch as of August 2026.
Authlib versions from 0.13 through 1.7.2 contain a vulnerability in the is_secure_transport() function, which incorrectly treats certain HTTP URLs with a userinfo component as secure loopback addresses. This allows an attacker to bypass the TLS enforcement by crafting URLs like http://localhost:80@evil.example/cb, which are accepted as secure despite being cleartext HTTP to an external host. The flaw affects OAuth 2.0 / OIDC endpoint and redirect URI validation, potentially allowing cleartext non-loopback URLs to be accepted where TLS is required. The severity is low, and a fix is available in version 1.50.0.
A vulnerability in the dnspython library used by kimi-cli allows a maliciously crafted DNS message to cause excessive CPU usage during DNS name decompression. This can degrade application performance or cause denial of service. The issue is fixed in dnspython version 2.9.0. No workarounds are currently known.
PyJWT versions up to 2.13.0 and current master at commit 7144e4534c34810f4525dc4578a32addd8212cff contain a vulnerability where the HMACAlgorithm.from_jwk method accepts an empty HMAC key from an oct JWK without rejection. This allows an attacker to forge tokens by exploiting the zero-length key acceptance during verification via PyJWK, PyJWKSet, or PyJWKClient. The issue arises because the empty-key rejection added in 2.13.0 for string/bytes keys was not applied to the JWK verification path. The vulnerability requires no authentication but depends on the verifier resolving an empty 'k' value from a JWK, which can occur due to misconfiguration or trusting a JWKS with such an entry. A fix is available in version 1.50.0 of the affected product kimi-cli.
FastMCP versions 3.0.0 through 3.4.9 and 4.0.0 through 4.1.1 contain an authorization bypass vulnerability where direct calls to transformed components skip the final authorization check. This allows low-privilege users to invoke protected tools, resources, templates, or prompts that should be denied. The issue arises because the server applies transforms before authorization but does not re-check the authorization on the transformed component in direct lookup paths. Fixes are available in FastMCP 3.4.10 and 4.1.2.
A regular expression used in OpenTelemetry Python's TraceState.from_header method causes quadratic CPU time complexity when parsing large tracestate headers containing long runs of spaces or tabs without commas. This can lead to significant processing delays and blocking of other connections in asynchronous servers. The issue affects versions from 1.0.0 through 1.49.x and is fixed in version 1.50.0.
Kimi CLI's GitPython integration has a vulnerability where the submodule creation function clones a submodule into the repository's .git/hooks directory before validating the path. This allows an attacker to plant an executable hook file that runs on subsequent git operations, leading to 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 hook is already written to disk.
**Affected:** `GitPython` **3.1.61** (latest release) and `main` — `git/objects/submodule/base.py`. `git diff 3.1.61 origin/main -- git/objects/submodule/` is empty, so both are identical here.
---
## The gap
The fix for `GHSA-hmq2-w58f-27jc` added `Submodule._validated_name()` and wired it into `update()` and five siblings, closing the `.gitmodules` **name** → `.git/modules/<name>` traversal. The other attacker-controlled `.gitmodules` field, **`path`**, is read raw:
```python
# git/objects/submodule/base.py:172-177
def _set_cache_(self, attr):
if attr in ("path", "_url", "_branch_path"):
reader = self.config_reader()
self.path = reader.get("path") # raw .gitmodules value
```
and GitPython's own containment guard is applied in only two of the places that consume it:
```
400: def _to_relative_path(cls, parent_repo, path) # the guard (abspath + commonpath containment)
542: path = cls._to_relative_path(repo, path) # add() — guarded
1041: module_checkout_path = self._to_relative_path(self.repo, module_path) # move() — guarded
```
`update()` validates only the name and then uses the path-derived absolute location directly:
```
788: self._validated_name(self.name) # NAME only
801: checkout_module_abspath = self.abspath # derived from self.path — unguarded
821: os.makedirs(checkout_module_abspath, exist_ok=True)
```
So `path = ../../../tmp/escaped` in an attacker-authored `.gitmodules` selects the directory that gets created and, on the clone path, populated from the submodule URL. The same absolute location is what `force_remove` hands to `shutil.rmtree`.
The asymmetry is the argument: this is not a missing concept — the project wrote `_to_relative_path()` precisely for this, and `add()`/`move()` use it. `update()` does not.
## Honest limits (please read before rating)
- **The most common flow is not affected.** `Repo.clone_from(...)` → `repo.submodules` → `sm.update(init=True)` re-derives `path` from a canonical tree lookup, and real git refuses to check out a tree containing a `..` component, so an evil `.gitmodules` never lands in the working tree in the first place. A reachable trigger therefore requires the victim's code to name a **non-HEAD commit** (a historical-commit API such as `submodule_update(previous_commit=...)`).
- **The researcher did not build that end-to-end trigger.** The researcher only verified first-hand the code above: the guard's two call sites, the name-only validation in `update()`, and the unguarded `abspath` → `os.makedirs()` flow at 3.1.61 == `main`.
## Suggested fix
Apply the guard the project already has, wherever the path is consumed:
```python
# in update(), before deriving abspath (and in any other consumer of self.path):
checkout_rel = self._to_relative_path(self.repo, self.path) # raises if it escapes the working tree
```
Better still, validate at the boundary: reject a `.gitmodules` entry whose `path` is absolute or contains a `..` component when the section is first read in `_set_cache_()`/`iter_items()`, so no consumer can be added later without the check. A regression test with `path = ../escaped` alongside the existing `name` test would pin both fields.
## Prior art checked
`GHSA-hmq2-w58f-27jc` (this is a residual of its fix, in the sibling field, not a re-report) plus the repository's 30 published advisories — none mentions the `path` field or `_to_relative_path`. Searched issues and PRs for `_to_relative_path`, `gitmodules path` and `submodule traversal`: no report of this.
## Credit
**kta1kri**.
---
## Appendix — `EVIDENCE_gitpython_path_unguarded_20260901.txt` (inlined; advisories accept no attachments)
```text
=== EVIDENCE: GitPython — the .gitmodules 'path' field reaches os.makedirs()/clone unguarded ===
Mon Aug 31 18:45:22 UTC 2026
--- artifact: tag 3.1.61 (latest release); git diff 3.1.61 origin/main -- git/objects/submodule/ is empty ---
--- the containment guard GitPython owns, and its only two call sites ---
33: _to_relative_path,
400: def _to_relative_path(cls, parent_repo: "Repo", path: PathLike) -> PathLike:
407: path = _to_relative_path(parent_repo.working_tree_dir, path)
542: path = cls._to_relative_path(repo, path)
1041: module_checkout_path = self._to_relative_path(self.repo, module_path)
--- the parent fix (_validated_name) call sites: it validates the NAME ---
309: def _validated_name(cls, name: str) -> str:
321: name = cls._validated_name(name)
541: cls._validated_name(name)
788: self._validated_name(self.name)
1040: self._validated_name(self.name)
1181: self._validated_name(self.name)
1439: self._validated_name(self.name)
1440: self._validated_name(new_name)
1489: self._validated_name(self.name)
--- update(): name validated, path not; abspath -> os.makedirs ---
try:
self._validated_name(self.name)
# ENSURE RE
GitPython version 3.1.59 contains a vulnerability (CVE-2026-87817) where the library incorrectly resolves the git directory path by testing certain tracked files before the actual .git directory. This allows an attacker controlling a repository to craft files that impersonate the git directory, causing GitPython to treat attacker-controlled content as internal git data, including executable hooks. This leads to arbitrary code execution when the victim performs a commit via GitPython's index.commit() method. Additional impacts include unauthorized reading of files outside the repository and writing config files to attacker-chosen locations. The vulnerability affects services that open or clone untrusted repositories using GitPython. A patch is available to correct the directory resolution order and improve validation.
GitPython's Actor.name_email_regex regular expression is vulnerable to catastrophic backtracking (ReDoS) when parsing commit author or committer fields containing a long string with an unterminated '<'. This causes quadratic CPU exhaustion, leading to denial of service. The vulnerability affects GitPython versions from 1.11.0 up to but not including 1.50.0. A crafted commit object can cause API calls accessing author or committer metadata to hang for over two minutes. This impacts CI runners, code-hosting backends, and repository scanning tools that process untrusted commits. A fix is available.
A critical vulnerability (CVE-2026-78676) in GitPython's GitConfigParser allows dormant multi-line git-config values to be corrupted into live injected directives upon any unrelated config write. This occurs because the parser's re-serialization logic mishandles multi-line values, causing injected directives like core.hooksPath to be interpreted by Git, enabling remote code execution (RCE). The issue affects GitPython version 3.1.58 at HEAD and specific kimi-cli versions. A patch is available.
A high-severity vulnerability in GitPython (CVE-2026-78675) allows arbitrary local file content disclosure via the [include] directive in an untrusted .gitmodules file. The SubmoduleConfigParser does not disable merge_includes, enabling an attacker to craft a malicious .gitmodules file that causes the parser to include and read arbitrary files on the victim's system. When the parser encounters a non-gitconfig file, it raises an exception that leaks the first line of the included file in the error message. This disclosure occurs during common read-only operations such as enumerating submodules, without requiring repository updates or checkouts. A fix is available for this vulnerability.
GitPython's Repo.blame() and Repo.blame_incremental() methods have an incomplete denylist for unsafe git revision options, omitting the --contents and -S options. This omission allows an attacker to cause arbitrary local file reads by passing these options, which echo file contents into the blame result. The vulnerability affects GitPython versions up to 3.1.58. A patch is available to address this issue by expanding the denylist to include these options.
Kimi CLI's GitPython integration contains a vulnerability (CVE-2026-67326) where newline injection in the config_writer() section parameter bypasses prior patch CVE-2026-42215. This allows an attacker controlling the section argument to inject newlines into .git/config, creating forged sections such as [core] with a malicious hooksPath. This leads to remote code execution (RCE) when git hooks are triggered. The vulnerability affects multiple version ranges of kimi-cli. A patch is available.
A vulnerability in Kimi CLI's GitPython integration (CVE-2026-42284) allows unsafe command-line options to bypass validation due to improper checking before shell splitting. Specifically, multi_options passed to clone operations are validated as original strings but executed after splitting, enabling injection of malicious git config options that execute attacker-controlled hooks during cloning or submodule updates.
A critical vulnerability (CVE-2026-32871) exists in the OpenAPIProvider component of FastMCP used by kimi-cli. The vulnerability arises from improper handling of path parameters in URL construction, where parameters are substituted without URL encoding. This allows an authenticated attacker to craft path traversal sequences that escape the intended API path and access arbitrary backend endpoints. The requests inherit the MCP provider's authorization headers, enabling authenticated SSRF attacks. A fix is available in version 1.44.0.
Authlib's JWS implementation contains a JWK Header Injection vulnerability (CVE-2026-27962) that allows attackers to forge JWT tokens that pass signature verification. This occurs when key=None is passed to JWS deserialization functions, causing the library to trust an attacker-controlled 'jwk' header field as the verification key. This violates RFC 7515 specifications and enables authentication and authorization bypass. The vulnerability affects authlib versions >=0.40 and <1.17.0. A fix is available in version 1.17.0.
A cryptographic padding oracle vulnerability (CVE-2026-28490) affects the Authlib Python library's implementation of the JSON Web Encryption (JWE) RSA1_5 key management algorithm. The vulnerability arises because Authlib disables the Bleichenbacher padding oracle mitigation by raising a distinct exception on invalid padding, enabling a reliable exception oracle. This issue is present by default in all Authlib installations without special configuration and was confirmed in Authlib version 1.6.8 with cryptography 46.0.5. A fix is available. The affected product is kimi-cli versions >=0.40 and <1.17.0.