Cycle 296 - MCP credential-forwarding / path-authority-injection vein (Apify CVE-2026-50143 class)

Date: 2026-07-02. WALK-with-lessons + 1 staged candidate (IBM mcp-context-forge, Medium).

What worked (bank as positive methodology)

Highest-signal target class for the Apify path-authority-injection vein = MCP proxies / gateways / aggregators / registries. They structurally hold a downstream credential AND take the outbound host from config / a registry row / a redirect. Wrappers of a single fixed API (github.com, api.apify.com) are lower signal because the base host is constant. Fan-out audited 8 repos; the two live leads were both gateways/registries (IBM contextforge, agentic-community mcp-gateway-registry).
Incomplete-fix tell: a blanket security promise applied per-call-site. IBM contextforge shipped + DOCUMENTED "All HTTP clients now have follow_redirects=False" naming Gateway Health Checks + SSE Gateway Connections. That promise is enforced by editing each client individually -> grep the guard string (follow_redirects=False), then find the client that OMITS it. One SSE health-check client (gateway_service.py:4286) was missed. Documented-blanket-guard + per-site-application = reliable incomplete-fix generator. This satisfies the Gate-6 by-design carve-out (breaks a promise built + applied elsewhere).
Auth-type asymmetry on redirect. httpx/requests strip ONLY Authorization + Cookie on a cross-origin redirect. Custom credential-header schemes (authheaders -> X-API-Key) are FORWARDED. So a redirect-follow bug that looks benign for Bearer auth is a live credential leak for custom-header auth. Always enumerate the auth TYPES a target supports and test the non-Authorization ones separately. (Cousin of the template escape-layer operator-coverage lesson: one layer neutralizes some tokens, not all.)

What didn't work / walked (bank as negative)

mcphub (samanhappy) WALK: exact sink files (ssrf.ts/assertSafeUrl) are the subject of merged security PR #937 / GHSA-9wx9-prgc-gmjr; the maintainer DELIBERATELY scoped the guard to internal-IP-only, leaving public-host registration in-scope BY DESIGN. Residual public-host credential passthrough = by-design + saturated (4+ advisories on the repo). Do not force.
metamcp, mcpjungle, TS SDK, reference servers, mcpo, microsoft/mcp-gateway CLEAR: credential+URL are single-owner co-located, or the SSE endpoint has a same-origin guard (sse.ts:214-216 endpoint.origin !== url.origin throw), or no credential is attached (fetch server = User-Agent only), or the host is fixed cluster-DNS. The MCP TS SDK's SSE same-origin check is the reference mitigation for this exact class - use it as the "what a correct fix looks like" control.

Saturation caution (bank)

agentic-community/mcp-gateway-registry is SATURATING: the SSRF class on the twin agent-card path is OPEN issue #1282 (identical IMDS threat model), credential-forward-to-attacker-upstream is stated in #1271, cred-reuse in #966. 3+ adjacent open issues = deprioritize per saturated-surface doctrine. Only the edit-repoint cross-principal credential-theft framing on the auth_credential_encrypted health/scan sinks is genuinely undisclosed-by-name - narrow, dup-risky. Documented as cautious secondary, no PoC built.

Reusable disclosure-gate move

For an incomplete-fix, the key Gate-0 question is not "is the class disclosed" (it usually is - that's why there's a fix) but "is the SPECIFIC missed call-site named in any open issue/PR, or already patched at HEAD?" Read the current HEAD source of the exact file:line to confirm the omission still lives. That is what separated this (live) from a $0 dup.

Cycle 297 addendum (same vein, 2nd confirmed finding + saturation map)

2nd CONFIRMED finding: docker/mcp-gateway (pkg/mcp/remote.go) - remote MCP credential headers (OAuth Bearer + secret headers) forwarded to an attacker-controlled redirect host. Self-hosted Go PoC, CLEAN pass. Same ROOT as IBM contextforge: an own-built HTTP client (not SDK-delegated) misses a documented/sibling redirect guard.

New reusable primitive banked: transport-layer header injection defeats stdlib redirect stripping

When a Go client injects Authorization/secret headers inside a custom http.RoundTripper (re-applied per hop) instead of on the *http.Request, Go's stdlib cross-host Authorization-strip NEVER fires (it only strips headers present on the request object). So the credential is re-added on the redirect hop and leaks. Grep tell: headerRoundTripper/RoundTrip that does req.Header.Set("Authorization"...) + an http.Client with NO CheckRedirect. This is a STRONGER variant than the httpx case (cycle296) because it defeats even the Authorization strip, not just custom-header leakage. Also re-confirmed the auth-type asymmetry both ways: Go stdlib strips Authorization cross-host but NEVER strips custom headers (X-API-Key) - so secret headers leak regardless of how they're set.

The productive sub-niche is now precise

The vein's remaining yield is NOT in SDK-delegated proxies (both official SDKs ship the SSE same-origin guard; single-principal CLI proxies fail precondition #2). It IS in multi-tenant gateways/runners that build their OWN outbound HTTP client for the credentialed connect, especially where the project shipped a documented blanket redirect/SSRF guard and applied it per-call-site (leaving the primary credentialed client uncovered). Confirmed hits: IBM contextforge (httpx follow_redirects), docker/mcp-gateway (Go headerRoundTripper). Weaker sibling: stacklok/toolhive registry client (operator-configured host = weaker precondition, saturated class). Saturated/credit-only: langflow MCP path, fastmcp, mcp-atlassian, mcp-gateway-registry, Unla.

The winning move both cycles: find the documented/shared guard (follow_redirects=False / CheckRedirect / SameHostRedirectPolicy / an SSRF-validation helper), then enumerate every http client construction and diff which route through the guard vs which build a raw client. The raw credentialed one is the finding.