CVE-2026-55096: SSRF via DNS-resolution gap in _validate_url_security (file download by URL)
fast-mcp-telegram is a Telegram MCP Server. Prior to version 30.1, the sendmessage/sendmessagetophone MCP tools accept files as a list of http(s) URLs, which the server downloads and attaches to the outgoing Telegram message. Downloads are guarded by validateurlsecurity, an SSRF denylist that checks the URL's literal hostname string but never resolves DNS. The fetch (httpx.AsyncClient.get) does its own resolution at request time. Consequently a hostname that resolves to a loopback / private / link-local address passes the guard and is fetched — even with the secure defaults blockprivateips=True and allowhttpurls=False. Because the fetched body is returned to the attacker as a Telegram file attachment, this is a full-read, exfiltrating SSRF, not blind. This issue has been patched in version 30.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
fast-mcp-telegramto a version that resolves this vulnerability.Fixed in 30.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using fast-mcp-telegram versions prior to 30.1 are affected where the send_message or send_message_to_phone MCP tools can be used to supply file URLs. The issue remains exploitable even when block_private_ips=True and allow_http_urls=False are configured.
What access does an attacker need?
An attacker needs low-privileged access sufficient to invoke one of the affected MCP tools and provide an HTTPS URL for a file attachment. No user interaction is required.
What can an attacker obtain through the SSRF?
An attacker can use a hostname that resolves to a loopback, private, or link-local address and cause the server to fetch it. The fetched response body is returned as a Telegram file attachment, enabling read access and exfiltration rather than only blind SSRF.
What should be done if upgrading cannot happen immediately?
The provided data identifies version 30.1 as the patch release. No alternative mitigation is specified; the documented secure-default settings do not prevent this bypass.