Summary
_is_http_git_repo (in the target-type inference used by infer_target_type) issues an HTTP request from the host running Strix (not the sandbox) to probe whether a given URL is a git repository. It follows redirects by default and treats any response with status_code >= 400, specifically including 401, as "yes, this is a git repo."
Impact
Since the probe request originates from Strix's own host/infra rather than the sandboxed scan target, feeding Strix a URL that points at an internal/private service (behind auth, returning 401 for unauthenticated requests) causes Strix's host to make a real outbound network request to that internal resource. This is a classic SSRF pattern: whoever controls the string passed as a scan target (e.g. in an automated pipeline, CI integration, or any flow where a URL string reaches infer_target_type) can use Strix's infrastructure to probe internal network services that would otherwise be unreachable from outside.
Where
strix/interface/utils.py — _is_http_git_repo, used by infer_target_type for http(s) URLs with 2+ path segments.
requests.get(f"{url}/info/refs?service=git-upload-pack") with default allow_redirects=True.resp.status_code == 401 (and other >=400 codes) is treated as a positive "is a git repo" signal.
Suggested fix
- Don't treat
401/403/other auth-adjacent status codes as a positive git-repo signal — only a genuine 200 with the expected smart HTTP content-type/body should count.
- Set
allow_redirects=False (or validate the redirect target before following) to avoid the probe being used to reach arbitrary internal hosts via a redirect chain.
- Consider general SSRF hardening for any host-side probe against user/target-supplied URLs (private-IP/loopback/link-local denylist), consistent with the SSRF guard pattern already used elsewhere in scan targets.
Happy to help validate a fix — flagging this because we run Strix regularly against our own scan targets and want the host-side inference path to be safe against attacker-influenced URLs.
Summary
_is_http_git_repo(in the target-type inference used byinfer_target_type) issues an HTTP request from the host running Strix (not the sandbox) to probe whether a given URL is a git repository. It follows redirects by default and treats any response withstatus_code >= 400, specifically including401, as "yes, this is a git repo."Impact
Since the probe request originates from Strix's own host/infra rather than the sandboxed scan target, feeding Strix a URL that points at an internal/private service (behind auth, returning 401 for unauthenticated requests) causes Strix's host to make a real outbound network request to that internal resource. This is a classic SSRF pattern: whoever controls the string passed as a scan target (e.g. in an automated pipeline, CI integration, or any flow where a URL string reaches
infer_target_type) can use Strix's infrastructure to probe internal network services that would otherwise be unreachable from outside.Where
strix/interface/utils.py—_is_http_git_repo, used byinfer_target_typefor http(s) URLs with 2+ path segments.requests.get(f"{url}/info/refs?service=git-upload-pack")with defaultallow_redirects=True.resp.status_code == 401(and other>=400codes) is treated as a positive "is a git repo" signal.Suggested fix
401/403/other auth-adjacent status codes as a positive git-repo signal — only a genuine200with the expectedsmart HTTPcontent-type/body should count.allow_redirects=False(or validate the redirect target before following) to avoid the probe being used to reach arbitrary internal hosts via a redirect chain.Happy to help validate a fix — flagging this because we run Strix regularly against our own scan targets and want the host-side inference path to be safe against attacker-influenced URLs.