GHSA-xg9w-vg3g-6m68
GuardDog Path Traversal Vulnerability Leads to Arbitrary File Overwrite and RCE
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
guarddogReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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
pathparameter 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
- Attacker creates malicious wheel with path traversal filenames
- Uploads to PyPI or distributes directly
- Package scan:
guarddog pypi scan malicious-pkg - GuardDog downloads and extracts the package
- Malicious files written to arbitrary locations
- Code execution could be achieved
Impact
Impact depends on how GuardDog is running and under which environment.
Critical Scenarios
-
Immediate Code Execution
- Write to
~/.bashrc→ executes on next shell - Write to
~/.profile→ executes on login
- Write to
-
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
- Write to
and more...
Credits
Reported by: Charbel (dwbruijn)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | guarddog | all versions | 2.7.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for guarddog. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update guarddog to 2.7.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xg9w-vg3g-6m68 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xg9w-vg3g-6m68 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-xg9w-vg3g-6m68. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xg9w-vg3g-6m68 in your dependencies?
O3 detects GHSA-xg9w-vg3g-6m68 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.