Microsoft PowerShell security-feature bypass caused by an improper standard security check

Improperly implemented security check for standard in Microsoft PowerShell allows an unauthorized attacker to bypass a security feature over a network.

• Microsoft PowerShell 7.4: affected from 7.4.0 through versions less than 7.4.21; the recorded update boundary is 7.4.21.
• Microsoft PowerShell 7.5: affected from 7.5.0 through versions less than 7.5.12; the recorded update boundary is 7.5.12.
• Microsoft PowerShell 7.6: affected from 7.6.0 through versions less than 7.6.7; the recorded update boundary is 7.6.7.

The record does not establish the status of other PowerShell release branches or versions outside these ranges.

Microsoft PowerShell has a CWE-358 defect caused by an improperly implemented security check for a standard. The public record does not identify the specific standard, code component, protocol, endpoint, or input format involved, so the internal processing path remains unknown. The structured assessment characterizes the relevant functionality as reachable over a network, requiring no prior privileges, having low complexity, and requiring user interaction. The stated outcome is a security-feature bypass; the protected feature and the action available after bypass are not disclosed. The affected scope is limited to the release branches listed in affected_summary.

• Reachability: Over the network.
• Privileges: The structured assessment states that no prior privileges are required.
• Complexity: Low.
• Interaction: User interaction is required.
• Exploitation status: The supplied record does not identify a public exploit; the CISA enrichment in the returned data records exploitation as none and automatable as no. This is the status recorded in the available data, not proof that exploitation cannot occur later.

The flaw enables a security-feature bypass, with the primary assessed consequence affecting integrity rather than directly exposing data or causing an availability failure. The assessed scope is unchanged, and the record does not establish privilege escalation, code execution, data disclosure, or service outage. Under the relevant conditions, an attacker may be able to cause an operation controlled by the security feature to proceed, but the feature and exact consequence are not disclosed. The practical effect therefore depends on what each organization uses PowerShell and the bypassed control to protect.

Affected Microsoft PowerShell deployments may allow a network-originated request to bypass a security control after user interaction. If this occurs in an administrative or automation workflow, it could weaken policy enforcement or the integrity of an operation that the security feature was intended to block. The structured assessment indicates high integrity impact and does not indicate confidentiality or availability impact. The record does not identify a specific business process, dataset, or asset that would be affected.

1. Update the matching release branch: move Microsoft PowerShell 7.4 to 7.4.21, PowerShell 7.5 to 7.5.12, or PowerShell 7.6 to 7.6.7, according to the branch deployed.
2. Verify after updating that the installed version is beyond the affected boundary for its branch; do not assume that a fix for one branch establishes the status of another.
3. Prioritize systems and workflows where PowerShell functionality is reachable over a network and user interaction can occur.
4. The record does not provide a confirmed workaround. Do not treat an unverified configuration change as equivalent to applying the vendor update.

1. Inventory all Microsoft PowerShell installations and record the actual release branch and version on servers, workstations, and deployment images.
2. Compare each version with the boundaries in affected_summary; do not rely only on the product name or major branch.
3. Review workflows, services, and network exposure that allow remote requests to reach PowerShell-related functionality, while noting that the record does not name a specific endpoint or protocol.
4. Review logs for unusual activity involving the security feature being protected. Treat this only as precautionary monitoring because the record provides no confirmed event name, IOC, or log pattern.
5. Do not treat the absence of suspicious log entries as proof that a system is safe.