CVE-2026-102598 in Werkzeug
Summary
by MITRE • 09/29/2026
Werkzeug is a comprehensive WSGI web application library. Prior to 3.1.9, the safe_join function used by send_from_directory can allow a NUL: special-device path because safe_join checks the Windows device name without first removing an empty NTFS ADS marker. The trigger is that an application runs on Windows with NTFS and serves a user-specified path ending in a special device name such as NUL:. The attack mechanism is that a requested path ends in a Windows special device name with an empty ADS marker. The impact is that the special device opens successfully and the file read hangs indefinitely. This issue is fixed in version 3.1.9.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within the Werkzeug library, specifically affecting versions prior to 3.1.9, represents a critical path traversal and resource exhaustion flaw rooted in improper input validation on Windows systems utilizing NTFS file structures. As a comprehensive WSGI web application library, Werkzeug provides utilities for handling HTTP requests and serving static files, with send_from_directory being a common function used by developers to safely serve files from a specified directory based on user-supplied paths. The core technical flaw lies in the implementation of the safe_join utility function, which is designed to prevent path traversal attacks by ensuring that constructed file paths remain within the intended base directory. However, this validation logic fails to account for specific Windows NTFS features related to Alternate Data Streams (ADS) and special device names when processing input on Windows platforms.
The operational mechanism of this vulnerability exploits a gap in how the safe_join function processes path components ending with empty ADS markers followed by Windows special device names such as NUL:. In standard operation, an attacker can craft a request where the user-specified file path ends with a sequence that includes an empty NTFS Alternate Data Stream marker immediately preceding a special device name like NUL: or CON:. The safe_join function checks for dangerous patterns in the final component of the path but does not first strip or neutralize the empty ADS marker. Consequently, the validation logic perceives the path as potentially valid because it focuses on the visible filename components rather than resolving the underlying NTFS stream semantics that are interpreted by the operating system kernel during file access operations.
When an application running on a Windows server with NTFS formatting attempts to serve such a crafted request using send_from_directory, the operating system interprets the path as referring to a special device rather than a regular file. Special devices like NUL: in Windows act as sinks for data; writing to them discards all data without error, but reading from them behaves differently depending on context and implementation details within the I/O subsystem. In this specific scenario involving Werkzeug's file serving mechanism, attempting to read from these special device paths causes the underlying system call or library function to hang indefinitely rather than returning an empty result or a standard end-of-file signal. This behavior transforms what might have been a simple path traversal attempt into a severe denial of service condition.
The impact of this vulnerability is primarily characterized by resource exhaustion and application unavailability for affected users. Because the file read operation hangs indefinitely, it consumes server threads or asynchronous event loop handles associated with that specific request without releasing them. In high-traffic environments or applications handling many concurrent requests, an attacker can exploit this flaw to exhaust available worker processes or connection slots, effectively rendering the web service unavailable to legitimate users. This constitutes a denial of service attack vector that does not require authentication and relies solely on crafting malicious HTTP GET requests with specific path parameters targeting Windows-based deployments of vulnerable Werkzeug versions.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to properly sanitize or validate user-supplied input before using it in file system operations. It also relates to CWE-409 Improper Handling of Unexpectedly Complex Data Structure due to the failure to account for NTFS Alternate Data Stream semantics during path resolution. In terms of offensive security frameworks such as MITRE ATT&CK, this technique falls under T1567 Exploit Public-Facing Application and specifically leverages techniques associated with resource exhaustion or denial of service via application layer vulnerabilities. The exploitation does not involve code execution but rather the manipulation of system I/O behavior to disrupt availability services.
Mitigation for this vulnerability requires immediate upgrading of the Werkzeug library to version 3.1.9 or later, where the safe_join function has been patched to correctly handle empty NTFS ADS markers and special device names on Windows systems. Developers should ensure that their deployment pipelines enforce strict dependency management practices to prevent regression to vulnerable versions. For organizations unable to patch immediately due to legacy constraints, temporary mitigations may include implementing a reverse proxy or web application firewall rule set that inspects incoming URL paths for patterns resembling empty ADS markers followed by special device names such as NUL:, CON, PRN, AUX, and similar Windows reserved identifiers. Additionally, restricting the file serving functionality to only allow alphanumeric characters and standard path separators can reduce the attack surface, although this may impact legitimate use cases requiring complex filenames. Regular security audits of web application codebases that utilize dynamic file serving should include specific checks for cross-platform compatibility issues related to NTFS features on Windows servers.