CVE-2026-21860 Windows device name flaw in Werkzeug safe_join fixed in 3.1.5

A subtle but important security gap in Werkzeug’s path-joining logic has resurfaced: attackers can craft filenames that exploit Windows’ legacy device-name semantics and cause web servers using Werkzeug’s safe_join/send_from_directory helpers to hang. This vulnerability, tracked as CVE-2026-21860, affects Werkzeug versions prior to 3.1.5 and was patched in the 3.1.5 release; the issue is platform‑specific to Windows and stems from incomplete filtering of reserved device names when those names are disguised with compound extensions or trailing whitespace. (github.com)

Background / Overview​

Werkzeug is the underlying WSGI utility library that powers many Python web frameworks and tools. It provides helpers for request/response handling, URL utilities, and file-serving helpers such as safe_join and send_from_directory, which are commonly used by higher-level frameworks (for example, Flask) to safely resolve and serve user-specified files from a directory. The purpose of safe_join is to canonicalize and validate path components so an attacker cannot escape a designated directory via path traversal.
On Windows, however, there is a long‑standing OS semantic: certain reserved device names—CON, PRN, AUX, NUL, COM1..COM9, LPT1..LPT9, and related variants—are treated as special device aliases rather than ordinary file names. Windows historically accepts these names with extensions (for example, NUL.txt) or trailing periods/spaces in many APIs, and those names map to device behavior (e.g., NUL discards writes), not to regular files. The Windows documentation explicitly warns developers to avoid these reserved names and notes that they are treated specially even when followed by extensions. That cross‑platform quirk is central to this class of bugs.

What CVE-2026-21860 actually is​

• The vulnerability is a logic/validation gap in Werkzeug’s safe_join() implementation: path segments that end with Windows device names can bypass the library’s checks when the device name is followed by compound extensions (for example, CON.txt.html) or trailing spaces, or when additional special names were not included in the original filter. When such a path is passed to send_from_directory, Werkzeug will resolve the path and allow the application to open the resulting path as if it were a regular file. On Windows, attempting to read these device-like filenames can cause the call to hang indefinitely, producing a denial‑of‑service condition for the worker handling that request. (github.com)
• The flaw is platform‑specific: only applications running on Windows or Windows-based containers are affected. The vulnerability does not permit arbitrary file disclosure or code execution by itself; the primary impact is availability (server worker hang/DoS). Public scanning services and package advisory databases rate the issue Medium (CVSS around 5.3–6.3 depending on scoring version).

How this slipped through: an iterative patch history​

This CVE is not the project’s first encounter with Windows device-name pitfalls. An earlier advisory and fix (published as CVE-2025-66221 and released in Werkzeug 3.1.4) added device-name filtering, but that initial patch was incomplete: it did not account for compound extensions like CON.txt.html, trailing spaces, and some additional special-name variants. CVE-2026-21860 documents the residual gap and the fix that followed in Werkzeug 3.1.5. The project continued to iterate on hardening of these checks with subsequent patches (for example, follow-up advisories and releases that further tightened checks across multi-segment paths), demonstrating that this class of bug is tricky because Windows’ semantics are both legacy and permissive in ways many cross‑platform libraries do not anticipate.

---

The technical mechanics — step by step​

What Windows does with device names​

Windows maintains legacy device names in the Win32 namespace that behave like devices rather than normal files. These names:

• Are case‑insensitive.
• Are treated as existing in every directory.
• May be accepted by many file APIs with extensions appended (e.g., NUL.txt) or with trailing dots/spaces.
• Map to device semantics (e.g., NUL is a sink; CON refers to the console).

Because these names are interpreted by the OS, opening and reading them may invoke device behavior (which is not the same as reading ordinary disk-backed file bytes), and some read operations can block/hang the caller depending on the device and how it behaves. Microsoft explicitly documents these restrictions and advises developers to avoid using reserved names.

How safe_join is intended to work​

*safe_join(directory, pathnames)** is designed to join user-provided path components to a base directory while ensuring the final path remains inside that directory (i.e., no directory traversal). It typically:

• Normalizes and joins the components.
• Resolves symbolic links or relative components.
• Compares the resulting path to a normalized base directory to ensure containment.

The expectation is that if a user supplies a malicious value like ../etc/passwd, safe_join will refuse it. But the function must also handle platform‑specific corner cases: canonicalization results can differ on Windows and POSIX, and reserved device-name semantics require explicit detection beyond simple path normalization.

The bug: pattern-matching vs. canonical device semantics​

