Skip to content

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

Open
boat2moon wants to merge 3 commits intoopenclaw:mainfrom
boat2moon:feat/web-fetch-ssrf-policy
Open

feat(web-fetch): add ssrfPolicy.allowRfc2544BenchmarkRange config option#40354
boat2moon wants to merge 3 commits intoopenclaw:mainfrom
boat2moon:feat/web-fetch-ssrf-policy

Conversation

@boat2moon
Copy link
Copy Markdown

@boat2moon boat2moon commented Mar 8, 2026

Summary

Add a new tools.web.fetch.ssrfPolicy configuration block that lets operators opt-in to allowing the RFC 2544 benchmark IP range (198.18.0.0/15) through the SSRF guard.

Problem

When OpenClaw runs behind proxy tools that use fake-IP DNS resolution (e.g. Clash TUN mode commonly used in China), hostnames resolve to addresses in the 198.18.0.0/15 range. The default SSRF guard correctly identifies these as special-use addresses and blocks every web_fetch request, making the tool completely unusable.

The browser tool already has ssrfPolicy.dangerouslyAllowPrivateNetwork for similar scenarios, but web_fetch had no equivalent escape hatch.

Solution

Add a scoped ssrfPolicy config to the web fetch tool:

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

Changes

File Change
src/config/zod-schema.agent-runtime.ts Add ssrfPolicy to ToolsWebFetchSchema
src/config/types.tools.ts Add TypeScript type + JSDoc
src/agents/tools/web-fetch.ts Add resolveSsrfPolicy(), wire policy through to fetchWithWebToolsNetworkGuard

Design notes

  • Opt-in only: The RFC 2544 range remains blocked by default.
  • Minimal surface: Only allowRfc2544BenchmarkRange is exposed; the broader dangerouslyAllowPrivateNetwork is intentionally not included to limit security impact.
  • Consistent pattern: Follows the same SsrFPolicy mechanism already used by withTrustedWebToolsEndpoint and the browser tool.

Closes #25322
Ref #25258

When users run behind proxy tools that use fake-IP DNS resolution
(e.g. Clash TUN mode mapping hostnames into the 198.18.0.0/15 range),
the default SSRF guard blocks every web_fetch request because those
addresses fall into the RFC 2544 benchmark reserved range.

This change adds a new tools.web.fetch.ssrfPolicy config block with
an allowRfc2544BenchmarkRange boolean. Setting it to true lets
web_fetch bypass the benchmark-range check, restoring normal operation
for users behind such proxies.

Changes:
- config/zod-schema.agent-runtime.ts: add ssrfPolicy to ToolsWebFetchSchema
- config/types.tools.ts: add TypeScript type + JSDoc for ssrfPolicy
- agents/tools/web-fetch.ts: wire ssrfPolicy through to fetchWithWebToolsNetworkGuard

Closes openclaw#25322
@openclaw-barnacle openclaw-barnacle bot added agents Agent runtime and tooling size: S labels Mar 8, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 8, 2026

Greptile Summary

This PR adds a scoped ssrfPolicy.allowRfc2544BenchmarkRange configuration option to the web_fetch tool, allowing operators running behind proxy tools that use fake-IP DNS resolution (e.g. Clash TUN mode) to opt in to allowing the RFC 2544 benchmark range through the SSRF guard. The schema, TypeScript type, and runtime wiring are all consistent with the existing SsrFPolicy mechanism used elsewhere in the codebase.

Key finding:
The implementation correctly integrates the ssrfPolicy into the runtime flow and the SSRF guard is properly invoked, but the module-level FETCH_CACHE does not include ssrfPolicy in its key. This creates a cache-based SSRF bypass risk in multi-agent deployments where different agents have different ssrfPolicy configurations. An agent instance with allowRfc2544BenchmarkRange: true can cache a successful response from an otherwise-blocked address; a second instance with the default (blocking) policy will return that cached response without the SSRF guard ever running.

Confidence Score: 2/5

  • Safe to merge in single-agent deployments, but carries a cache-based SSRF bypass risk in multi-agent setups where different agents have different ssrfPolicy configurations.
  • The feature itself is narrowly scoped and correctly integrated with the SSRF guard at runtime. However, the module-level FETCH_CACHE at line 47 uses a key that omits ssrfPolicy, allowing cached responses from a permissive policy instance to be served to a restrictive policy instance without re-running the guard. This is a real security issue in multi-agent deployments, though the risk is theoretical in typical single-config production environments.
  • src/agents/tools/web-fetch.ts — specifically the cache key construction at lines 531–533 and the resolveSsrfPolicy call placement inside execute (line 776) rather than at tool creation time.

Comments Outside Diff (1)

  1. src/agents/tools/web-fetch.ts, line 531-533 (link)

    Cache key omits ssrfPolicy, enabling SSRF bypass via cache

    FETCH_CACHE is module-level and shared across all web_fetch tool instances in the same process. When an instance configured with allowRfc2544BenchmarkRange: true successfully fetches a URL that resolves to an address in the RFC 2544 benchmark range, the response is stored in the cache under a key of fetch:<url>:<extractMode>:<maxChars> — with no policy component.

    A second tool instance with the default (blocking) policy would look up the same key, find the cached entry, and return it without ever running the SSRF guard. In multi-agent deployments where different agents carry different configurations, this entirely bypasses the protection the policy is meant to enforce.

    Include the effective ssrfPolicy in the cache key to prevent cross-instance cache poisoning. Additionally, for consistency with other config values (e.g., readabilityEnabled), consider resolving ssrfPolicy at tool creation time (outside execute, alongside other config state in createWebFetchTool).

Last reviewed commit: 25871f3

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 25871f3223

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines 555 to +558
url: params.url,
maxRedirects: params.maxRedirects,
timeoutSeconds: params.timeoutSeconds,
policy: params.ssrfPolicy,
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Isolate web_fetch cache by SSRF policy

This change makes web_fetch behavior depend on params.ssrfPolicy, but the shared FETCH_CACHE key in runWebFetch is still only URL/extractMode/maxChars. In environments with multiple tool instances/configs (or after toggling config at runtime), a fetch performed with allowRfc2544BenchmarkRange: true can populate cache and then be returned to a caller where that flag is false, effectively bypassing the new SSRF guard until cache expiry; the cache key should include policy state (or policy-sensitive requests should not be cached).

Useful? React with 👍 / 👎.

…che hits

Address review feedback from Codex and Greptile: when ssrfPolicy differs
between tool instances, a cached response from a permissive policy could
be served to a restrictive one, bypassing the SSRF guard.

Append ':rfc2544' suffix to the cache key when allowRfc2544BenchmarkRange
is enabled, ensuring cache isolation between policy configurations.
Extend browser tool SSRF policy to support the allowRfc2544BenchmarkRange
option, matching the web_fetch tool. This allows operators behind fake-IP
DNS proxies (e.g. Clash TUN mode) to unblock browser navigation for
hostnames that resolve to the RFC 2544 benchmark range (198.18.0.0/15).

Changes:
- types.browser.ts: add field to BrowserSsrFPolicyConfig
- zod-schema.ts: add field to browser ssrfPolicy validation
- browser/config.ts: read and pass through in resolveBrowserSsrFPolicy
- schema.help.ts + schema.labels.ts: add help text and label
- config.test.ts + navigation-guard.test.ts: add test coverage
- pr-body.md: update PR description to cover both tools
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agents Agent runtime and tooling size: S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Add ssrfPolicy config support for web_fetch tool (parity with browser)

1 participant