Problem
src/review/content-lane/safe-url.ts's isSafeEndpointUrl (lines 112-123) doc comment says it "additionally permits secure WebSocket endpoints (wss:, ws:)" — but ws: is not secure; it's the plaintext counterpart to wss:, the same relationship http:/https: has in this same module, where http: is explicitly rejected by the sibling isSafeHttpUrl.
isSafeEndpointUrl is used at src/review/content-lane/registry-logic.ts:496 to validate a submitted base-layer (subtensor RPC) endpoint URL, so a registry surface can currently be accepted with an unencrypted ws:// endpoint even though every other URL type this gate validates requires TLS.
This is not itself an SSRF bypass — the host/IP private-range guard applies identically to both ws: and wss: — it's a transport-security/spec-consistency gap: the module's own stated intent ("secure WebSocket endpoints") doesn't match what the code actually allows.
Area
src/review/content-lane/safe-url.ts (isSafeEndpointUrl, lines 112-123) — inside the SSRF-guard module.
Proposal
Drop ws: from isSafeEndpointUrl's allowed-protocol list (matching isSafeHttpUrl's http: rejection), or, if there's a real reason to keep allowing it (e.g. self-hosted operators pointing at a local unencrypted RPC node), re-justify it explicitly in the doc comment rather than mislabeling it "secure." A maintainer should make this call — it's a real behavior decision (tighten vs. document), not purely mechanical.
Deliverables
Resources
src/review/content-lane/safe-url.ts (lines 112-123, isSafeEndpointUrl; compare isSafeHttpUrl for the https:-only precedent)src/review/content-lane/registry-logic.ts:496 (the call site this affects)
Boundaries
Scoped to this one protocol-allowlist inconsistency — not a broader audit of safe-url.ts.
maintainer-only — this is inside the SSRF-guard module's protocol allowlist; even though the code change itself is small, it's a security-boundary decision (tighten vs. explicitly document) that warrants a security-aware reviewer, not a first-pass contributor task.
Problem
src/review/content-lane/safe-url.ts'sisSafeEndpointUrl(lines 112-123) doc comment says it "additionally permits secure WebSocket endpoints (wss:,ws:)" — butws:is not secure; it's the plaintext counterpart towss:, the same relationshiphttp:/https:has in this same module, wherehttp:is explicitly rejected by the siblingisSafeHttpUrl.isSafeEndpointUrlis used atsrc/review/content-lane/registry-logic.ts:496to validate a submitted base-layer (subtensor RPC) endpoint URL, so a registry surface can currently be accepted with an unencryptedws://endpoint even though every other URL type this gate validates requires TLS.This is not itself an SSRF bypass — the host/IP private-range guard applies identically to both
ws:andwss:— it's a transport-security/spec-consistency gap: the module's own stated intent ("secure WebSocket endpoints") doesn't match what the code actually allows.Area
src/review/content-lane/safe-url.ts(isSafeEndpointUrl, lines 112-123) — inside the SSRF-guard module.Proposal
Drop
ws:fromisSafeEndpointUrl's allowed-protocol list (matchingisSafeHttpUrl'shttp:rejection), or, if there's a real reason to keep allowing it (e.g. self-hosted operators pointing at a local unencrypted RPC node), re-justify it explicitly in the doc comment rather than mislabeling it "secure." A maintainer should make this call — it's a real behavior decision (tighten vs. document), not purely mechanical.Deliverables
ws:removed from the allowed-protocol list, withisSafeHttpUrl-equivalent test coverage confirming it's now rejected; or the doc comment corrected to accurately describe whyws:is intentionally allowed.Resources
src/review/content-lane/safe-url.ts(lines 112-123,isSafeEndpointUrl; compareisSafeHttpUrlfor thehttps:-only precedent)src/review/content-lane/registry-logic.ts:496(the call site this affects)Boundaries
Scoped to this one protocol-allowlist inconsistency — not a broader audit of
safe-url.ts.maintainer-only — this is inside the SSRF-guard module's protocol allowlist; even though the code change itself is small, it's a security-boundary decision (tighten vs. explicitly document) that warrants a security-aware reviewer, not a first-pass contributor task.