The initial mitigation attempted by Werkzeug screened for exact device-name matches (e.g., filenames exactly equal to CON), but the Windows semantics allow variations (extensions, compound extensions, trailing spaces) that are still mapped to device behavior. An attacker can craft a path segment that looks like a harmless filename to a naive check (for example, public/uploads/CON.txt.html), yet Windows will accept the segment and direct the open call to the CON device semantics. Because send_from_directory will open that path (the name appears to be a normal file under the allowed directory), the application ends up opening a device handle and then, typically, hanging when trying to read it.
This combination of library-level filtering that is too narrow and OS-level name interpretation is the root cause. The more complete fix rejects known device‑name patterns regardless of extension or trailing spaces and adds wider coverage for variants. (github.com)

---

Who is affected?​

• Any Python web application using Werkzeug < 3.1.5 on Windows that calls send_from_directory (or otherwise relies on safe_join) with user‑controlled path components is in scope.
• Flask applications that delegate file‑serving to Werkzeug’s helpers are affected because Flask’s send_from_directory uses Werkzeug’s implementation. This includes apps that expose upload directories or arbitrary file‑download endpoints that accept path fragments from clients.
• Linux and most Unix-like deployments are not affected by this Windows‑specific semantic; however, Windows containers, Windows‑hosted WSGI servers, and development/test environments running on Windows are at risk.
• Because many dependent products vendor-bundle or ship Werkzeug (or include it as a transitive dependency), enterprise software that consumes the library may also be affected; several vendor bulletins (for example, IBM) call out the CVE and recommend updates.

Impact and exploitability​

• Primary impact: Denial of Service (availability). An attacker sending crafted requests that lead the application to open and read device-like paths may cause worker threads/processes to block indefinitely, reducing capacity or taking the service offline if enough workers are affected. Public CVSS assessments reflect this availability impact and rate the issue as Medium.
• Exploitability constraints:
• The target must be running Windows (or a Windows container) with a vulnerable Werkzeug version.
• The application must accept attacker-controlled path segments that get passed to safe_join/send_from_directory without additional application-level filtering.
• No authentication is required if the file-serving endpoint is public, so remote unauthenticated DoS is possible in that configuration.
• The issue does not directly disclose files (confidentiality) nor permit arbitrary code execution (integrity) based on currently published information; however, availability impacts can be operationally severe in high-availability environments.
• Real‑world risk profile: The vulnerability is high-risk for internet‑facing services that serve files from untrusted input on Windows hosts and lower risk for services running on Linux or for apps with strict input validation in front of file-serving calls.

Detection and hunting guidance​

If you manage Python web services or infrastructure, hunt for indicators of attempted or successful exploitation:

• Search web server / application logs for requests that target file endpoints with path segments that end in known device-name patterns (case-insensitive). Examples to look for include path components ending with CON, CON., CON, CON.txt, CON.txt.html, NUL, PRN, AUX, COM1, LPT1, and superscript variants. These may appear URL‑encoded in logs. A defensive detection pattern (pseudo‑regex) could be:
• Case-insensitive match against path segment suffixes: (CON|PRN|AUX|NUL|COM[1-9]|LPT[1-9]) optionally followed by dots, spaces, or multiple extensions.
• Monitor WSGI worker process behavior and HTTP request latency: worker processes that hang when handling file‑serving requests or show repeated “reading file” states are suspicious.
• Instrument application code or WSGI middleware to log every call into send_from_directory/safe_join, including the resolved absolute path and the original user-supplied segment; this can reveal attempts to exploit the validation gap.
• Use endpoint telemetry (traces, sampling) to capture stack traces of workers that are hanging; that will help identify blocked file I/O on reserved device handles.
• If you have a Web Application Firewall (WAF), create rules to block requests matching reserved device-name patterns in path segments for endpoints that serve files.

Note: because these names are legal-looking filenames for non-experts, detection requires careful, case-insensitive pattern matching and consideration of URL-encoding. (github.com)

Mitigation and remediation​

• Upgrade immediately
• The vendor fix is released in Werkzeug 3.1.5; upgrade all affected hosts and rebuild/deploy applications that depend on Werkzeug to 3.1.5 or later. This is the primary and recommended remediation.
• If you cannot upgrade right away, apply defensive filters
• On Windows hosts, add input sanitization that rejects path segments equal to or ending with reserved device names, in a case‑insensitive manner, and regardless of trailing dots, spaces, or multiple extensions.
• Reject file requests whose final path component matches a device-name pattern, for example:
• Deny if the final path component (after splitting on path separators) case‑insensitively starts with one of the reserved names and is followed only by dots/spaces and optional extensions.
• Prefer whitelisting acceptable filenames rather than blacklisting; for example, maintain a trusted set of filenames to serve or restrict file downloads to a verified mapping of safe names.
• Minimize attack surface
• Avoid using send_from_directory with untrusted input where possible; instead, map allowed tokens to filename paths on the server side.
• Add rate limits on file-serving endpoints to reduce amplification of any DoS attempts.
• Restrict access to file-serving endpoints via authentication or network controls if the endpoint does not need to be public.
• Runtime protection
• Use worker process supervisors and request timeouts (for example, WSGI server request timeouts) to ensure blocked workers are recycled rather than leaving the service degraded indefinitely.
• Configure system-level timeouts for file I/O where possible, and ensure process managers restart hung workers.
• Test and validate
• After upgrading, run cross‑platform regression tests that include Windows-specific cases: filenames like CON, NUL, COM1, CON.txt, CON.txt.html, and trailing-space variants should be rejected or handled safely by the application. This helps prevent regressions in future changes.

