Werkzeug is a widely used WSGI utility library for Python web applications, providing functions such as safe_join to securely concatenate user-supplied paths with a base directory, mitigating directory traversal attacks. In versions 3.1.5 and earlier, safe_join attempts to block Windows special device names (like CON, NUL, PRN) to prevent misuse. However, the filtering logic was incomplete and did not account for device names appearing as the final segment in multi-segment paths (e.g., example/NUL). This oversight allows such paths to bypass the filter. When send_from_directory uses safe_join to serve files from user-specified paths on Windows, it may open these special device names as if they were files. Reading from these device files causes the application to hang indefinitely, effectively causing a denial of service (DoS). The vulnerability is tracked as CWE-67 (Improper Neutralization of Windows Device Names). Exploitation requires no authentication or user interaction and can be triggered remotely via crafted HTTP requests. The issue was addressed in Werkzeug 3.1.6 by improving the filtering logic to correctly handle device names in all path segments.

This vulnerability primarily enables denial of service attacks against web applications running Werkzeug on Windows platforms. An attacker can craft requests that cause the application to hang indefinitely when attempting to read special device names treated as files. This can degrade service availability, potentially leading to resource exhaustion or application downtime. Since Werkzeug is a foundational library used by many Python web frameworks, the impact can cascade to numerous applications and services relying on it. Although the vulnerability does not allow code execution or data disclosure, the resulting DoS can disrupt business operations, degrade user experience, and increase operational costs. Organizations with Windows-based Python web servers are particularly at risk. The lack of known exploits in the wild suggests limited current exploitation, but the ease of triggering the issue remotely without authentication increases the risk of opportunistic attacks.

The primary mitigation is to upgrade Werkzeug to version 3.1.6 or later, where the vulnerability is fixed. For organizations unable to upgrade immediately, a temporary workaround is to implement input validation on user-supplied paths to reject or sanitize any segments matching Windows special device names (CON, NUL, PRN, AUX, COM1-COM9, LPT1-LPT9) regardless of their position in the path. Additionally, monitoring application logs for repeated requests containing suspicious device names can help detect exploitation attempts. Deploying web application firewalls (WAFs) with custom rules to block requests targeting these device names can provide further protection. Finally, consider isolating Windows-based web servers or limiting exposure to untrusted networks to reduce attack surface until patches are applied.