Werkzeug safe_join() allows Windows special device namesGHSA-29vq-49wr-vm6x
Fix: pallets/werkzeug@f407712GHSA-29vq-49wr-vm6x is a CWE-67 vulnerability in werkzeug. A fix is available for werkzeug — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-29vq-49wr-vm6x.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
werkzeugReal-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
Werkzeug is a comprehensive WSGI web application library. Versions 3.1.5 and below, the safe_join function allows Windows device names as filenames if preceded by other path segments. This was previously reported as GHSA-hgf8-39gv-g3f2, but the added filtering failed to account for the fact that safe_join accepts paths with multiple segments, such as example/NUL. The function send_from_directory uses safe_join to safely serve files at user-specified paths under a directory. If the application is running on Windows, and the requested path ends with a special device name, the file will be opened successfully, but reading will hang indefinitely. This issue has been fixed in version 3.1.6.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | werkzeug | all versions | 3.1.6pip install --upgrade 'werkzeug==3.1.6' |
Affected Products
werkzeugpalletsprojectsDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for werkzeug, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update werkzeug to 3.1.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-29vq-49wr-vm6x 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.
Frequently Asked Questions
Is GHSA-29vq-49wr-vm6x in your dependencies?
Find it across PyPI, including transitive dependencies.