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:

1. The target application must be running Werkzeug version 3.1.5 or below
2. The application must be running on a Windows operating system
3. 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:

 
 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:

 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

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