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.
I found a credential propagation issue in the repository file-content fetch path.
In the current
mainbranch,/chat/completions/streamacceptsrepo_url,filePath,type, andtoken. WhenfilePathis present, the handler callsget_file_content(...). For a GitHub Enterprise style URL,get_github_file_content()builds an API URL from the suppliedrepo_urland calls:If
tokenis supplied, the initial request includesAuthorization: token .... Requests strips that original header on a cross-host redirect, but because the call uses Requests defaults,trust_envremains enabled. Requests can then refillAuthorizationfrom the server process.netrcfor the redirect target.I reproduced this against commit
16f35a0fc0284e99b7963bbf4e8585e9957e2fe1with the documented Poetry install. The resolved versions included:The reproduction used only loopback servers and fake canary credentials. A request to
/chat/completions/streamwith a controlled GitHub Enterprise stylerepo_urlandfilePath=README.mdcaused the file-content fetch to follow a redirect. The controlled redirect target received:Decoded:
The original
Authorization: token ...header was not leaked. This issue is specifically that server-side.netrccredentials can be attached to an attacker-influenced redirect target during repository file fetching.Impact depends on the server process having a matching
.netrcentry 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:
requests.Session()withtrust_env = Falsefor repository and file-content fetches that use user-supplied repository URLs.