Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix web_fetch blocked by SSRF guard for 198.18.0.0/15 (fake-IP) while web_search works fine [1 pull requests, 2 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#48961•Fetched 2026-04-08 00:50:30
View on GitHub
Comments
2
Participants
2
Timeline
16
Reactions
0
Author
the3asicthe3asic
Participants
Hollychou924Hollychou924the3asicthe3asic
Timeline (top)
referenced ×10cross-referenced ×4commented ×2

Error Message

Blocked: resolves to private/internal/special-use IP address

Every domain resolves to 198.18.x.x (Surge's fake-IP), which triggers the SSRF guard.

Root Cause

web-fetch.ts:532 calls fetchWithWebToolsNetworkGuard() without passing policy or useEnvProxy:

// web-fetch.ts L532 — no policy, no useEnvProxy
const result = await fetchWithWebToolsNetworkGuard({
  url: params.url,
  maxRedirects: params.maxRedirects,
  timeoutSeconds: params.timeoutSeconds,
  init: { headers: { ... } },
});

Meanwhile, web-search.ts:926 uses withTrustedWebToolsEndpoint() which injects allowRfc2544BenchmarkRange: true + useEnvProxy: true:

// web-search.ts L926 — works correctly
return withTrustedWebToolsEndpoint({ url, ... }, async ({ response }) => { ... });

The WEB_TOOLS_TRUSTED_NETWORK_SSRF_POLICY in web-guarded-fetch.ts already has the correct policy:

const WEB_TOOLS_TRUSTED_NETWORK_SSRF_POLICY: SsrFPolicy = {
  dangerouslyAllowPrivateNetwork: true,
  allowRfc2544BenchmarkRange: true,
};

Fix Action

Fixed

PR fix notes

PR #48972: fix(web-fetch): allow RFC 2544 trusted benchmark endpoints

Description (problem / solution / changelog)

Summary

  • Problem: web_fetch used the trusted web-tools SSRF policy, but that policy only allowed private-network endpoints and forgot the RFC 2544 benchmark range (198.18.0.0/15) that some hosted fake-IP setups use.
  • Why it matters: web_search already allowed that range for trusted providers, but web_fetch still failed on the same infrastructure with remote IP 198.18.x.x is blocked.
  • What changed: extended WEB_TOOLS_TRUSTED_NETWORK_SSRF_POLICY to also allow the RFC 2544 benchmark range, and added focused regression coverage for a trusted web_fetch call resolving to 198.18.0.42.
  • What did NOT change (scope boundary): no changes to default SSRF blocking for untrusted fetches, no broader allowlist expansion beyond the existing trusted web-tools policy.

Change Type

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #48961

User-visible / Behavior Changes

Trusted web_fetch requests now accept RFC 2544 benchmark-range fake IPs (for example 198.18.x.x) the same way trusted web_search requests already do.

Test plan

  • corepack pnpm exec vitest run src/agents/tools/web-fetch.ssrf.test.ts
  • corepack pnpm exec oxfmt --check src/agents/tools/web-guarded-fetch.ts src/agents/tools/web-fetch.ssrf.test.ts
  • corepack pnpm exec oxlint src/agents/tools/web-guarded-fetch.ts src/agents/tools/web-fetch.ssrf.test.ts

Changed files

  • src/agents/tools/web-fetch.ssrf.test.ts (modified, +13/-0)
  • src/agents/tools/web-guarded-fetch.ts (modified, +1/-0)

Code Example

Blocked: resolves to private/internal/special-use IP address

---

// web-fetch.ts L532 — no policy, no useEnvProxy
const result = await fetchWithWebToolsNetworkGuard({
  url: params.url,
  maxRedirects: params.maxRedirects,
  timeoutSeconds: params.timeoutSeconds,
  init: { headers: { ... } },
});

---

// web-search.ts L926 — works correctly
return withTrustedWebToolsEndpoint({ url, ... }, async ({ response }) => { ... });

---

const WEB_TOOLS_TRUSTED_NETWORK_SSRF_POLICY: SsrFPolicy = {
  dangerouslyAllowPrivateNetwork: true,
  allowRfc2544BenchmarkRange: true,
};
RAW_BUFFERClick to expand / collapse

Bug Description

web_fetch fails with SSRF blocked error when running behind a transparent proxy that uses fake-IP DNS (e.g., Surge Enhanced Mode on macOS). The same URLs work fine with web_search.

Environment

  • macOS (Mac mini as network gateway)
  • Surge Enhanced Mode (transparent proxy with fake-IP DNS)
  • All DNS queries return virtual IPs in 198.18.0.0/15 (RFC 2544 benchmark range)

Error

Blocked: resolves to private/internal/special-use IP address

Every domain resolves to 198.18.x.x (Surge's fake-IP), which triggers the SSRF guard.

Root Cause

web-fetch.ts:532 calls fetchWithWebToolsNetworkGuard() without passing policy or useEnvProxy:

// web-fetch.ts L532 — no policy, no useEnvProxy
const result = await fetchWithWebToolsNetworkGuard({
  url: params.url,
  maxRedirects: params.maxRedirects,
  timeoutSeconds: params.timeoutSeconds,
  init: { headers: { ... } },
});

Meanwhile, web-search.ts:926 uses withTrustedWebToolsEndpoint() which injects allowRfc2544BenchmarkRange: true + useEnvProxy: true:

// web-search.ts L926 — works correctly
return withTrustedWebToolsEndpoint({ url, ... }, async ({ response }) => { ... });

The WEB_TOOLS_TRUSTED_NETWORK_SSRF_POLICY in web-guarded-fetch.ts already has the correct policy:

const WEB_TOOLS_TRUSTED_NETWORK_SSRF_POLICY: SsrFPolicy = {
  dangerouslyAllowPrivateNetwork: true,
  allowRfc2544BenchmarkRange: true,
};

Suggested Fix

Either:

  1. Have web-fetch.ts use withTrustedWebToolsEndpoint() like web-search.ts does
  2. Or pass policy: { allowRfc2544BenchmarkRange: true } and useEnvProxy: true to fetchWithWebToolsNetworkGuard()

Related Issues

  • #38986
  • #25086
  • #26945

extent analysis

Fix Plan

To resolve the SSRF blocked error, we need to modify the web-fetch.ts file to either use withTrustedWebToolsEndpoint() or pass the correct policy and useEnvProxy to fetchWithWebToolsNetworkGuard(). Here are the steps:

  • Option 1: Use withTrustedWebToolsEndpoint()
    1. Import withTrustedWebToolsEndpoint from the relevant module.
    2. Wrap the fetchWithWebToolsNetworkGuard call with withTrustedWebToolsEndpoint.
    3. Example:

import { withTrustedWebToolsEndpoint } from './web-tools';

// ...

const result = await withTrustedWebToolsEndpoint({ url: params.url }, async ({ response }) => { const init = { headers: { ... } }; return fetchWithWebToolsNetworkGuard({ url: params.url, maxRedirects: params.maxRedirects, timeoutSeconds: params.timeoutSeconds, init, }); });

* **Option 2: Pass policy and `useEnvProxy` to `fetchWithWebToolsNetworkGuard()`**
  1. Define the policy with `allowRfc2544BenchmarkRange` set to `true`.
  2. Pass the policy and `useEnvProxy: true` to `fetchWithWebToolsNetworkGuard`.
  3. Example:
  ```typescript
const policy = {
  allowRfc2544BenchmarkRange: true,
};

const result = await fetchWithWebToolsNetworkGuard({
  url: params.url,
  maxRedirects: params.maxRedirects,
  timeoutSeconds: params.timeoutSeconds,
  init: { headers: { ... } },
  policy,
  useEnvProxy: true,
});

Verification

To verify that the fix worked, test the web_fetch function with a URL that previously triggered the SSRF blocked error. The request should now succeed without being blocked.

Extra Tips

  • Make sure to test both options and choose the one that best fits your use case.
  • If you're using a transparent proxy with fake-IP DNS, ensure that the allowRfc2544BenchmarkRange policy is set to true to avoid SSRF blocked errors.

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…
#api#ssr#installation#tensor shape#autograd error#generation error#database connection#vector store#embedding generation

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix web_fetch blocked by SSRF guard for 198.18.0.0/15 (fake-IP) while web_search works fine [1 pull requests, 2 comments, 2 participants]