What happened
The SSRF denylist in fast-mcp-telegram's file-URL downloader was bypassable because it validated only literal hostname strings; attackers could supply domains that resolve to loopback or private addresses (demonstrated in tests with mocked getaddrinfo for localtest.me → 127.0.0.1 and internal-service.local → 10.x). Fixed in 30.1 by adding DNS-resolution validation.
Why it matters
Telegram MCP servers are commonly run on analyst/ops machines with network reach into internal infrastructure; an SSRF reachable through an agent-callable MCP tool lets a poisoned prompt or compromised agent pivot from the tool server into internal services and cloud metadata endpoints.
Attack vector
The send_message tools accept a list of file URLs that the server fetches and attaches to outgoing Telegram messages; _validate_url_security blocks literal localhost/private strings but did not resolve domains that resolve to 127.0.0.1 or 10.x.x.x (e.g. localtest.me → 127.0.0.1), enabling SSRF to internal services and cloud metadata.
Affected systems
leshchenko1979/fast-mcp-telegram < 30.1 (send_message / send_message_to_phone tools)
Mitigation
Upgrade to fast-mcp-telegram >= 30.1 (commit e6b3032), which adds socket.getaddrinfo DNS-resolution checks so URL validation matches resolved addresses, not just hostname strings.