Werkzeug is a widely used WSGI web application library that provides utilities for safely serving files through its safe_join and send_from_directory functions. In versions 3.1.5 and earlier, the safe_join function attempts to prevent directory traversal and unsafe file access by sanitizing user-supplied paths. However, it fails to properly handle Windows device names (e.g., NUL, CON, PRN) when these device names appear as the final segment of a multi-segment path, such as example/NUL. The filtering logic was insufficient because it did not consider that safe_join accepts paths with multiple segments, allowing these special device names to bypass checks. When send_from_directory uses safe_join to serve files, it can open these device files on Windows systems. Attempting to read from such device files causes the application to hang indefinitely, leading to a denial-of-service condition. This vulnerability is identified as CWE-67 (Improper Neutralization of Input During Pathname Resolution) and has a CVSS 4.0 score of 6.3, indicating medium severity. Exploitation requires no privileges or user interaction and can be triggered remotely by sending crafted requests that specify paths ending with Windows device names. The issue was fixed in Werkzeug version 3.1.6 by improving path validation to correctly handle multi-segment paths containing device names.

This vulnerability can cause denial-of-service (DoS) conditions in web applications using vulnerable Werkzeug versions on Windows platforms. Attackers can remotely trigger the application to hang indefinitely by requesting paths that end with special Windows device names, potentially disrupting service availability. This can impact web services, APIs, and any applications relying on Werkzeug's file-serving utilities, leading to downtime and degraded user experience. While it does not directly expose sensitive data or allow code execution, the DoS impact can be leveraged in targeted attacks against critical web infrastructure. Organizations with high availability requirements or those serving Windows-based environments are particularly at risk. The vulnerability does not require authentication or user interaction, increasing the attack surface. No known exploits are reported in the wild yet, but the ease of triggering the hang condition makes it a credible threat.

The primary mitigation is to upgrade Werkzeug to version 3.1.6 or later, where the vulnerability is fixed. If immediate upgrading is not feasible, organizations should implement strict input validation on user-supplied paths to block requests containing Windows device names such as NUL, CON, PRN, AUX, COM1-COM9, and LPT1-LPT9, especially when these appear as the last path segment. Additionally, consider deploying web application firewalls (WAFs) with custom rules to detect and block suspicious path requests targeting device names. Monitoring application logs for repeated requests with device name patterns can help identify attempted exploitation. Running Werkzeug-based applications on non-Windows platforms can also reduce risk, as the issue specifically affects Windows device name handling. Finally, ensure that application timeout settings are configured to prevent indefinite hangs in case of unexpected file reads.