Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Feature request: add ssrfPolicy config for web_fetch (like browser has) [2 pull requests, 1 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#49444•Fetched 2026-04-08 00:55:12
View on GitHub
Comments
0
Participants
1
Timeline
13
Reactions
0
Author
NemoAirNemoAir
Participants
NemoAirNemoAir
Timeline (top)
referenced ×10cross-referenced ×3

Root Cause

The browser tool works fine because it has ssrfPolicy.dangerouslyAllowPrivateNetwork / allowRfc2544BenchmarkRange config options. But web_fetch has no such config, forcing users to patch source code.

Fix Action

Fix / Workaround

The browser tool works fine because it has ssrfPolicy.dangerouslyAllowPrivateNetwork / allowRfc2544BenchmarkRange config options. But web_fetch has no such config, forcing users to patch source code.

Current Workaround

Patching withStrictGuardedFetchMode() in all bundled JS files to inject allowRfc2544BenchmarkRange: true into the policy. This needs to be re-applied after every openclaw update.

PR fix notes

PR #51407: feat(web-fetch): add ssrfPolicy.allowRfc2544BenchmarkRange config option

Description (problem / solution / changelog)

Summary

This PR adds a scoped ssrfPolicy config block to web_fetch, allowing users behind fake-IP proxy tools (Clash TUN, Surge, etc.) to enable RFC 2544 benchmark range access.

Problem

OpenClaw's SSRF guard blocks RFC 2544 benchmark range (198.18.0.0/15), which is used by fake-IP proxy tools like Clash, Surge, and Mihomo. This causes web_fetch to fail for users behind these proxies.

Solution

Add a configuration option:

{
  "tools": {
    "web": {
      "fetch": {
        "ssrfPolicy": {
          "allowRfc2544BenchmarkRange": true
        }
      }
    }
  }
}

Changes

  • src/config/zod-schema.agent-runtime.ts: add ssrfPolicy to ToolsWebFetchSchema
  • src/config/types.tools.ts: add TypeScript type and JSDoc for ssrfPolicy
  • src/agents/tools/web-fetch.ts:
    • Add ssrfPolicy to WebFetchRuntimeParams
    • Pass policy to fetchWithWebToolsNetworkGuard
    • Include ssrfPolicy in cache key to prevent cross-policy cache bypass

Related Issues

Closes #25322, #27597, #48080, #48961, #49377, #49444

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/.generated/config-baseline.json (modified, +21/-1)
  • docs/.generated/config-baseline.jsonl (modified, +4/-2)
  • src/agents/tools/web-fetch.ssrf.test.ts (modified, +26/-0)
  • src/agents/tools/web-fetch.ts (modified, +17/-1)
  • src/config/schema.base.generated.ts (modified, +9/-0)
  • src/config/schema.help.ts (modified, +4/-0)
  • src/config/schema.labels.ts (modified, +3/-0)
  • src/config/schema.test.ts (modified, +16/-0)
  • src/config/types.tools.ts (modified, +5/-0)
  • src/config/zod-schema.agent-runtime.ts (modified, +6/-0)

PR #61830: feat(web-fetch): add ssrfPolicy.allowRfc2544BenchmarkRange config option

Description (problem / solution / changelog)

Summary

  • Problem: the underlying SSRF / guarded-fetch stack already supports allowRfc2544BenchmarkRange, but web_fetch had no scoped config surface to pass that policy through for fake-IP proxy environments such as Clash TUN, Mihomo, and Surge.
  • Why it matters: in those environments, normal public destinations can resolve into 198.18.0.0/15, making web_fetch unusable even though the underlying network guard already has the necessary benchmark-range allowance capability.
  • What changed: added an opt-in tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange config path, threaded it through runtime/schema handling and web_fetch, and added regression coverage for default-blocked behavior, explicit opt-in behavior, and cache isolation across policy variants.
  • What did NOT change (scope boundary): no default behavior change, no broader SSRF relaxation, and no private-network allowlist expansion beyond this scoped web_fetch opt-in.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

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

Linked Issue/PR

  • Related #25322
  • Related #27597
  • Related #48080
  • Related #48961
  • Related #49377
  • Related #49444

Root Cause / Regression History (if applicable)

  • Root cause: web_fetch did not expose an existing lower-level SSRF policy capability at the tool config layer.
  • Missing guardrail: no regression test covered “blocked by default, allowed only when explicitly enabled, and isolated across cache variants”.
  • Prior context: this behavior has been reported repeatedly in Clash/Surge/Mihomo fake-IP environments.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file:
    • src/agents/tools/web-fetch.ssrf.test.ts
    • src/config/schema.test.ts
    • src/config/schema.base.generated.test.ts
  • Scenario the test should lock in:
    • default blocked behavior
    • explicit opt-in behavior
    • cache isolation between strict and permissive policy variants
    • schema/generated config alignment

User-visible / Behavior Changes

  • New opt-in config:
    • tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange
  • Default behavior remains unchanged.
  • When enabled, web_fetch can access fake-IP-proxied public destinations resolving into 198.18.0.0/15.

Security Impact (required)

  • New permissions/capabilities? (Yes/No) Yes
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:
    • This is a narrow web_fetch-only opt-in for one special-use range.
    • Default behavior remains fail-closed.
    • Cache keys now include ssrfPolicy so permissive results do not bleed into stricter instances.

Repro + Verification

Environment

  • OS: WSL2 Ubuntu
  • Runtime/container: local worktree
  • Relevant config:
    • tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange: true

Steps

  1. Run web_fetch against a URL resolving into 198.18.0.0/15 with default config.
  2. Confirm it is blocked.
  3. Enable tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange.
  4. Re-run the same request.
  5. Confirm it succeeds and does not reuse permissive cache state for stricter tool instances.

Expected

  • Default config blocks RFC 2544 targets.
  • Explicit opt-in allows them for web_fetch.
  • Cache remains policy-specific.

Actual

  • Verified locally with targeted schema/runtime/SSRF regression coverage.

Evidence

  • Targeted tests passing after the patch
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified:
    • runtime config accepts the new path
    • generated schema stays aligned
    • default blocked behavior remains intact
    • explicit opt-in works
    • cache isolation works
  • Not verified:
    • full repo-wide pnpm check
    • unrelated global CI failures outside the touched web_fetch / schema surface

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) Optional new config only
  • Migration needed? (Yes/No) No

