GHSA-w75w-9qv4-j5xj
dbt-common's commonprefix() doesn't protect against path traversal
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
dbt-common🐍dbt-commonReal-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
Impact
What kind of vulnerability is it? Who is impacted?
A path traversal vulnerability exists in dbt-common's safe_extract() function used when extracting tarball archives. The function uses os.path.commonprefix() to validate that extracted files remain within the intended destination directory. However, commonprefix() compares paths character-by-character rather than by path components, allowing a malicious tarball to write files to sibling directories with matching name prefixes.
For example, when extracting to /tmp/packages, a crafted tarball could write files to /tmp/packagesevil/ by exploiting the character-based prefix matching.
This vulnerability affects users who:
- Install dbt packages from untrusted sources
- Process tarball archives through dbt-common's extraction utilities
The practical risk is limited because:
- Exploitation requires a malicious tarball to be processed
- File writes are restricted to sibling directories with matching prefixes (not arbitrary paths)
- Packages from trusted sources (dbt Hub) are not affected
This is similar to CVE-2026-1703 in pip, which had a CVSS score of 3.9 (Low).
Patches
Has the problem been patched? What versions should users upgrade to?
Fixed in dbt-common version 1.37.3 & 1.34.2, and patched for dbt-core 1.11.7 and 1.10.20 releases.
The fix replaces os.path.commonprefix() with os.path.commonpath(), which correctly compares paths by their components rather than characters.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
- Only install dbt packages from trusted sources (official dbt Hub, verified git repositories)
- Avoid installing packages from untrusted URLs or unverified third parties
- Review package contents before installation when sourcing from external locations
Resources
Are there any links users can visit to find out more?
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): https://cwe.mitre.org/data/definitions/22.html
- CVE-2026-1703 (similar vulnerability in pip): https://nvd.nist.gov/vuln/detail/CVE-2026-1703
- pip fix PR #13777: https://github.com/pypa/pip/pull/13777
- Python documentation on
commonpathvscommonprefix: https://docs.python.org/3/library/os.path.html#os.path.commonpath
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | dbt-common | all versions | 1.34.2 |
| 🐍PyPI | dbt-common | ≥ 1.35.0&&< 1.37.3 | 1.37.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for dbt-common. 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 dbt-common to 1.34.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w75w-9qv4-j5xj 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-w75w-9qv4-j5xj 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-w75w-9qv4-j5xj. 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-w75w-9qv4-j5xj in your dependencies?
O3 detects GHSA-w75w-9qv4-j5xj across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.