This would fix #25215 for us — we run Clash/mihomo in fake-ip mode and had to pin an older version to work around the SSRF block. Clean approach exposing it as a config option. 👍

This fix is critical for many users in China who rely on Clash/mihomo with fake-ip mode. The web_fetch tool is completely unusable without this. Hope this can be merged soon! Thanks for the clean implementation.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

This fix is critical for many users in China who rely on Clash/mihomo with fake-ip mode. The web_fetch tool is completely unusable without this. Hope this can be merged soon! Thanks for the clean implementation.

Closing — issue #25215 is already being addressed by PR #26436. Deferring to avoid duplication.

These are different. The current issue affects the web_fetch tool, while #26436 only affects the discord channel.

These are different. The current issue affects the web_fetch tool, while #26436 only affects the discord channel.

These are different. The current issue affects the web_fetch tool, while #26436 only affects the discord channel.

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 SSRF and Firecrawl API key exfiltration via configurable firecrawl.baseUrl

Description

tools.web.fetch.firecrawl.baseUrl is now accepted as an arbitrary string in the runtime config schema, and is used to construct the Firecrawl API endpoint without SSRF protections or allowlisting.

Impact:

• SSRF/internal network access: If an attacker can influence runtime config (multi-tenant config, untrusted overrides, etc.), they can set firecrawl.baseUrl to internal hosts/IPs (e.g. http://127.0.0.1:..., http://169.254.169.254/...) and the server will fetch() it.
• Credential leakage: The request includes Authorization: Bearer <firecrawl apiKey>. If baseUrl is attacker-controlled, the Firecrawl API key will be sent to the attacker-controlled endpoint.

Vulnerable flow:

• input: tools.web.fetch.firecrawl.baseUrl (schema: z.string().optional(); no URL/host/scheme validation)
• sink: fetch(endpoint, { headers: { Authorization: ... }}) to the computed endpoint

Vulnerable code:

const endpoint = resolveFirecrawlEndpoint(params.baseUrl);
const res = await fetch(endpoint, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${params.apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify(body),
});

Recommendation

Treat firecrawl.baseUrl as security-sensitive.

Preferred (most secure): disallow arbitrary baseUrl

• Only allow the default SaaS host (e.g. api.firecrawl.dev) or a small administrator-controlled allowlist.

If custom base URLs must be supported (self-hosted Firecrawl):

1. Validate and normalize the URL at config-parse time:
   • require https: (or explicitly allow http: only for local/dev)
   • block localhost, link-local, private IP ranges, and other special-use ranges
   • optionally require hostnames to match an allowlist
2. Use the existing SSRF guard for the Firecrawl call as well.

Example hardening:

import { fetchWithSsrFGuard } from "../../infra/net/fetch-guard.js";

​// Validate baseUrl (https + allowlisted hostname) before use.
const endpoint = resolveFirecrawlEndpoint(validatedBaseUrl);

const { response } = await fetchWithSsrFGuard({
  url: endpoint,
  init: {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  },
  ​// ensure private/internal ranges remain blocked for this config-driven request
  policy: { dangerouslyAllowPrivateNetwork: false },
  auditContext: "firecrawl",
});

Additionally:

• If baseUrl is not on an allowlist, do not send the API key (fail closed) to prevent exfiltration.

Analyzed PR: #25258 at commit 41ab60b

_{Last updated on: 2026-03-09T13:51:05Z}

Closing this PR because the author has more than 10 active PRs in this repo. Please reduce the active PR queue and reopen or resubmit once it is back under the limit. You can close your own PRs to get back under the limit.

Greptile Summary

This PR fixes two distinct bugs: (1) ToolsWebFetchSchema used Zod's .strict() without declaring readability, firecrawl, or ssrfPolicy, causing those keys to be silently rejected at validation time with "Unrecognized key" errors; and (2) even though the SsrFPolicy.allowRfc2544BenchmarkRange field already existed in the SSRF guard, it was never wired through from the user config, making web_fetch unconditionally block the 198.18.0.0/15 benchmark range used by Clash/mihomo fake-ip mode.

• Added readability, ssrfPolicy, and firecrawl to ToolsWebFetchSchema in zod-schema.agent-runtime.ts, fixing the silent config rejection
• Wired fetch.ssrfPolicy.allowRfc2544BenchmarkRange from config through createWebFetchTool → runWebFetch → fetchWithSsrFGuard's policy parameter
• Added the ssrfPolicy field to ToolsConfig in types.tools.ts
• Added help text and UI labels for the new ssrfPolicy fields
• Added schema regression tests covering all three previously-broken config keys (ssrfPolicy, readability, firecrawl)
• Added unit tests for default-block, explicit-allow, and explicit-disable behaviors of the RFC 2544 range

Confidence Score: 5/5

• This PR is safe to merge — it fixes genuine config-rejection and SSRF-bypass bugs with appropriate opt-in gating, tests, and documentation.
• The fix is minimal and targeted: the Zod schema additions directly mirror the existing TypeScript types, the new runtime parameter is a simple boolean passed through an already-established policy interface, the opt-in flag is false by default so all existing SSRF protections remain unchanged, and new tests cover default, enabled, and disabled paths. No regressions are expected.
• No files require special attention.

_{Last reviewed commit: 41ab60b}

Greptile Summary

This PR fixes a real-world breakage where web_fetch was completely unusable for users running Clash/mihomo in fake-ip mode. It does this by exposing the pre-existing SsrFPolicy.allowRfc2544BenchmarkRange option all the way through the config/schema/runtime stack, and simultaneously fixes a latent schema bug where ssrfPolicy, readability, and firecrawl sub-configs were silently rejected at validation time due to ToolsWebFetchSchema using .strict() without declaring those fields.

• Schema fix: readability, ssrfPolicy, and firecrawl added to ToolsWebFetchSchema — closes the "Unrecognized key" validation errors.
• Runtime wiring: allowRfc2544BenchmarkRange is read from fetch.ssrfPolicy and passed through to fetchWithSsrFGuard; defaults safely to false so no existing SSRF behaviour changes.
• Type / help / labels: types.tools.ts, schema.help.ts, and schema.labels.ts updated consistently.
• Tests: SSRF test file covers default-block, explicit-allow, and explicit-deny paths; schema regression tests confirm all three newly-added sub-configs are accepted.
• Minor style note: The inline resolution of allowRfc2544BenchmarkRange (lines 773–780 of web-fetch.ts) uses a verbose "key" in obj guard chain that is equivalent to the simpler fetch?.ssrfPolicy?.allowRfc2544BenchmarkRange === true; the existing resolveFetch* helper pattern in the same file would be more consistent.

Confidence Score: 5/5

• Safe to merge — the change is opt-in, defaults to false, and all existing SSRF protections remain active unless explicitly overridden.
• The feature is a clearly scoped opt-in config flag with no change to default behaviour. The root-cause bug (missing fields in .strict() schema) is straightforwardly fixed, tests cover the critical paths, and the wiring is consistent with how the rest of fetchWithSsrFGuard is parameterised. The only finding is a verbose but logically correct inline expression that could be simplified.
• No files require special attention; the minor verbosity in src/agents/tools/web-fetch.ts lines 773–780 is style-only.

_{Last reviewed commit: 41ab60b}

Greptile Summary

This PR fixes a real regression where web_fetch was completely unusable for users running a local proxy (e.g. Clash/mihomo in fake-ip mode) after the RFC 2544 benchmark range (198.18.0.0/15) was added to the SSRF block list. It also fixes a separate but related issue where three fields — ssrfPolicy, readability, and firecrawl — were silently rejected at config validation time because ToolsWebFetchSchema used .strict() without declaring them.

Key changes:

• Schema fix: ToolsWebFetchSchema now includes readability, ssrfPolicy, and firecrawl — resolving the "Unrecognized key" errors on all three fields.
• New config option: tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange can be set to true to permit connections to 198.18.0.0/15; all other SSRF protections (loopback, private ranges, cloud-metadata hostnames, etc.) remain active.
• Test coverage: Three new SSRF tests cover the default-block, explicit-allow, and explicit-disable behaviour for RFC 2544 IP literals. Three new schema regression tests confirm all previously-rejected config keys are now accepted.
• Minor style inconsistency: allowRfc2544BenchmarkRange is computed inline inside the execute callback using a verbose runtime type-inspection pattern, while every other config-derived value (readabilityEnabled, firecrawlEnabled, userAgent, etc.) is pre-computed outside the callback. Now that ssrfPolicy is a properly typed field on WebFetchConfig, the check could be simplified to fetch?.ssrfPolicy?.allowRfc2544BenchmarkRange === true and extracted alongside the other const declarations.

Confidence Score: 4/5

• Safe to merge; the security boundary is preserved — only the RFC 2544 range is conditionally permitted and all other SSRF protections remain active.
• The schema fix and type additions are straightforward and well-tested. The SSRF wiring is correct end-to-end. The only deduction is a minor style inconsistency in how allowRfc2544BenchmarkRange is computed (inline in the execute callback using verbose runtime checks) compared to the established pattern for every other config value in the same function.
• src/agents/tools/web-fetch.ts — the inline allowRfc2544BenchmarkRange computation at lines 773–780 is inconsistent with the rest of the function's config-resolution pattern.

_{Last reviewed commit: 41ab60b}