fix: keep benchmark-range DNS blocked for provider fetches

[qqzhangyanhua]

Summary

• Custom provider baseURL values are fetched by the AI SDK, which does not use ssrfSafeFetch or the connect-time SSRF dispatcher.
• Validation therefore keeps rejecting a hostname whose DNS answer is in 198.18.0.0/15. Allowing that answer would let a user-controlled name pass the check and later connect to a reserved address, including Clash/mihomo fake-ip space when that range is actually reachable.
• Literal addresses in that range, and connect-time answers in that range, stay blocked as well.

Test plan

• pnpm --filter @agent-native/core exec vitest run src/extensions/url-safety.spec.ts src/agent/engine/provider-endpoint-validation.spec.ts (36 passed)
• A DNS answer of 198.18.0.12 is rejected by validateProviderBaseUrl
• A connect-time answer of 198.18.0.5 after a public preflight fails with EAI_BLOCKED

[builder-io-integration]

Builder reviewed your changes and found 1 potential issue 🔴

Review Details

Incremental Code Review Summary

The latest commit correctly restores benchmark-range blocking in both the shared URL safety logic and provider endpoint validation. The two earlier review comments covering those explicit exemptions have been resolved. The added tests also cover rejecting a 198.18.0.0/15 preflight answer and blocking the same range at connect time.

Risk: High — this remains security-sensitive SSRF and DNS validation code.

New Finding

• 🔴 High: Provider endpoint validation still performs only a one-time DNS preflight, while the validated URL is later sent through the AI SDK’s normal fetch path without the connect-time SSRF dispatcher. A hostname can resolve publicly during validation and rebind to loopback, metadata, or another private address before the model request; the actual provider transport must use the guarded dispatcher or pin and authorize the validated address.

No UI code changed, so browser verification is not applicable.

🧪 Browser testing: Skipped — PR only modifies backend/security utility code and tests, no UI impact

[builder-io-integration]

🔴 Protect provider requests against DNS rebinding

This performs a one-time DNS preflight, but the validated URL is later fetched by the AI SDK without the connect-time SSRF dispatcher. The hostname can resolve publicly here and rebind to loopback, metadata, or another private address before the model request; use the guarded dispatcher for the provider transport or pin and authorize the resolved address.

Additional Info

This is distinct from the resolved benchmark-range exemption comments: those comments were fixed by restoring the default closed behavior.

[qqzhangyanhua]

The connect-time DNS-rebinding gap you're flagging is real, but it's pre-existing and broader than this PR: validateProviderBaseUrl()'s one-time preflight was never backed by ssrfSafeFetch/createSsrfSafeDispatcher on the actual provider request path, for any custom endpoint — not just the 198.18.0.0/15 case this PR touches. Confirmed unchanged on main at aba8c52 before this PR's diff.

Keeping this PR scoped to the fake-ip false positive (both prior findings on that are fixed and tested). Tracking the connect-time guard for provider requests separately in #5610.

[steve8708]

Thanks for the PR, and for opening #5610 for the broader DNS-rebinding issue. I agree that should stay a separate follow-up.

For #5608, could you align the PR with the behavior we want to merge? The current diff adds tests and comments, while the 198.18.0.0/15 block already exists in the base, so runtime behavior is unchanged. If the intent is to lock in the fail-closed behavior, please frame it as regression coverage and update the title and changeset. If the goal is to fix the fake-IP false positive, please include the runtime change and tests that preserve the SSRF protection.