Child link relay forwards provider-specific caller credentials to Home #6032

Summary

The Child link data relay promises to replace every caller credential with the link admission key, but its denylist omits provider-specific credential headers used by built-in adapters. At merged dev 5744e7a19f, api-key (Azure) and x-goog-api-key (Google/AI Studio) survive Child → Home forwarding.

Reachable path

forwardLinkRequestHeaders/linkRequestHeaders lowercases only for denylist matching, then preserves every unlisted end-to-end header. After the tunnel ownership gate, relayLinkDataRequest sends those preserved headers to the Home listener while also attaching the link key. Header case is not a mitigation: the Headers implementation normalizes names.

A caller using the Child with an Azure or Google credential header can therefore send that provider credential across the machine boundary despite the documented contract that caller credentials stay on the Child and the Home serves requests with its own accounts.

Expected fix

Fail closed on credential-like caller header names before relay, at minimum covering the built-in api-key and x-goog-api-key forms in addition to the existing authorization/x-api-key/cookie/account headers. Preserve ordinary request metadata, hop-by-hop filtering, /v1/usage link-key behavior, and connection-nominated removal.

Required regression

Exercise mixed-case Api-Key and X-Goog-Api-Key through both the pure header helper and the actual relayed fetch; assert neither reaches Home and the link admission header remains the only credential.

This is a local paired-machine credential-boundary disclosure. It is not an unauthenticated internet path.