CVE-2020-16886: Microsoft PowerShellGet RCE Vulnerability

CVE-2020-16886 Overview

A security feature bypass vulnerability exists in the Microsoft PowerShellGet V2 module that allows attackers to circumvent Windows Defender Application Control (WDAC) policies. This vulnerability enables the execution of arbitrary code on machines that should be protected by application control policies, undermining a critical Windows security feature designed to prevent unauthorized code execution.

Critical Impact
Attackers with administrator privileges can bypass WDAC policy enforcement and execute arbitrary PowerShell scripts as fully trusted code on policy-locked machines.

Affected Products

Microsoft PowerShellGet version 2.2.5
PowerShellGet V2 module installed from PowerShell Gallery
Windows systems with WDAC policies configured to allow PowerShellGet module execution

Discovery Timeline

2020-10-16 - CVE-2020-16886 published to NVD
2026-02-23 - Last updated in NVD database

Technical Details for CVE-2020-16886

Vulnerability Analysis

This vulnerability represents an Authorization Bypass flaw in Microsoft's PowerShellGet V2 module that undermines the security guarantees provided by Windows Defender Application Control (WDAC). WDAC is designed to restrict which applications and scripts can run on Windows systems, providing a critical layer of defense against unauthorized code execution. The flaw in PowerShellGet's URL processing logic creates a pathway for attackers to inject and execute PowerShell scripts that bypass these controls entirely.

The exploitation requires a specific configuration where an attacker with administrator privileges first installs the vulnerable PowerShellGet V2 module from the PowerShell Gallery onto a target system. When WDAC policy is configured to trust the PowerShellGet module—a common enterprise configuration given its utility for package management—the vulnerability becomes exploitable. Once these conditions are met, an attacker can inject malicious PowerShell scripts that execute with full trust, completely circumventing the application control restrictions that should prevent unauthorized code execution.

Root Cause

The root cause of this vulnerability lies in improper URL processing within the PowerShellGet V2 module. The module fails to properly validate or sanitize URLs during certain operations, creating an injection point that allows attackers to manipulate the trust context established by WDAC policies. This improper handling enables malicious content to be processed within the trusted execution context of the PowerShellGet module itself.

Attack Vector

The attack requires local access to the target system with administrator privileges. The attacker must first establish a configuration where:

The PowerShellGet V2 module is installed on the target machine from the PowerShell Gallery
WDAC policy is configured to allow the PowerShellGet module to execute
The attacker then exploits the URL processing flaw to inject PowerShell scripts that inherit the trusted status of the module

This attack is particularly concerning in enterprise environments where WDAC policies are deployed to enforce application whitelisting. Organizations relying on WDAC as a primary security control may have a false sense of security if this vulnerable module is present in their environment.

The vulnerability mechanism involves exploiting the trust relationship between WDAC and the PowerShellGet module. When WDAC allows PowerShellGet to run, any code executed through the vulnerable URL processing pathway inherits that trust. Technical details regarding the specific exploitation technique can be found in the Microsoft Security Advisory CVE-2020-16886.

Detection Methods for CVE-2020-16886

Indicators of Compromise

Unexpected PowerShell script execution on WDAC-protected systems that should be blocked by policy
Installation or presence of PowerShellGet version 2.2.5 on protected endpoints
Anomalous URL patterns in PowerShellGet module activity logs
Script execution events originating from the PowerShellGet module context with unusual characteristics

Detection Strategies

Monitor for PowerShellGet module installations and version information across endpoints using Get-Module -ListAvailable PowerShellGet
Implement PowerShell script block logging and module logging to capture detailed execution information
Enable Windows Defender Application Control audit mode to identify potential bypass attempts before they succeed
Review WDAC policy violation events in Windows Event Logs for unusual patterns

Monitoring Recommendations

Configure enhanced PowerShell logging including Script Block Logging (Event ID 4104) and Module Logging
Monitor for Event ID 3076 (WDAC Audit) and Event ID 3077 (WDAC Block) in the CodeIntegrity log
Establish baselines for normal PowerShellGet activity and alert on deviations
Integrate endpoint detection solutions to correlate PowerShell execution patterns with WDAC policy state

How to Mitigate CVE-2020-16886

Immediate Actions Required

Identify all systems with PowerShellGet V2 module version 2.2.5 installed
Apply the Microsoft security update that addresses the URL processing vulnerability
Review WDAC policies to ensure they appropriately restrict PowerShellGet module permissions until patching is complete
Consider temporarily removing or blocking the vulnerable PowerShellGet version on critical systems

Patch Information

Microsoft has released a security update that addresses this vulnerability by changing how URLs are processed within the PowerShellGet module. Organizations should update the PowerShellGet module to the latest version available from the PowerShell Gallery. The update can be applied using the Update-Module PowerShellGet command. For detailed patch information, refer to the Microsoft Security Advisory CVE-2020-16886.

Workarounds

Remove the PowerShellGet V2 module from WDAC allow policies until the patch can be applied
Implement strict administrator privilege controls to limit who can install PowerShell modules
Use WDAC policy rules that target specific, patched versions of PowerShellGet rather than allowing all versions
Consider deploying additional PowerShell constrained language mode restrictions on sensitive systems

bash

# Check installed PowerShellGet version
Get-Module -ListAvailable PowerShellGet | Select-Object Name, Version

# Update PowerShellGet module to patched version
Update-Module -Name PowerShellGet -Force

# Verify WDAC policy status on the system
Get-CimInstance -Namespace root\Microsoft\Windows\CI -ClassName MSFT_MpComputerStatus