[diegosouzapw]

Closes GHSA-3f8g-pfh9-j687 (HIGH), GHSA-qv45-56jc-4wmj and GHSA-9m72-44hg-w32g, all reported by @skeletonsec. Targets release/v3.8.51.

All three are the same meta-pattern: a hardened path exists and a sibling path bypasses it. Each is fixed at the shared source rather than on the reported side, because "fix one copy" is what produced them.

---

1. provider_options.baseUrl sent the operator's key to a caller-chosen host

A caller with search scope could redirect the SaaS search builders, so the operator's third-party API key went wherever they named — key=/api_key= in the query for google-pse/searchapi, X-API-Key/Authorization for you.com/linkup/nimble/ollama — and the parsed response came back, making the same primitive an SSRF with readback.

My own GHSA-j7j4 fix is the one this slipped past. That fix added parseAndValidateNonMetadataUrl to this exact resolver, which blocks IMDS and nothing else. Against key exfiltration it does nothing: the attacker names their own public host. I treated a credential-destination problem as an SSRF problem.

And the j7j4 regression test missed it for a sharper reason worth recording: its fixture was searxng-search — the one keyless provider where redirecting the base URL leaks no credential. The test picked the benign case and passed.

The fix separates two sources that were being read through one call:

Source	Origin	Now
providerSpecificData	stored provider connection (credentials?.providerSpecificData) — operator	honored, block-metadata, loopback/LAN keeps working for self-hosted searxng
providerOptions	body.provider_options — caller	refused outright

No provider needs a per-request caller-chosen fetch target; the self-hosted story is served by the operator field. Operator config now also wins over a caller value instead of being shadowed by it.

Deliberate behaviour change: a caller sending provider_options.baseUrl gets an explicit refusal instead of a silently redirected request. Silently ignoring it would leave them believing the override applied.

The new suite iterates every keyed provider in the registry instead of one fixture, and asserts the registry still has keyed providers so it cannot degrade to zero coverage. search-baseurl-ssrf-guard.test.ts had one assertion encoding the wrong contract (caller-supplied loopback allowed) — moved to the operator source with the reasoning inline; the j7j4 metadata cases are untouched.

---

2. The error sanitizer had no sk- pattern

upstreamErrorPassthrough.ts recognized \bsk-[…]{8,} and refused verbatim passthrough for any upstream 4xx carrying it — correctly calling it a leak. The body then fell through to buildErrorBody → sanitizeErrorMessage → redactSensitiveErrorText, which had no such pattern. The layer that identified the credential handed it to a layer that could not see it, so Incorrect API key provided: sk-proj-… came back to the caller intact.

The passthrough file's comment claimed it "mirrors the vocabulary of redactSensitiveErrorText". The mirror had drifted — so the raw-token shapes now live once, in error.ts as RAW_CREDENTIAL_PATTERNS, and the passthrough layer imports them. Covers sk-/sk_, Google AIza… and three-segment JWTs, with upper-bounded quantifiers per AGENTS.md → PII learnings §1 (these run over untrusted upstream bodies).

The suite's last test is the anti-drift assertion: for every body the passthrough layer refuses as leaky, the fallback sanitizer must not return it unchanged. It also pins that ordinary prose containing "risk" or "task sk" is left alone.

---

3. The bifrost relay returned the sidecar's headers and body verbatim

The relay sends Authorization: Bearer ${BIFROST_API_KEY} to the sidecar, and new Headers(upstream.headers) handed back anything the sidecar echoed — that header, its own set-cookie, an x-api-key — to whoever holds the relay token. set-cookie matters as much as the credential: it is a session, and a browser would store it against our origin.

New shared stripSensitiveResponseHeaders(), built on the filterUpstreamResponseHeaderEntries helper that already sat in that file unused. Applied to both relay routes — the TS sibling copies headers wholesale too, so fixing only the reported one would leave the same hole next door plus a second copy waiting to drift. The bifrost route also normalizes non-2xx through parseUpstreamError + buildErrorBody + sanitizeErrorMessage, reaching parity with the sibling and Hard Rule #12.

---

Validation

TDD on all three, hermetic (env -u OMNIROUTE_API_KEY):

Suite	Result
search-baseurl-client-override-3f8g	23/23 (19 red before)
error-sanitizer-sk-key-qv45	9/9 (7 red before)
bifrost-relay-response-leak-9m72	6/6 (all red before)
sibling sweep (upstream-response-headers-strip, upstream-error-passthrough, search-baseurl-ssrf-guard, free-web-search, firecrawl-search-ssrf-guard + the three above)	91/91

• typecheck:core — exit 0, no output
• check:mutation-test-coverage --strict — ✓ No drift (the three new test files cover mutated modules; registered up front rather than after CI caught it, as in fix(authz): hard-gate every credential export and CLI-config write (GHSA-5926-2w35-7h4q) #12600)
• check:tracked-artifacts, check:lockfile — OK
• prettier --check clean; eslint — 37 errors across the touched files, exactly the 37 already frozen in eslint-suppressions.json for search.ts (34) and error.ts (3). This diff adds none.

One flake seen and discriminated: cursor-renewal's SIGTERM-timing case failed under the parallel sweep and passes 28/28 in isolation. Unrelated to these files.

⚠️ check:public-creds fails on this branch — the zcodeProtocol.ts base-red, fixed separately in #12615. Not touched by this diff.