Improper Windows device-name handling in PHP Group PHP can cause denial of service

On Windows, PHP's filesystem and stream APIs do not reject reserved device names such as CON, PRN, AUX, NUL, COM1 to COM9, LPT1 to LPT9, CONIN$ and CONOUT$ when they appear as a component of a path. An attacker-controlled filename therefore reaches CreateFileW() and opens a device instead of the regular file the application expected, which can block or hang the request and exhaust worker processes.

• Only PHP deployments on Windows are identified by the advisory as affected.
• PHP 8.2.* is affected when below 8.2.34; the corresponding patched release is 8.2.34.
• PHP 8.3.* is affected when below 8.3.35; the corresponding patched release is 8.3.35.
• PHP 8.4.* is affected when below 8.4.26; the corresponding patched release is 8.4.26.
• PHP 8.5.* is affected when below 8.5.11; the corresponding patched release is 8.5.11.
• Branches or distribution packages outside these boundaries require separate verification. The fix status of one branch must not be inferred for every other branch.

This is a CWE-67 flaw in PHP's Windows path handling. When a path component contains a reserved device name such as CON, PRN, AUX, NUL, COM1 to COM9, LPT1 to LPT9, CONIN$, or CONOUT$, PHP does not reject it before passing the path into the Windows I/O layer. Application paths flow through the stream wrapper layer, for example file_get_contents() calls php_stream_open_wrapper_ex(), while move_uploaded_file() reaches VCWD_RENAME() and php_copy_file_ex(), before php_win32_ioutil_open_w() passes the path to CreateFileW().

The flaw is reachable over the network when a Windows application exposes a path or filename that an attacker can control. The record indicates that no prior privileges and no user interaction are required, but exploitation has high complexity and depends on suitable deployment conditions. The vendor advisory publishes a proof-of-concept demonstrating the behavior. The reviewed evidence does not identify a campaign, victim, or specific observed abuse.

When the preconditions are met, PHP can open a device handle instead of a regular file. Devices that wait for input can keep requests open, and concurrent requests can exhaust workers and interrupt service. The record identifies network reachability, no prior privileges, and no user interaction, but also identifies high attack complexity and dependence on an application path that accepts attacker-controlled input. The confirmed impact is centered on service and worker-pool availability; the available evidence does not establish a confidentiality or integrity impact.

A PHP application on Windows that builds paths from user-controlled data, such as an upload destination or download endpoint, can be forced to operate on a system device instead of the intended file. Depending on the device and operation, requests may block, hang, produce unexpected read or write behavior, or return native Windows API errors. Repeated requests against a blocking device can consume the worker pool and deny service. The supplied evidence does not establish unauthorized data disclosure, data modification, or code execution.

1. Upgrade PHP on Windows to the patched release for the deployed branch: 8.2.34, 8.3.35, 8.4.26, or 8.5.11. Use the exact patched release for the same branch and do not treat a fix in one branch as evidence that all other branches are fixed.
2. Verify operating-system or vendor-supplied PHP packages separately to ensure that the running package contains the relevant backport.
3. Review endpoints that allow external data to control filenames or paths. If immediate updating is not possible, a temporary application-boundary control can prevent untrusted path components from using reserved device names; test this control against Windows path semantics.
4. Do not rely only on application-level path joining or normalization, because the advisory states that these operations may not detect Windows device names.
5. After updating, test both rejection of reserved device names in path components and any explicitly supported device paths that must remain available for compatibility.

1. Inventory Windows hosts running PHP and compare each deployed branch with the affected version boundaries.
2. Review endpoints that accept upload filenames, filename parameters, download paths, or similar data and pass them to file_get_contents(), move_uploaded_file(), or stream wrappers.
3. Check logs and telemetry for long-lived requests, retained workers, worker-pool exhaustion, or unusual I/O errors following client-supplied filenames. Treat these as investigation leads, not vendor-confirmed indicators.
4. In a test environment, verify that reserved device names in path components are rejected after updating, while explicitly supported device paths continue to behave as intended.
5. Do not treat the absence of suspicious log entries as proof that a system is safe.