Attacker Value
Very High
(1 user assessed)
(1 user assessed)
User Interaction
Privileges Required
Attack Vector


Disclosure Date: September 11, 2020
Add MITRE ATT&CK tactics and techniques that apply to this CVE.


A remote code execution vulnerability exists in Microsoft Exchange server due to improper validation of cmdlet arguments. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the System user, aka ‘Microsoft Exchange Server Remote Code Execution Vulnerability’. Note: As of January 12, 2021, the patch for CVE-2020-16875 has been bypassed twice. See CVE-2020-17132 for details.

Add Assessment

  • Attacker Value
    Very High
  • Exploitability
Technical Analysis

There’s more info in Rapid7’s analysis here, but as @tsellers-r7 and @smcintyre-r7 pointed out privately today, need for authenticated session + exposed PowerShell endpoint + user who belongs to specific Exchange groups = less opportunity for wide-scale attacks than something like February’s Exchange vuln. I’m interested to see how Steven Seeley’s exploit works if he releases it, though. Might be cause for quick re-evaluation.

CVSS V3 Severity and Metrics
Base Score:
7.2 High
Impact Score:
Exploitability Score:
Attack Vector (AV):
Attack Complexity (AC):
Privileges Required (PR):
User Interaction (UI):
Scope (S):
Confidentiality (C):
Integrity (I):
Availability (A):

General Information


  • Microsoft


  • Microsoft Exchange Server 2019 Cumulative Update 5,
  • Microsoft Exchange Server 2019 Cumulative Update 6,
  • Microsoft Exchange Server 2016 Cumulative Update 16,
  • Microsoft Exchange Server 2016 Cumulative Update 17

Additional Info

Technical Analysis

Update January 15, 2021: The original patch for CVE-2020-16875 has been bypassed twice. Microsoft issued CVE-2020-17132 for the first patch bypass; as of January 15, 2021, the second patch bypass has been released as an unpatched zero-day, complete with exploit code. See Rapid7’s analysis of CVE-2020-17132 for full details.

Update September 10, 2020: A proof-of-concept exploit is now publicly available. Amended analysis is available in the Rapid7 analysis section.

Update September 9, 2020: Microsoft updated their advisory to reflect that CVE-2020-16875 is a remote code execution vulnerability and not a memory corruption as previously stated. Amended information is below.


On Tuesday, September 8, 2020, Microsoft published a security advisory on CVE-2020-16875, a remote code execution vulnerability affecting Microsoft Exchange Server. According to Microsoft’s advisory, the vulnerability arises from improper validation of cmdlet arguments. More specifically, Seeley writes that “the flaw exists within the processing of the New-DlpPolicy cmdlet. The issue results from the lack of proper validation of user-supplied template data when creating a dlp policy.” An attacker who successfully exploits the vulnerability can run arbitrary code in the context of the SYSTEM user. CVE-2020-16875 carries a CVSSv3 base score of 8.4.

Exploitation of CVE-2020-16875 requires an authenticated user in a certain Exchange role to be compromised. As of September 10, 2020, a public proof-of-concept is available via Steven Seeley, the researcher who discovered the vulnerability. CVE-2020-16875 still falls into the impending threat category; we will update this analysis should we see evidence of active exploitation (which is likely).

Affected products

  • Exchange Server 2016 (Cumulative Update 16 and 17)
  • Exchange Server 2019 (Cumulative Update 5 and 6)

Note: Previous Cumulative Update releases are almost certainly affected as well, but because they are no longer supported by Microsoft they are not explicitly listed in the advisory.

Rapid7 analysis

CVE-2020-16875 is a post-authentication vulnerability that, if successfully exploited, would give an attacker SYSTEM-level access on the affected Exchange server. Because Exchange is integrated with Active Directory, attackers who exploit CVE-2020-16875 may also be in a position to compromise Active Directory. CVE-2020-16875 requires an exposed PowerShell endpoint for successful remote exploitation; it also requires that an attacker be able to execute operations within the context of a user who belongs to a specific Exchange group (updates to available information indicate that the group in question is the “Data Loss Prevention” group).

In general, Microsoft Exchange is both a valuable and a frequently exposed attack target, as previous attacks have underlined. While control of an Exchange server from which to launch attacks is a high-value opportunity for attackers, the attack surface area for this particular vulnerability appears to be smaller than that of, say, CVE-2020-0688. CVE-2020-16875 is a useful option for penetration testers on internal engagements or for attackers who already have credentials with which to authenticate.

CVE-2020-16875 poses higher risk for multi-tenant environments—i.e., multiple organizations using the same Exchange and/or Active Directory environment.


Microsoft has released KB4577352 as a security update that resolves this vulnerability. It is available via Windows Update, or as standalone packages directly from the Update Catalog or Download Center:

Note that standalone packages should be installed as an Administrator to ensure all relevant files are updated correctly.

Microsoft has not provided any mitigations or workarounds, and we recommend patching as soon as possible. A list of mitigating controls is below:

  1. On Exchange Client Access servers, make sure that the /PowerShell/ virtual directory has the correct Authentication methods configured per Microsoft Best Practices and your internal security requirements. You can find virtual directory information for Exchange Server 2016 and 2019 here.
  2. To use remote PowerShell to connect to an Exchange server, the user needs to be a member of a management role group, or be directly assigned a management role that enables the user to run Exchange cmdlets. Audit Exchange Role groups to ensure that they only contain the appropriate users and that those users have the appropriate controls in place on their accounts and environment. Microsoft documentation on how to block or allow users’ remote PowerShell access to Exchange servers is available here.