Risks and Mitigations

  • Risk: users may enable the exemption unnecessarily.
    • Mitigation: explicit opt-in, narrow scope, default-off.
  • Risk: cache reuse could widen behavior across policy variants.
    • Mitigation: ssrfPolicy is now part of the cache key.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/tools/web-fetch.ssrf.test.ts (modified, +38/-6)
  • src/agents/tools/web-fetch.ts (modified, +7/-1)
  • src/config/schema.base.generated.ts (modified, +25/-0)
  • src/config/schema.help.ts (modified, +4/-0)
  • src/config/schema.labels.ts (modified, +3/-0)
  • src/config/schema.test.ts (modified, +16/-0)
  • src/config/types.tools.ts (modified, +5/-0)
  • src/config/zod-schema.agent-runtime.ts (modified, +6/-0)

Code Example

"browser": {
  "ssrfPolicy": {
    "allowPrivateNetwork": true,
    "allowRfc2544BenchmarkRange": true,
    "allowedHostnames": ["example.local"]
  }
}

---

"tools": {
  "web": {
    "fetch": {
      "ssrfPolicy": {
        "allowRfc2544BenchmarkRange": true
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Problem

browser tool has a configurable ssrfPolicy in openclaw.json:

"browser": {
  "ssrfPolicy": {
    "allowPrivateNetwork": true,
    "allowRfc2544BenchmarkRange": true,
    "allowedHostnames": ["example.local"]
  }
}

However, web_fetch has no equivalent config — it hardcodes strict SSRF mode via withStrictGuardedFetchMode(), which passes no policy to fetchWithSsrFGuard().

Use Case

Home network with Surge (macOS proxy) acting as DHCP + DNS for all LAN devices. Surge uses fake-IP mode, resolving all domains to the RFC 2544 benchmark range (198.18.0.0/15). This causes web_fetch to block every URL that goes through Surge DNS, even for legitimate public websites.

The browser tool works fine because it has ssrfPolicy.dangerouslyAllowPrivateNetwork / allowRfc2544BenchmarkRange config options. But web_fetch has no such config, forcing users to patch source code.

Current Workaround

Patching withStrictGuardedFetchMode() in all bundled JS files to inject allowRfc2544BenchmarkRange: true into the policy. This needs to be re-applied after every openclaw update.

Proposed Solution

Add ssrfPolicy config under tools.web.fetch, mirroring the browser config schema:

"tools": {
  "web": {
    "fetch": {
      "ssrfPolicy": {
        "allowRfc2544BenchmarkRange": true
      }
    }
  }
}

The implementation would pass this policy through fetchWithWebToolsNetworkGuard() → fetchWithSsrFGuard() → resolvePinnedHostnameWithPolicy(), which already supports the full policy object.

Environment

  • OpenClaw 2026.3.13
  • Home LAN with Surge proxy (fake-IP mode, 198.18.0.0/15)
  • Linux host (gateway mode: local)

extent analysis

Fix Plan

To fix the issue, we need to add the ssrfPolicy configuration to the web_fetch tool. Here are the steps:

  • Add the following configuration to openclaw.json:
"tools": {
  "web": {
    "fetch": {
      "ssrfPolicy": {
        "allowPrivateNetwork": true,
        "allowRfc2544BenchmarkRange": true,
        "allowedHostnames": ["example.local"]
      }
    }
  }
}
  • Update the withStrictGuardedFetchMode() function to pass the ssrfPolicy to fetchWithSsrFGuard():
const ssrfPolicy = config.tools.web.fetch.ssrPolicy;
return fetchWithSsrFGuard(url, options, ssrfPolicy);
  • Update the fetchWithWebToolsNetworkGuard() function to pass the ssrfPolicy to fetchWithSsrFGuard():
const ssrfPolicy = config.tools.web.fetch.ssrPolicy;
return fetchWithSsrFGuard(url, options, ssrfPolicy);

Verification

To verify that the fix worked, you can test the web_fetch tool with a URL that was previously blocked by the SSRF policy. For example:

web_fetch http://example.com

If the fix is successful, the web_fetch tool should be able to fetch the URL without being blocked by the SSRF policy.

Extra Tips

  • Make sure to update the openclaw.json configuration file with the correct ssrfPolicy settings for your environment.
  • If you are using a Surge proxy, make sure to configure the allowRfc2544BenchmarkRange setting to true to allow access to the RFC 2544 benchmark range.

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#prompt issue#agent setup#task chaining#parallel task

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 Feature request: add ssrfPolicy config for web_fetch (like browser has) [2 pull requests, 1 participants]