Microsoft Windows Shell command injection enables security feature bypass across Windows and Outlook.com

Improper neutralization of special elements used in a command ('command injection') in Windows Shell allows an unauthorized attacker to bypass a security feature over a network.

• Microsoft Outlook.com: affected from 1.0.0 before 20260925.100.
• Microsoft Windows 10 Version 1607: affected from 10.0.14393.0 before 10.0.14393.9612.
• Microsoft Windows Server 2016, including Server Core installation: affected from 10.0.14393.0 before 10.0.14393.9612.
• Microsoft Windows 10 Version 1809: affected from 10.0.17763.0 before 10.0.17763.9376.
• Microsoft Windows Server 2019, including Server Core installation: affected from 10.0.17763.0 before 10.0.17763.9376.
• Microsoft Windows 10 Version 21H2: affected from 10.0.19044.0 before 10.0.19044.7807.
• Microsoft Windows 10 Version 22H2: affected from 10.0.19045.0 before 10.0.19044.7807, as recorded in the supplied version data.
• Microsoft Windows 11 Version 23H2: affected from 10.0.22631.0 before 10.0.22631.7652; the record includes both ARM64 and x64.
• Microsoft Windows 11 Version 24H2: affected from 10.0.26100.0 before 10.0.26100.9711.
• Microsoft Windows 11 Version 25H2: affected from 10.0.26200.0 before 10.0.26200.9711.
• Microsoft Windows 11 version 26H1: affected from 10.0.28000.0 before 10.0.28000.3231.
• Microsoft Windows 11 Version 26H2: affected from 10.0.26300.0 before 10.0.26300.9711.
• Microsoft Windows Server 2012 R2, including Server Core installation: affected from 6.3.9600.0 before 6.3.9600.23470.
• Microsoft Windows Server 2022: affected from 10.0.20348.0 before 10.0.20348.5761.
• Microsoft Windows Server 2025, including Server Core installation: affected from 10.0.26100.0 before 10.0.26100.33650.

These boundaries are branch-specific. A reported update boundary for one branch does not establish that every later or parallel branch is unaffected.

The vulnerability is classified as CWE-77 and occurs when special elements in a command are not properly neutralized before Windows Shell processes them. The record states that an attacker can reach the vulnerable behavior over a network without prior privileges, but user interaction is required. The supplied assessment describes low attack complexity and unchanged scope. The record does not identify the exact command, parameter, interface, parser, or processing boundary reached by attacker-controlled input, and it does not specify which security feature is bypassed.

• The vulnerability is reachable over a network.
• The attacker requires no prior authentication or privileges, but user interaction is required.
• The supplied assessment describes low attack complexity.
• The CISA Known Exploited Vulnerabilities entry confirms exploitation in the wild. Use in a ransomware campaign is recorded as unknown.
• The supplied record does not identify a public exploit; that status does not contradict the confirmed exploitation entry.
• No payload, exploit chain, or deployment-specific precondition is provided in the available evidence.

The flaw allows attacker-controlled input containing special command elements to pass through inadequate neutralization and result in a security-feature bypass. The supplied assessment indicates potentially high effects on confidentiality, integrity, and availability, but the available evidence does not confirm code execution, persistence, privilege escalation, or a specific form of data access. Because scope is assessed as unchanged, the described outcome remains within the exploited component or system. At the organizational level, exploitation could reduce the effectiveness of security controls, require urgent investigation, and disrupt operations while multiple Windows and Windows Server branches are updated. The actual outcome depends on the specific security feature, input path, and user interaction involved, which have not been publicly detailed.

• Successful exploitation can weaken or bypass a security feature on affected systems.
• The supplied assessment indicates potentially high effects on confidentiality, integrity, and availability, but it does not confirm a specific takeover, data theft, or destructive scenario.
• The affected product scope includes Windows client, Windows Server, Server Core installations, and the Outlook.com entry, increasing inventory and triage requirements.
• Because exploitation has been confirmed, unpatched systems may present additional operational risk and risk of security-control evasion.
• The record does not identify which data, services, or user populations were actually affected.

1. Update each affected branch: install the applicable Microsoft security update so the installed version is no longer below the lessThan boundary for that branch in affected_summary. The record states that a patch is available but does not provide KB identifiers or detailed installation instructions.
2. Treat branches independently: do not use a Windows client boundary to determine the status of Windows Server, Server Core, Outlook.com, or another Windows branch. For Windows 10 Version 22H2, verify the recorded boundary carefully because it is listed as 10.0.19044.7807.
3. Prioritize network-reachable assets: address unpatched systems first, especially those involved in workflows where users interact with content from untrusted sources.
4. For Outlook.com: follow Microsoft service-side remediation guidance; the record does not describe a local update mechanism or the service deployment boundary.
5. If updating is delayed: use only a mitigation documented by Microsoft or CISA for the applicable product and branch. The supplied record does not provide a technical workaround, so unsupported substitute controls should not be assumed.
6. Investigate potentially affected assets: because CISA confirms exploitation, perform incident response and forensics under the organization’s process for systems in affected ranges. No specific IOC is supplied in the record.

1. Inventory Microsoft Windows and Windows Server systems, including Server Core installations, and record their exact current builds.
2. Compare each build with the affected branches and corresponding version boundaries in affected_summary; do not infer the status of one branch from an update for another.
3. For Outlook.com, verify service-side exposure and Microsoft guidance rather than attempting a local version check.
4. Prioritize review of assets reachable over the network and workflows that require users to open or interact with untrusted content.
5. Because exploitation has been confirmed, perform incident triage and forensics under the organization’s response process for assets running affected versions. The record provides no IOC, log event, or specific telemetry pattern.
6. Absence of matching log evidence does not prove that a system is safe; combine inventory, update state, and incident investigation.