Repository file fetch follows redirects with environment netrc auth enabled

I found a credential propagation issue in the repository file-content fetch path.

In the current main branch, /chat/completions/stream accepts repo_url, filePath, type, and token. When filePath is present, the handler calls get_file_content(...). For a GitHub Enterprise style URL, get_github_file_content() builds an API URL from the supplied repo_url and calls:

requests.get(api_url, headers=headers)

If token is supplied, the initial request includes Authorization: token .... Requests strips that original header on a cross-host redirect, but because the call uses Requests defaults, trust_env remains enabled. Requests can then refill Authorization from the server process .netrc for the redirect target.

I reproduced this against commit 16f35a0fc0284e99b7963bbf4e8585e9957e2fe1 with the documented Poetry install. The resolved versions included:

requests==2.32.5
aiohttp==3.13.1
tqdm==4.67.1

The reproduction used only loopback servers and fake canary credentials. A request to /chat/completions/stream with a controlled GitHub Enterprise style repo_url and filePath=README.md caused the file-content fetch to follow a redirect. The controlled redirect target received:

Authorization: Basic TElCMkFQUF9FTkRQT0lOVF9SRUZJTExfTE9HSU46TElCMkFQUF9FTkRQT0lOVF9SRUZJTExfUEFTU1dPUkQ=

Decoded:

LIB2APP_ENDPOINT_REFILL_LOGIN:LIB2APP_ENDPOINT_REFILL_PASSWORD

The original Authorization: token ... header was not leaked. This issue is specifically that server-side .netrc credentials can be attached to an attacker-influenced redirect target during repository file fetching.

Impact depends on the server process having a matching .netrc entry and on a repository/file request that reaches this redirect path. In that configuration, an untrusted repository API response can make the DeepWiki backend send environment credentials to the redirect target.

Suggested mitigations:

• Use a requests.Session() with trust_env = False for repository and file-content fetches that use user-supplied repository URLs.
• Consider disallowing cross-host redirects, or at least restricting redirects to the expected repository API host.
• Avoid applying server environment credentials to repository URLs supplied by users.