CVE-2021-36952

What it actually does

CVE-2021-36952 is a memory-corruption vulnerability in Microsoft Visual Studio 2017 and Visual Studio 2019 that can allow remote code execution in the context of the user running Visual Studio. Exploitation requires user interaction, such as opening a malicious project, solution, or related developer artifact. If triggered successfully, the flaw can allow attacker-controlled code to execute with the same privileges as the victim user, potentially enabling data theft, source-code tampering, credential access, persistence, or lateral movement from a developer workstation.

Why it matters to the business

This vulnerability primarily threatens developer workstations and build-related workflows. A successful attack could compromise source code, signing material, credentials, package publishing access, or internal systems reachable from a developer machine. Although it is not listed in CISA KEV and no mature public exploit is indicated, the EPSS score is relatively high, meaning organizations should treat exposed developer environments as a meaningful risk, especially where Visual Studio is used to handle third-party, open-source, contractor-supplied, or externally received project files.

How an attack unfolds

An attacker prepares a malicious Visual Studio-compatible file, project, solution, or repository content designed to trigger memory corruption when processed by a vulnerable Visual Studio 2017 or 2019 installation. The attacker then delivers the content through a plausible developer workflow, such as a shared repository, pull request, archive, email attachment, issue reproduction package, or contractor handoff. When a user opens or builds the crafted content in Visual Studio, the vulnerability is triggered and attacker-controlled code may execute under that user's account. From there, the attacker may run post-exploitation tooling, access source repositories or secrets available to the user, modify build artifacts, steal credentials or tokens, and attempt to move laterally to other systems accessible from the developer workstation.

How to fix it

Apply the relevant Microsoft security updates for Visual Studio 2017 and Visual Studio 2019, or upgrade affected installations to the latest supported servicing release. Because no fixed versions were provided in the input, use Microsoft Visual Studio Installer, enterprise software management, or Microsoft Update channels to ensure Visual Studio 2017 and 2019 are fully patched with updates released on or after the September 2021 security update cycle. Where patching is delayed, reduce exposure by preventing developers from opening untrusted projects or archives, using isolated sandboxes or disposable virtual machines for externally supplied code, disabling unnecessary extensions, enforcing least privilege on developer workstations, and restricting access from developer endpoints to sensitive production systems, signing keys, and package publishing credentials.

How to confirm the fix worked

Confirm that all Visual Studio 2017 and Visual Studio 2019 installations have received the applicable Microsoft security update or have been upgraded to a supported, fully patched release. Validate through the Visual Studio Installer, installed product version inventory, endpoint management tooling, or software asset management scans. Review whether vulnerable versions remain on developer endpoints, build workstations, jump hosts, or virtual desktop images. Test mitigation effectiveness by confirming that untrusted project handling processes require sandboxing or review and that developer workstations do not run with unnecessary administrative privileges.

Typical attack path

1. Identify an organization or developer using Microsoft Visual Studio 2017 or 2019.
2. Create a malicious Visual Studio project, solution, or related file that triggers the memory-corruption condition.
3. Deliver the crafted content through a developer-trusted channel such as a repository, archive, pull request, email, chat, or issue tracker.
4. Convince the target user to open or build the content with a vulnerable Visual Studio installation.
5. Execute code in the context of the Visual Studio user account.
6. Use the compromised developer workstation to access source code, credentials, package registries, signing keys, or internal services.
7. Establish persistence, exfiltrate data, tamper with code or builds, or move laterally if additional access is available.

How to detect it

Look for signs that Visual Studio opened untrusted content and then launched unusual child processes or network connections. Useful telemetry includes endpoint detection and response events, Windows Security process creation logs, Sysmon Event ID 1 process creation, Sysmon Event ID 3 network connections, PowerShell logs, command-line auditing, file creation events, source-control activity, proxy logs, DNS logs, and authentication logs. Investigate Visual Studio or MSBuild spawning shells, script interpreters, download tools, archive utilities, or binaries from user-writable directories. Review recent downloads, extracted archives, cloned repositories, pull requests, and issue reproduction packages that were opened in Visual Studio before patching. Also check for suspicious changes to build scripts, project files, package manifests, CI/CD configuration, credential files, and source repositories. Because the input does not provide a public exploit signature or malware family, detection should emphasize behavioral anomalies rather than a single definitive indicator.

• devenv.exe
• MSBuild.exe
• VBCSCompiler.exe
• ParentImage=*\\devenv.exe Image=*\\powershell.exe
• ParentImage=*\\devenv.exe Image=*\\cmd.exe
• ParentImage=*\\devenv.exe Image=*\\wscript.exe
• ParentImage=*\\devenv.exe Image=*\\cscript.exe
• ParentImage=*\\devenv.exe Image=*\\mshta.exe
• ParentImage=*\\devenv.exe Image=*\\rundll32.exe
• ParentImage=*\\devenv.exe Image=*\\regsvr32.exe
• ParentImage=*\\devenv.exe Image=*\\certutil.exe
• ParentImage=*\\devenv.exe Image=*\\bitsadmin.exe
• ParentImage=*\\devenv.exe Image=*\\curl.exe
• ParentImage=*\\devenv.exe Image=*\\wget.exe
• ParentImage=*\\MSBuild.exe Image=*\\powershell.exe
• ParentImage=*\\MSBuild.exe Image=*\\cmd.exe
• ParentImage=*\\MSBuild.exe Image=*\\rundll32.exe
• ParentImage=*\\MSBuild.exe Image=*\\regsvr32.exe
• ParentImage=*\\MSBuild.exe Image=*\\mshta.exe
• Image=*\\AppData\\Local\\Temp\\*.exe ParentImage=*\\devenv.exe
• Image=*\\AppData\\Local\\Temp\\*.dll ParentImage=*\\devenv.exe
• Image=*\\AppData\\Roaming\\*.exe ParentImage=*\\devenv.exe

What your security team should do

• Inventory all Microsoft Visual Studio 2017 and Visual Studio 2019 installations, including developer laptops, virtual desktops, build machines, and lab systems.
• Patch or upgrade affected Visual Studio installations to the latest supported servicing release as a priority due to the high EPSS score.
• Hunt for suspicious child processes spawned by Visual Studio or build tools, especially PowerShell, cmd.exe, script interpreters, download utilities, or credential-access tools.
• Review recent externally sourced projects, pull requests, archives, or reproduction packages opened by developers before patching.
• Require sandboxed analysis for untrusted code projects and archives received from third parties or the internet.
• Restrict developer endpoint access to production systems, signing infrastructure, package registries, and sensitive secrets using least privilege and strong authentication.
• Monitor source repositories and build pipelines for unexpected commits, build script changes, dependency changes, or package publishing activity following suspicious Visual Studio execution.