Threats affecting pkg:brew/fastmcp

CVE-2026-48817 is a vulnerability in Starlette's HTTPEndpoint where arbitrary HTTP methods can invoke unintended endpoint attributes. This occurs when an HTTPEndpoint subclass is registered without explicitly restricting allowed HTTP methods, allowing non-standard methods to call internal methods as handlers. The issue affects Starlette and frameworks built on it, such as FastAPI. The vulnerability is fixed in version 3.4.0.

A vulnerability in Fastmcp's Starlette framework allows an attacker to bypass path-based security checks by sending a malformed HTTP Host header. The Host header is not properly validated before reconstructing request.url, causing request.url.path to differ from the actual requested path. Applications relying on request.url.path for security decisions may be bypassed. The issue is fixed in version 3.3.1_1. Mitigation includes upgrading to the fixed version or deploying a reverse proxy that rejects malformed Host headers.

FastMCP's OpenAPIProvider contains a critical SSRF and path traversal vulnerability (CVE-2026-32871) due to improper handling of path parameters. The vulnerability arises because path parameters are substituted directly into URL templates without URL encoding, allowing attackers to inject traversal sequences like '../'. This enables escaping the intended API prefix and accessing arbitrary backend endpoints with the MCP provider's authentication context. The flaw allows unauthorized access to internal APIs, privilege escalation, and potential data exfiltration or service disruption.

A vulnerability in authlib's JWS implementation (CVE-2026-27962) allows an attacker to bypass signature verification by exploiting the library's fallback to a JWK header key when no verification key is provided or found. This enables forging arbitrary JWT tokens that pass as valid, violating RFC 7515 specifications. The flaw affects versions >=2.12.3 and <3.1.0 and is fixed in version 3.1.0.

FastMCP's OAuthProxy callback handler does not verify that the browser sending the authorization code has just given consent, leading to a Confused Deputy vulnerability when using the GitHubProvider OAuth integration. An attacker can trick a victim, already logged into GitHub and previously authorized, into sending a valid authorization code to a malicious client, allowing unauthorized access to the victim's MCP server resources. This affects FastMCP versions from 2.12.3 up to but not including 3.2.0. A fix is available in version 3.2.0.

FastMCP versions from 2.12.3 up to but not including 3.2.0 have a command injection vulnerability on Windows. This occurs when server names contain shell metacharacters such as '&' and are passed to the 'fastmcp install claude-code' or 'fastmcp install gemini-cli' commands. The vulnerability arises because these commands invoke Windows .cmd wrapper scripts via cmd.exe, which interprets metacharacters, allowing arbitrary command execution. This does not affect macOS or Linux, nor does it affect config-file-based install targets. The issue is fixed in version 3.2.0 by validating server names to reject shell metacharacters.

CVE-2025-62801 is a command injection vulnerability in the FastMCP Cursor installer on Windows. It arises from unsafe handling of the server_name field, which is embedded directly into a shell command without sanitization. This allows attackers who can control server_name to execute arbitrary OS commands on affected Windows hosts running fastmcp install cursor. The vulnerability affects FastMCP versions from 2.12.3 up to but not including 2.13.0. A fix is available in version 2.13.0.

FastMCP versions from 2.12.3 up to but not including 2.13.0 contain a reflected Cross-Site Scripting (XSS) vulnerability in the OAuth client callback page. This occurs because user-controlled input parameters, such as the 'error' GET parameter, are embedded into the callback page without proper escaping or sanitization, allowing execution of arbitrary JavaScript in the callback server's origin. The vulnerability is fixed in version 2.13.0.

Starlette's FileResponse component contains a vulnerability in its HTTP Range header parsing logic that leads to quadratic-time processing. An unauthenticated attacker can craft a Range header that causes CPU exhaustion per request, resulting in denial-of-service for endpoints serving files. This affects any Starlette application using FileResponse or StaticFiles, as well as frameworks built on Starlette such as FastAPI when serving files. The vulnerability is fixed in version 2.13.0.2_1.

FastMCP OAuth Proxy improperly issues tokens without binding them to the specific MCP server resource requested, instead using a generic base URL. This flaw allows an attacker running a malicious MCP server to trick victims into authenticating and then reuse stolen tokens to access other legitimate MCP servers using the same OAuth Proxy. The vulnerability affects FastMCP versions from 2.12.3 up to but not including 2.14.2. A fix is available in version 2.14.2 that ensures tokens are issued specifically for the MCP server indicated in the authorization request's resource parameter.

FastMCP versions from 2.12.3 up to but not including 2.14.0 allow usage of MCP SDK versions prior to 1.23, which are vulnerable to CVE-2025-66416. FastMCP itself does not directly use the vulnerable MCP SDK components. Upgrading to FastMCP 2.14.0 or later mitigates exposure to this vulnerability.

### Summary `joserfc.jwt.decode` accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or `None`. `HMACAlgorithm.sign` and `HMACAlgorithm.verify` in [`src/joserfc/_rfc7518/jws_algs.py:62-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L62-L70) feed whatever `OctKey.get_op_key(...)` produced into `hmac.new(...)`, and `OctKey.import_key` only emits a `SecurityWarning` when the raw key is shorter than 14 bytes without rejecting zero-length input. Any application whose JWT secret is sourced from an unset environment variable, an unset Redis / DB row, a key finder fallback that returns `""`, or a `Hash.new("")`-style default verifies attacker tokens forged with `HMAC(key=b"", signing_input)` because the attacker trivially reproduces the same digest with no secret knowledge. This is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x / CVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key, filed 2026-05-13). ruby-jwt v3.2.0 added an `ensure_valid_key!` precondition that rejects empty keys at both sign and verify entry; joserfc has no equivalent. (The same primitive lives in the deprecated `authlib.jose` module by the same maintainer; filing this advisory against joserfc alongside a separate `authlib` advisory because the codebases are independent shipping artifacts on PyPI.) ### Affected versions `joserfc` (PyPI) `<= 1.6.7` (latest published release reproduces). No patched release. ### Privilege required Unauthenticated. Any HTTP / RPC endpoint that calls `joserfc.jwt.decode` with a verification key sourced from configuration is reachable. The condition that makes the bug observable is operator-side: the configured secret resolves to `""` or `None`. Common patterns that produce this state in production: - `OctKey.import_key(os.environ.get("JWT_SECRET", ""))` - A key finder callable that returns `""` / `None` for an unknown `kid` - Default values like `os.getenv("SECRET") or ""`, `cfg.get("secret", "")` - Database / Redis row lookup that returns `""` for a missing row ### Vulnerable code [`src/joserfc/_rfc7518/jws_algs.py:43-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L43-L70): ```python class HMACAlgorithm(JWSAlgModel): SHA256 = hashlib.sha256 SHA384 = hashlib.sha384 SHA512 = hashlib.sha512 def __init__(self, sha_type, recommended=False): self.name = f"HS{sha_type}" self.description = f"HMAC using SHA-{sha_type}" self.recommended = recommended self.hash_alg = getattr(self, f"SHA{sha_type}") self.algorithm_security = sha_type def sign(self, msg: bytes, key: OctKey) -> bytes: op_key = key.get_op_key("sign") return hmac.new(op_key, msg, self.hash_alg).digest() def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool: op_key = key.get_op_key("verify") v_sig = hmac.new(op_key, msg, self.hash_alg).digest() return hmac.compare_digest(sig, v_sig) ``` [`src/joserfc/_rfc7518/oct_key.py:52-63`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/oct_key.py#L52-L63): ```python @classmethod def import_key(cls, value, parameters=None, password=None) -> "OctKey": key: OctKey = super(OctKey, cls).import_key(value, parameters, password) if len(key.raw_value) < 14: # https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final warnings.warn("Key size should be >= 112 bits", SecurityWarning) return key ``` The `< 14` check only warns; `len(key.raw_value) == 0` falls through and is returned to the caller. `HMACAlgorithm.verify` then calls `hmac.compare_digest(sig, hmac.new(b"", signing_input, sha256).digest())`, and Python's `hmac.new(b"", ...)` accepts the empty key. Cross-language sibling of ruby-jwt's fix in [`lib/jwt/jwa/hmac.rb`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/lib/jwt/jwa/hmac.rb): ```ruby def ensure_valid_key!(key) raise_verify_error!('HMAC key expected to be a String') unless key.is_a?(String) raise_verify_error!('HMAC key cannot be empty') if key.empty? end ``` invoked from both `sign(signing_key:)` and `verify(verification_key:)`. PyJWT landed an equivalent guard in 2.13.0 (`HMACAlgorithm.prepare_key` raises `InvalidKeyError("HMAC key must not be empty.")` for `len(key_bytes) == 0`). firebase/php-jwt rejects empty material in `Key.__construct`. jjwt enforces a 256-bit minimum in `DefaultMacAlgorithm.validateKey`. joserfc has the strongest existing length-warning logic but stops at `< 14 bytes` warn rather than `== 0` reject. ### How an empty `JWT_SECRET` reaches `hmac.new` 1. The application calls `joserfc.jwt.decode(value, key, algorithms=["HS256"])` where `key = OctKey.import_key("")` (or `OctKey.import_key(b"")`, or any custom path t