openclaw - ✅(Solved) Fix [Bug]: SSRF guard blocks http proxy address (127.0.0.1) during Telegram media download [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60475Fetched 2026-04-08 02:50:39
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
Participants
Timeline (top)
labeled ×2commented ×1cross-referenced ×1mentioned ×1

When channels.telegram.proxy is set to http://127.0.0.1:1082, Telegram media downloads fail with "Blocked hostname (not in allowlist): 127.0.0.1".

Error Message

{"subsystem":"security"} blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot.../photos/file_113.jpg reason=Blocked hostname (not in allowlist): 127.0.0.1 {"module":"telegram-auto-reply"} MediaFetchError: Failed to fetch media: Blocked hostname (not in allowlist): 127.0.0.1

Root Cause

SSRF guard rejects the request because 127.0.0.1 (the proxy address) is not in hostnameAllowlist: ["api.telegram.org"]. Gateway log shows:

security: blocked URL fetch (url-fetch) target=https://api.telegram.org/file/.../photos/file_113.jpg reason=Blocked hostname (not in allowlist): 127.0.0.1

Fix Action

Fix / Workaround

Affected: Users with http proxy configured for Telegram (workaround for Issue #60472 ) Severity: High (all media silently fails, no error surfaced to user) Frequency: Always (100% reproducible) Consequence: Cannot use http proxy for Telegram even as workaround for socks5 issue

buildTelegramMediaSsrfPolicy() sets hostnameAllowlist: ["api.telegram.org"]. When undici sets up CONNECT tunnel through the proxy, assertExplicitProxyAllowed() checks the proxy IP against this allowlist. Suggested fix: auto-add proxy hostname to allowedHostnames, or set allowPrivateProxy: true for operator-configured proxies. Workaround: patch matchesHostnameAllowlist in ssrf.ts to always return true for 127.0.0.1, and add NODE_TLS_REJECT_UNAUTHORIZED=0 to LaunchAgent.

PR fix notes

PR #60565: fix: Telegram media download fails when proxy is socks5

Description (problem / solution / changelog)

Summary

Telegram media downloads fail when using socks5:// proxy because the SSRF guard enforces pinned DNS checks that expect HTTP(S) proxy URLs. Since undici natively handles socks5:// proxies and the target media URL is always HTTPS, we disable the pinned DNS checks for media downloads by setting pinDns: false.

Changes

  • Added pinDns: false to fetchWithSsrFGuard call in src/media/fetch.ts for media downloads
  • This allows Telegram media to be downloaded through socks5:// proxies without SSRF pinned DNS validation errors

Testing

  • Ran vitest run src/media/fetch.test.ts - 7 tests passed
  • Ran vitest run extensions/telegram/src/fetch.test.ts - 22 tests passed

Fixes openclaw/openclaw#60472

Changed files

  • extensions/feishu/src/media.ts (modified, +3/-1)
  • extensions/ollama/index.ts (modified, +4/-1)
  • extensions/ollama/src/stream.ts (modified, +21/-2)

Code Example

security: blocked URL fetch (url-fetch) target=https://api.telegram.org/file/.../photos/file_113.jpg reason=Blocked hostname (not in allowlist): 127.0.0.1

---

{"subsystem":"security"} blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot.../photos/file_113.jpg reason=Blocked hostname (not in allowlist): 127.0.0.1
{"module":"telegram-auto-reply"} MediaFetchError: Failed to fetch media: Blocked hostname (not in allowlist): 127.0.0.1
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When channels.telegram.proxy is set to http://127.0.0.1:1082, Telegram media downloads fail with "Blocked hostname (not in allowlist): 127.0.0.1".

Steps to reproduce

  1. Set channels.telegram.proxy: "http://127.0.0.1:1082" in openclaw.json
  2. Send an image to the bot via Telegram DM
  3. Observe gateway log: blocked URL fetch reason=Blocked hostname (not in allowlist): 127.0.0.1

Expected behavior

The operator-configured proxy address is automatically exempt from SSRF hostname checks. Image downloads successfully.

Actual behavior

SSRF guard rejects the request because 127.0.0.1 (the proxy address) is not in hostnameAllowlist: ["api.telegram.org"]. Gateway log shows:

security: blocked URL fetch (url-fetch) target=https://api.telegram.org/file/.../photos/file_113.jpg reason=Blocked hostname (not in allowlist): 127.0.0.1

OpenClaw version

2026.4.2

Operating system

macOS 26.4 arm64

Install method

npm global

Model

claude-sonnet-4-6

Provider / routing chain

openclaw → local acc proxy → anthropic

Additional provider/model setup details

No response

Logs, screenshots, and evidence

{"subsystem":"security"} blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot.../photos/file_113.jpg reason=Blocked hostname (not in allowlist): 127.0.0.1
{"module":"telegram-auto-reply"} MediaFetchError: Failed to fetch media: Blocked hostname (not in allowlist): 127.0.0.1

Impact and severity

Affected: Users with http proxy configured for Telegram (workaround for Issue #60472 ) Severity: High (all media silently fails, no error surfaced to user) Frequency: Always (100% reproducible) Consequence: Cannot use http proxy for Telegram even as workaround for socks5 issue

Additional information

buildTelegramMediaSsrfPolicy() sets hostnameAllowlist: ["api.telegram.org"]. When undici sets up CONNECT tunnel through the proxy, assertExplicitProxyAllowed() checks the proxy IP against this allowlist. Suggested fix: auto-add proxy hostname to allowedHostnames, or set allowPrivateProxy: true for operator-configured proxies. Workaround: patch matchesHostnameAllowlist in ssrf.ts to always return true for 127.0.0.1, and add NODE_TLS_REJECT_UNAUTHORIZED=0 to LaunchAgent.

I'd like to work on a fix for this if the direction looks good to you.

extent analysis

TL;DR

Auto-adding the proxy hostname to the allowed hostnames or setting allowPrivateProxy to true for operator-configured proxies may resolve the issue.

Guidance

  • Review the buildTelegramMediaSsrfPolicy function to understand how the hostnameAllowlist is currently set and consider modifying it to include the proxy hostname.
  • Investigate the assertExplicitProxyAllowed check and its interaction with the hostnameAllowlist to determine the best approach for allowing the proxy IP.
  • Consider implementing a workaround by patching matchesHostnameAllowlist in ssrf.ts to always return true for 127.0.0.1, but be aware of potential security implications.
  • Evaluate the suggestion to set allowPrivateProxy to true for operator-configured proxies as a potential fix.

Example

No code example is provided due to the complexity of the issue and the need for a thorough review of the existing codebase.

Notes

The suggested fix and workaround may have security implications, and a thorough review of the code changes is necessary to ensure that the solution does not introduce new vulnerabilities.

Recommendation

Apply the workaround by patching matchesHostnameAllowlist in ssrf.ts to always return true for 127.0.0.1, but prioritize implementing a proper fix that auto-adds the proxy hostname to the allowed hostnames or sets allowPrivateProxy to true for operator-configured proxies to ensure a more secure and reliable solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The operator-configured proxy address is automatically exempt from SSRF hostname checks. Image downloads successfully.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING