External control of file name or path in Windows Kernel allows an authorized attacker to elevate privileges locally.

External control of file name/path (CWE-73) in the Windows Projected File System minifilter prjflt.sys PrjfPortConnect volume-name handling, local EoP. A client connecting to the ProjFS communication port supplies a _PRJ_CONNECTION_CONTEXT { GUID virtualizationInstanceID; UINT Version; USHORT VolumeLength; WCHAR szVolume[256]; }. PrjfPortConnect builds usVolumeName from szVolume/VolumeLength (fully user-controlled) and passes it to PrjfGetInstanceFromVolumeName -> FltGetVolumeFromName, which ultimately calls ZwCreateFile with ObjectName = usVolumeName. PRE: the name is not restricted to a legitimate volume device path, so a low-privileged user can supply an arbitrary object path (e.g. L"\Device\SrvAdmin") and cause prjflt to open a privileged device it could not otherwise open - its IRP_MJ_CREATE routine (e.g. SrvNetCreate) then runs. Diff of prjflt.sys 10.0.26100.7920 -> .8036 (Mar 10 2026, KB5079473) confirms the fix: gated behind CFR flag Feature_78846265, PrjfGetInstanceFromVolumeName now calls a new helper PrjfValidateAndGetGlobalVolumePath(name, ...) to validate that the supplied name is a proper global volume path before FltGetVolumeFromName / FltGetVolumeInstanceFromName, rejecting arbitrary device paths.

A fully user-controlled ProjFS connection volume name reaches ZwCreateFile, letting a normal user open privileged devices

Derived from the patch delta: the checks added by the vendor identify which fields crossed a trust boundary unvalidated. Reachability and privilege are taken from the call chain in the RCA report.

ChenJian with Sea Security Orca Team