Operational checklist (quick steps)​

• Inventory all services that depend on Werkzeug (.1.5), including transitive dependencies and vendor packages.
• Prioritize internet‑facing Windows hosts and file‑serving endpoints for immediate update to Werkzeug 3.1.5+.
• Deploy temporary WAF rules and server-side filters to block reserved device-name patterns while you patch.
• Enable request timeouts and monitor worker health to limit the impact of attempts.
• Add cross‑platform unit tests for path canonicalization to prevent future regressions.

Why this class of bug keeps appearing — and what maintainers can do​

There are three recurring causes for device‑name escape bugs in cross‑platform libraries:

• Platform semantics mismatch. Library authors may reason in POSIX terms (where CON or NUL are ordinary filenames) and miss Windows’ legacy device semantics that treat certain identifiers as devices in every directory.
• String-based filters are brittle. Simple checks for exact matches fail against variations like compound extensions (CON.txt.html) or trailing whitespace. Canonicalization is hard: a robust check must consider how the OS will interpret the final path.
• Insufficient cross-platform CI coverage. A patch that passes Linux-based CI can still be unsafe on Windows; automated cross‑platform test suites that exercise path handling on Windows are essential.

Pallets’ maintainers fixed the problem, but the sequence of advisories (an initial fix followed by a second CVE for residual cases and then further follow-ups) highlights that patching alone is not enough unless the test matrix includes the platform quirks being guarded against. The project’s iterative fixes and release notes illustrate a responsible maintenance process, but they also show how subtle OS behavior can produce multiple rounds of remediation.

Critical analysis — strengths and risks​

Strengths​

• The maintainers responded with patches and public advisories; the 3.1.4 and 3.1.5 releases show active triage and incremental hardening. The changelog documents corrections specific to Windows device-name handling, and the project provided a fix that addressed compound extensions and trailing‑space cases.
• Multiple security databases (NVD, Snyk, OSV, GitLab advisories) have cataloged the CVE, making it easier for defenders and automated tooling to detect and remediate vulnerable versions. That ecosystem support speeds mitigation in downstream projects.

Risks / Concerns​

• Repeated advisories for the same functional area (device-name handling) indicate that this is an easy class of regression to reintroduce. Without Windows-specific unit tests, future changes could re-open the same gap.
• Many applications rely on Werkzeug transitively (Flask and other frameworks), and enterprise products sometimes vendor-bundle older versions. That increases the risk of lagged remediation: a vulnerable Werkzeug copy can sit inside a vendor product even if the top-line app is updated.
• Detection is non-trivial because the attack strings may look like ordinary filenames or be URL-encoded. Incomplete logging or lack of resolved-path telemetry reduces defenders’ ability to spot exploitation attempts before service degradation occurs.

Final recommendations for defenders​

• Treat all Windows-hosted Python web services that use Werkzeug < 3.1.5 as high priority for patching.
• If you maintain CI/CD pipelines, add Windows-based tests that exercise safe_join/send_from_directory with a suite of reserved-name cases, including compound extensions and trailing spaces.
• For product teams that ship third‑party code, ensure your SBOM and dependency scanning picks up transitive Werkzeug versions and request updates from vendors if necessary.
• On high‑value services, combine immediate patching with short-term mitigations (WAF rules, input filters, request timeouts) to reduce risk while upgrades are rolled out.

---

CVE-2026-21860 is a textbook example of how platform-specific legacy behavior can undermine cross‑platform security assumptions: a function designed to prevent directory traversal can be bypassed not by clever encoding but by leaning on decades-old OS semantics that interpret seemingly harmless filename variants as devices. The fix is straightforward—upgrade to Werkzeug 3.1.5 or later—but the broader lesson is operational: maintainers and defenders must test and harden against platform quirks, and organizations should treat transitive dependencies and vendor-bundled libraries as first‑class patching concerns.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center