* fix(agents): scope provider SSRF trust by origin
* fix(provider): preserve explicit private-network deny
* docs(provider): document exact-origin SSRF trust
* test(provider): cover exact-origin SSRF edges
* docs(provider): align local model private-origin guidance
* refactor(ssrf): keep policy merging in infra
* test(ssrf): cover exact-origin trust through guard
* test(ssrf): block sibling private-origin redirects
* fix(provider): keep loopback trust origin-scoped
* fix(provider): block metadata origin trust
* fix(ssrf): keep metadata rebinding blocked
* fix(ssrf): block cloud metadata origins
* fix(ssrf): block ipv6 metadata origins
* fix(ssrf): block embedded metadata origins
* test(ssrf): cover embedded link-local metadata
* test(provider): cover custom anthropic proxy classification
* test(provider): widen transport policy mock
* test(plugin-sdk): assert metadata-IP allowedOrigins entries are rejected
Plugin authors can construct an SsrFPolicy that lists any well-formed
http(s) origin in allowedOrigins. The abuse-resistance lives one layer
deeper, in resolvePinnedHostnameWithPolicy's metadata/link-local block.
Add an SDK-level smoke test asserting that contract directly:
- AWS/Alibaba IMDS IPv4 literals, GCP metadata canonical hostname,
IPv6 ULA metadata literal, and non-metadata link-local IPv4 entries
build a policy via ssrfPolicyFromHttpBaseUrlAllowedOrigin and are
then rejected at resolvePinnedHostnameWithPolicy.
- DNS rebinding from a trusted private DNS origin to a metadata IP is
rejected even when the request hostname is origin-trusted.
This would fail if the SDK helper or resolveSsrFPolicyForUrl ever
short-circuited past the metadata block.
* chore(docs): regenerate baselines after upstream rebase
upstream/main moved between rebases; the merged source state for the
PR's `src/config/schema.help.ts` change and the upstream plugin-sdk
surface changes both produce different hashes than the committed
baselines, so `config:docs:check` and `plugin-sdk:api:check` would fail.
Regenerated via `pnpm config:docs:gen` + `pnpm plugin-sdk:api:gen` on
Crabbox; both baselines verified with their respective `--check`
generators.
* test(plugin-sdk): assert SSRF blocked error class
* fix(lint): satisfy exact-origin PR lint rules
* docs: clarify custom provider origin trust
* chore(docs): refresh plugin sdk api baseline
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* style: update chat layout and spacing for improved UI consistency
- Adjusted margin and padding for .chat-thread and .content--chat to enhance layout.
- Consolidated CSS selectors for better readability and maintainability.
- Introduced new test for log parsing functionality to ensure accurate message extraction.
* UI: polish agent skills, chat images, and sidebar status
* test: stabilize vitest helper export types
* UI: address review feedback on agents refresh and chat styles
* test: update outbound gateway client fixture values
* test: narrow shared ip fixtures to IPv4
Telegram's API and file servers resolve to IPs in the 198.18.0.0/15
range (RFC 2544 benchmarking range). The SSRF filter was blocking these
addresses because ipaddr.js classifies them as 'reserved', and the
filter also had an explicit RFC2544_BENCHMARK_PREFIX check that blocked
them unconditionally.
Fix: exempt 198.18.0.0/15 from the 'reserved' range block in
isBlockedSpecialUseIpv4Address(). Other 'reserved' ranges (TEST-NET-2,
TEST-NET-3, documentation prefixes) remain blocked. The explicit
RFC2544_BENCHMARK_PREFIX check is repurposed as the exemption guard.
Closes#24973
Kaspre