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

Registry-symlink local EoP (CWE-59 / external control of path) in the WLAN AutoConfig service wlansvc.dll (runs as SYSTEM). The profile-sync trigger functions CdsTriggerSyncIfNeededForLoggedInUsers, CdsTriggerSyncWithProfileDeletion and CdsTriggerSyncIfProfileEligible query the session user's token via UMgrQueryUserToken and then call Windows::Internal::WiFiCloudStore::IsSyncNeededForUser with that token WITHOUT impersonating it - so the registry work runs under SYSTEM. Inside IsSyncNeededForUser, keys are opened by name under HKLM\SOFTWARE\Microsoft\WlanSvc\ProfileSync\<SID> (OpenGenericSyncBaseKeyForUser 'Profiles'/'Cost', gated by WlanSvcTaskBootstrapped==1, creating an NLM/Irrelevant subkey). A standard user owns that subtree, so they replace the Profiles/Cost/NLM path components with registry symbolic links into protected system hives; SYSTEM then follows them, directing privileged registry operations at attacker-chosen targets -> EoP. IN-HOUSE Ghidra decompilation diff of wlansvc.dll 10.0.26100.7019 -> .7171 (Nov 11 2025; 3 MB analyzed via a persisted project) confirms the fix: all three CdsTriggerSync* functions now DuplicateToken the user token and wil::impersonate_token_nothrow it before the operation and RevertImpersonateToken after (PRE 0 -> POST 22 impersonation calls), so registry access is evaluated with the user's rights and symlinks into system paths fail with access-denied; token/impersonation failure halts the operation. Unconditional fix. Credit: t0zhang.

WLAN AutoConfig handles the user's profile-sync registry keys under SYSTEM without impersonation, so user-planted symlinks are followed as SYSTEM

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.

T0