A critical vulnerability in fast-mcp-telegram, a Python package that exposes Telegram accounts through the Model Context Protocol (MCP), allows unauthenticated remote attackers to bypass bearer token authentication entirely and take over the default Telegram session.
Tracked as GHSA-rxw2-pc8j-vxwm, the flaw affects all versions up to and including 0.19.0 and was patched in version 0.19.1, released on May 29, 2026.
The vulnerability stems from a classic but often overlooked flaw class: path traversal via unsanitized token input used directly in filesystem operations.
fast-mcp-telegram authenticates HTTP clients using Bearer tokens that map directly to session files on disk. The verifier logic explicitly blocks one dangerous value: the literal string telegram because that name corresponds to the default legacy session file (~/.config/fast-mcp-telegram/telegram.session) used in stdio and no-auth deployments.
The problem is that this blocklist check is naive. It rejects the exact string telegram but never sanitizes path separators, . or .. sequences, or resolves the final path before checking file existence. That omission opens the door to a trivial traversal alias:
../fast-mcp-telegram/telegramWhen appended with .session and joined to the session directory, this resolves right back to the very file the blocklist was designed to protect:
~/.config/fast-mcp-telegram/../fast-mcp-telegram/telegram.session
= ~/.config/fast-mcp-telegram/telegram.sessionThe exact string telegram is denied, but its traversal-disguised twin sails through untouched.
Once the malicious token authenticates, SessionFileTokenVerifier.verify_token() and the client-building logic in src/client/connection.py both accept it as a legitimate AccessToken.
The downstream account-prefix middleware, designed to label MCP tools per authenticated account, has no way to detect forgery. It simply sees a valid session and dutifully exposes prefixed tools like default_alice_send_message for the compromised account.
Security researchers validated the exploit with a stub-based proof-of-concept, confirming that a traversal token not only bypasses authentication but also grants access to message reading, message sending, MTProto API calls, and attachment-handling tool surfaces all without a real generated bearer token or Telegram credentials.
This bug is a reminder that authentication boundaries built on filesystem path concatenation are only as strong as their input sanitization. Reserved-name blocklists are fragile controls; they protect against literal matches but say nothing about equivalent paths reachable through traversal.
Any HTTP-exposed fast-mcp-telegram server with the default or legacy telegram.session file present is effectively wide open to any attacker who knows this technique; no credential guessing, no brute force require
The GitHub advisory outlines concrete fixes now implemented in version 0.19.1:
- Enforce a strict token alphabet (e.g.,
^[A-Za-z0-9_-]{32,128}$) matching properly generated URL-safe tokens. - Reject
/,\,.,.., empty segments, and absolute paths in both header and URL-based auth. - Resolve the final session path and confirm it remains a direct child of the configured session directory before granting access.
- Apply identical validation across all token-consuming code paths, including setup and cleanup routines.
- Add regression tests covering traversal aliases, URL-encoded variants, and Windows-style separators.
Administrators running fast-mcp-telegram in HTTP auth mode should upgrade to 0.19.1 immediately and audit logs for anomalous tokens resembling path traversal sequences.
About the Author
