Windows PowerShell CVE-2026-70185

Requires an attacker who already has local, authenticated, low-privileged access to the Windows host and the ability to run PowerShell (PR:L, AV:L, UI:N) - there is no remote or unauthenticated path. The attacker then abuses the flaw to bypass a PowerShell protection mechanism/security feature, crossing a security boundary (S:C) for full impact. Limiting factors that reduce real-world risk: the mandatory pre-existing local foothold, the authenticated low-privilege prerequisite, and SSVC Automatable=no (not scannable/wormable). The exact security feature that is bypassed is not named in the MSRC description, so defenders cannot pin exploitation to a single named configuration; all supported Windows editions in the listed version ranges are affected regardless of a special opt-in setting.

Signals are moderately consistent and point to a real but not emergency-tier issue. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 8.8) describes a locally-exploitable flaw requiring a low-privileged authenticated foothold, with no user interaction and a scope change that yields total confidentiality, integrity, and availability impact - the scope change is what pushes an otherwise local issue to 8.8. CISA's SSVC decision framework aligns with and tempers this: Exploitation=none (no observed activity), Automatable=no (consistent with AV:L requiring pre-existing local access, so no mass/wormable scanning), but Technical Impact=total (matching C:H/I:H/A:H). It is NOT in CISA KEV and no public exploit is identified, so exploitation status is 'no public exploit identified at time of analysis.' EPSS is not provided in the input, so probabilistic exploitation likelihood cannot be quantified here. Net: this is a credible privilege/security-boundary bypass worth prioritized patching on managed Windows fleets, but the local-access precondition and absence of exploitation evidence place it below internet-facing unauthenticated criticals. One data tension to verify: the CWE is CWE-639 (authorization bypass) and the description frames it as a protection-mechanism/security-feature bypass, whereas the input Tag says 'Authentication Bypass' - authorization/security-feature bypass is the more accurate framing.

A low-privileged but authenticated local user on an affected Windows host (e.g., a standard user or a constrained PowerShell session) executes crafted PowerShell that defeats a PowerShell security feature, escaping the intended restriction and gaining execution across a security boundary with full system impact. No public exploit code is identified, so an attacker would need to develop the technique; the local, no-user-interaction nature (AV:L/UI:N) means it chains cleanly after any initial access.