Werkzeug EUVD-2026-88980

Exploitation requires ALL of: (1) the application is deployed on Windows on an NTFS filesystem; (2) it uses Werkzeug's send_from_directory / safe_join to serve a path derived from user input; and (3) the attacker controls a trailing path segment so it can be a Windows special device name (NUL, CON, AUX, PRN, COM1-9, LPT1-9) followed by an empty NTFS ADS marker, e.g. 'NUL:'. This is the AT:P requirement in the CVSS 4.0 vector - the flaw is unreachable on Linux/macOS deployments (the common Flask production case) and unreachable if the app does not serve user-controlled filenames. No authentication or user interaction is required (PR:N/UI:N) once those deployment conditions hold. The limiting factors are the Windows-plus-NTFS-plus-user-path preconditions, which sharply narrow the realistically vulnerable population.

This is a genuine but low-severity availability issue, not a high-risk emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L) scores 6.3 but the only impact is VA:L - a request-handling hang with zero confidentiality or integrity effect, so the 'Information Disclosure' tag in the input is factually wrong (this is a denial-of-service, not a data leak). The critical de-rating signal is AT:P (attack requirement present): exploitation is possible ONLY when the application runs on Windows with an NTFS filesystem AND serves user-controlled paths through send_from_directory/safe_join. Werkzeug/Flask is overwhelmingly deployed on Linux in production, where this bug is not reachable, so real-world exposure is a narrow slice of an otherwise huge install base. No EPSS score, no CISA KEV listing, and no public exploit code were provided - this is a coordinated GitHub Security Advisory (GHSA-g6x2-hccm-hh4m) with a confirmed fix, indicating responsible disclosure rather than observed attacks. No conflicting vector/description signals: the network attack vector is consistent with an HTTP-served path, and the local-device hang is the described mechanism. Exploitation status: no public exploit identified at time of analysis.

A Windows-hosted Flask/Werkzeug app that serves user-requested filenames from a directory (e.g. via send_from_directory) receives an HTTP request whose path component ends in a Windows special device name with an empty NTFS ADS marker, such as 'NUL:'. safe_join fails to reject it because it checked the device name before stripping the ADS ':' marker, so the app opens the special device and the read hangs indefinitely, tying up the worker; repeating this can exhaust the worker pool and deny service. No public proof-of-concept was provided in the intelligence.