CVE-2020-0646
A remote code execution vulnerability exists when the Microsoft .NET Framework fails to validate input properly, aka '.NET Framework Remote Code Execution…
Critical
Known exploited
- Severity
- 9.8 / 10
- Critical · CVSS 3.1
- Exploit chance (EPSS)
- 99.22%
- Chance of exploitation in the next 30 days. Higher than 99.94% of scored vulnerabilities.
- Known exploited
- Yes
- In CISA's catalog since Nov 3, 2021
- Weakness
- CWE-91 XML Injection (aka Blind XPath Injection)
- CWE-91 XML Injection (aka Blind XPath Injection)
- Fix
- None yet
- No fixed version published
Exploited in the wild. Microsoft .NET Framework Remote Code Execution Vulnerability (Microsoft .NET Framework). Required action: Apply updates per vendor instructions. Due for U.S. federal agencies by May 3, 2022.
Description
A remote code execution vulnerability exists when the Microsoft .NET Framework fails to validate input properly, aka '.NET Framework Remote Code Execution Injection Vulnerability'.
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.1 9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-91: XML Injection (aka Blind XPath Injection)
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
How to prevent it
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
CWE-91: XML Injection (aka Blind XPath Injection)
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
How to prevent it
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
References
Advisories
Other links
Timeline
- Published
- Added to CISA's Known Exploited Vulnerabilities catalog
- Remediation due for U.S. federal agencies
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-vr34-hp96-76pp xmldom: requireWellFormed DocType publicId/systemId validation is bypassable via an embedded line terminator | High | Same weakness, CWE-91 |
| GHSA-jxjr-3g7g-3944 xmldom: requireWellFormed element/attribute name validation is bypassable via an embedded line terminator | High | Same weakness, CWE-91 |
| GHSA-c7q8-3ch8-vqpv xmldom: Processing Instruction Target Injection Bypasses requireWellFormed | High | Same weakness, CWE-91 |
| GHSA-3px3-54cx-rmw9 xmldom: Creation-time XML Name/QName validation is bypassable via an embedded line terminator, allowing injection on the default serialization path | High | Same weakness, CWE-91 |
| GHSA-27p8-2357-5qqv xmldom: DocType `name` Injection Bypasses requireWellFormed | High | Same weakness, CWE-91 |
| GHSA-w2rr-34g9-rvrj xmldom: Element name injection via createElement() bypasses requireWellFormed | High | Same weakness, CWE-91 |
| GHSA-4w3w-2rp5-g8jm xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed | High | Same weakness, CWE-91 |
| EEF-CVE-2026-48590 Element and Attribute Names Injected Verbatim into XML Output in xml_builder | Not rated yet | Same weakness, CWE-91 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor