CVE-2026-52830: fast-mcp-telegram <=0.19.0 allows bearer token path traversal to authenticate as the default telegram.session, bypassing reserved session name protections and enabling unauthorized access to Telegram MCP tools.

fast-mcp-telegram <= 0.19.0 uses the raw HTTP Bearer token as a file-name fragment when building a session-file path. It checks the token against a set of reserved names (e.g. telegram) but never rejects path separators or normalizes the result. A token such as ../fast-mcp-telegram/telegram therefore resolves to the same reserved telegram.session file that the exact name check is meant to protect, while bypassing the name check. A remote HTTP client who knows the target session directory layout can authenticate as the default account and list or invoke the exposed Telegram MCP tools.

• Package/component: fast-mcp-telegram (PyPI), specifically src.server_components.session_token_verifier.SessionFileTokenVerifier and src.server_components.auth_middleware.UrlTokenMiddleware.
• Affected versions: <= 0.19.0.
• Patched version: 0.19.1.
• Risk level: High. A remote, unauthenticated attacker can bypass bearer-token authentication and gain access to the victim's Telegram MCP tools as the default session without any Telegram credentials.
• Consequences: Unauthorized access to tools such as get_messages, send_message, send_message_to_phone, invoke_mtproto, etc., under the identity of the default telegram session.

Impact Parity

• Disclosed/claimed maximum impact: Authorization bypass via HTTP Bearer token path traversal (api_remote / authz_bypass).
• Reproduced impact from this run: Real HTTP auth bypass on a running fast-mcp-telegram 0.19.0 instance. The reserved token telegram is rejected (HTTP 401), while the traversal alias ../fast-mcp-telegram/telegram is accepted (HTTP 200) and returns the protected tools/list response. The patched 0.19.1 build rejects the same traversal token (HTTP 401).
• Parity: full for the claimed auth-bypass surface; the reproduction exercises the actual remote HTTP API and reaches the authenticated MCP path.
• Not demonstrated: We did not demonstrate actual Telegram message exfiltration or message sending, because no real Telegram session credentials are configured. However, the auth layer is clearly bypassed and the tool list is exposed, proving the claimed authorization bypass.

Root Cause

In src/server_components/session_token_verifier.py (0.19.0), verify_token() does:

if token.lower() in RESERVED_SESSION_NAMES:
    return None
session_path = self._session_directory / f"{token}.session"
if not session_path.is_file():
    return None
return AccessToken(token=token, ...)

The reserved-name check is exact and case-insensitive, but the token string is then inserted directly into the path with only a .session suffix. Because pathlib.Path does not normalize .. in the operand, the token ../fast-mcp-telegram/telegram yields:

<session_dir>/../fast-mcp-telegram/telegram.session

When session_dir is the default ~/.config/fast-mcp-telegram, this resolves to ~/.config/fast-mcp-telegram/telegram.session, the same default session file the exact-name check is trying to protect. The same vulnerable path construction is also present in UrlTokenMiddleware, which rewrites the URL token into the Authorization header.

The 0.19.1 fix introduces src/server_components/session_token_validation.py. It validates the token against a strict ^[A-Za-z0-9_-]{43}$ pattern and uses session_file_path(), which resolves the constructed path and verifies it is still inside session_dir with is_relative_to(). Any traversal sequence or reserved name is rejected before the file existence check.

Reproduction Steps

Run the self-contained script:

bash bundle/repro/reproduction_steps.sh

The script:

1. Reads bundle/project_cache_context.json and uses the provided project_cache_dir for persistent Python venvs.
2. Creates two virtual environments, installing fast-mcp-telegram==0.19.0 (vulnerable) and ==0.19.1 (fixed).
3. Creates a controlled HOME and default session directory ~/.config/fast-mcp-telegram, then touches telegram.session so the default session exists.
4. Starts each version in http-auth mode on a different localhost port and waits for /health to return 200.
5. Sends a JSON-RPC tools/list request to POST /v1/mcp with three different bearer tokens on the vulnerable server:
   • telegram (reserved, expected 401)
   • ../fast-mcp-telegram/telegram (traversal alias, expected 200)
   • invalid-token (no matching session file, expected 401)
6. Sends the same traversal token to the fixed server (expected 401).
7. Writes bundle/repro/runtime_manifest.json and exits 0 only when the expected statuses are observed.

Expected evidence

• repro/artifacts/http_vuln_reserved.txt and http_vuln_noauth.txt: HTTP 401 response body.
• repro/artifacts/http_vuln_traversal.txt: HTTP 200 SSE event containing the full tools/list result.
• repro/artifacts/http_fixed_traversal.txt: HTTP 401 response body from the patched version.
• logs/server_vuln.log and logs/server_fixed.log: server startup logs showing mode http-auth and the session directory.

Evidence

Captured artifacts:

• bundle/repro/artifacts/http_vuln_traversal.txt (HTTP 200, tools list returned)
• bundle/repro/artifacts/http_vuln_reserved.txt (HTTP 401, reserved token rejected)
• bundle/repro/artifacts/http_vuln_noauth.txt (HTTP 401, invalid token rejected)
• bundle/repro/artifacts/http_fixed_traversal.txt (HTTP 401, traversal token rejected on 0.19.1)
• bundle/logs/server_vuln.log
• bundle/logs/server_fixed.log
• bundle/repro/runtime_manifest.json
• bundle/logs/reproduction_steps.log
• bundle/logs/reproduction_steps_run2.log

Key excerpt from the vulnerable traversal response (first line only for brevity):

event: message\r\n
data: {"jsonrpc":"2.0","id":1,"result":{"tools":[{"name":"search_messages_globally", ...

This demonstrates that the protected tools/list endpoint returned successfully using only the traversal token.

The fixed server log confirms the same traversal token now returns HTTP 401:

{"error": "invalid_token", "error_description": "Authentication failed..."}

Environment details captured in the logs: Python 3.14, uvicorn, fastmcp-slim 3.4.2, fast-mcp-telegram 0.19.0 / 0.19.1, session directory repro/fakehome/.config/fast-mcp-telegram.

Recommendations / Next Steps

• Upgrade to fast-mcp-telegram >= 0.19.1, which enforces a strict token format and resolves/session-directory containment checks.
• Network-level mitigation until patched: restrict access to the MCP HTTP port so only trusted clients can reach it.
• Detection: monitor authentication logs for tokens containing path separators or unusual patterns.
• Testing recommendation: add regression tests that attempt tokens such as ../session, ..\\session, telegram, and /etc/passwd and assert they are rejected before any file existence check.

Additional Notes

• The script was run twice consecutively from a clean project-cache state; both runs exited 0 and produced the same status sequence (401, 200, 401 on vulnerable; 401 on fixed), confirming idempotency.
• The GitHub source repository for fast-mcp-telegram was not directly reachable in this environment, so the reproduction relies on the official PyPI wheels. The relevant source code is visible in the installed site-packages and confirms the vulnerable Path concatenation in 0.19.0 and the new session_token_validation.py containment check in 0.19.1.
• No real Telegram credentials or network connectivity to Telegram are required for the reproduction; the bypass is demonstrated purely against the local authentication layer.