CVE-2026-27199: Werkzeug Path Traversal Vulnerability

CVE-2026-27199 Overview

CVE-2026-27199 is a denial of service vulnerability in Werkzeug, a comprehensive WSGI web application library for Python. The vulnerability exists in the safe_join function, which allows Windows device names as filenames if preceded by other path segments. This bypasses previous filtering added in response to GHSA-hgf8-39gv-g3f2, as the fix failed to account for multi-segment paths such as example/NUL.

When an application running on Windows uses the send_from_directory function (which relies on safe_join to safely serve files), a malicious request with a path ending in a special device name (such as NUL, CON, PRN, etc.) will cause the file to be opened successfully, but any read operation will hang indefinitely, resulting in a denial of service condition.

Critical Impact
Applications running Werkzeug on Windows are vulnerable to denial of service attacks where an attacker can cause application threads to hang indefinitely by requesting paths containing Windows special device names.

Affected Products

Werkzeug versions 3.1.5 and below
Python web applications using send_from_directory or safe_join functions on Windows
Flask applications serving static files on Windows servers

Discovery Timeline

2026-02-21 - CVE CVE-2026-27199 published to NVD
2026-02-23 - Last updated in NVD database

Technical Details for CVE-2026-27199

Vulnerability Analysis

The vulnerability stems from improper path name resolution for restricted file names (CWE-67) in Werkzeug's safe_join function. Windows reserves certain device names (such as NUL, CON, PRN, AUX, COM1-COM9, LPT1-LPT9) that have special behavior when accessed as files. When an application attempts to read from these device names, the operation may hang indefinitely or behave unexpectedly.

The safe_join function is designed to prevent directory traversal and other path-based attacks when serving files. A previous fix (GHSA-hgf8-39gv-g3f2) added filtering for Windows device names, but this filtering only checked single-segment paths. The vulnerability exists because safe_join accepts paths with multiple segments, allowing an attacker to bypass the filter by prepending a valid directory segment to the device name (e.g., example/NUL).

Root Cause

The root cause is insufficient input validation in the safe_join function's Windows device name filtering logic. The function did not properly validate all path segments for reserved Windows device names, only checking single-segment paths. This allowed multi-segment paths containing device names in non-initial positions to bypass the security check.

Attack Vector

An attacker can exploit this vulnerability remotely over the network without authentication. The attack requires:

The target application must be running Werkzeug version 3.1.5 or below
The application must be running on a Windows operating system
The application must use send_from_directory or safe_join to serve user-requested files

By sending a crafted HTTP request with a path like /files/example/NUL, the attacker can cause the application to attempt to read from a Windows device, resulting in the thread hanging indefinitely.

The security patch addresses this issue by checking all segments of multi-segment paths for Windows device names:

text

 
 Unreleased
 
+-   ``safe_join`` on Windows does not allow special devices names in
+    multi-segment paths. :ghsa:`29vq-49wr-vm6x`
+
 
 Version 3.1.5
 -------------

Source: GitHub Commit Update

Additionally, the patch includes updates to the security module:

python

 DEFAULT_PBKDF2_ITERATIONS = 1_000_000
 
 _os_alt_seps: list[str] = list(
-    sep for sep in [os.sep, os.path.altsep] if sep is not None and sep != "/"
+    sep for sep in [os.sep, os.altsep] if sep is not None and sep != "/"
 )
 # https://chrisdenton.github.io/omnipath/Special%20Dos%20Device%20Names.html
 _windows_device_files = {

Source: GitHub Commit Update

Detection Methods for CVE-2026-27199

Indicators of Compromise

HTTP requests containing Windows device names in path segments (e.g., /files/example/NUL, /static/dir/CON, /assets/PRN)
Application threads or processes hanging indefinitely without returning responses
Increased server resource consumption from blocked threads
Log entries showing requests for paths ending with NUL, CON, PRN, AUX, or COM1-COM9

Detection Strategies

Monitor web server access logs for requests containing Windows reserved device names in multi-segment paths
Implement application-level monitoring to detect threads that have been blocked for abnormally long periods
Deploy web application firewall (WAF) rules to block requests containing Windows device names in URL paths
Use runtime application self-protection (RASP) solutions to detect and block suspicious file access patterns

Monitoring Recommendations

Configure alerting for requests matching patterns like */NUL, */CON, */PRN, */AUX, */COM[1-9], */LPT[1-9] in web server logs
Monitor application health metrics for signs of thread pool exhaustion or increased response times
Review Werkzeug version in all deployed Python applications to identify vulnerable instances
Implement request timeout mechanisms to prevent indefinite hangs from affecting application availability

How to Mitigate CVE-2026-27199

Immediate Actions Required

Upgrade Werkzeug to version 3.1.6 or later immediately on all Windows deployments
Audit all Python web applications to identify those using safe_join or send_from_directory functions
Deploy WAF rules to block requests containing Windows device names as a temporary mitigation
Consider moving file-serving functionality to a dedicated static file server that is not affected by this vulnerability

Patch Information

The vulnerability has been fixed in Werkzeug version 3.1.6. The patch ensures that safe_join properly validates all segments of multi-segment paths for Windows special device names.

Fixed Version:3.1.6
Patch Commit:f407712fdc60a09c2b3f4fe7db557703e5d9338d
Release Notes:Werkzeug 3.1.6 Release
Security Advisory:GHSA-29vq-49wr-vm6x

Workarounds

Implement request filtering at the web server or reverse proxy level to block paths containing Windows device names
Add application-level validation to reject paths containing device names before passing them to safe_join or send_from_directory
Deploy the application on a non-Windows operating system where Windows device names are not interpreted specially
Use a dedicated static file serving solution instead of Werkzeug's file serving functions

bash

# Example nginx configuration to block Windows device names
location ~* /(nul|con|prn|aux|com[1-9]|lpt[1-9])(/|$) {
    return 403;
}