CVE-2026-47305: Update Visual Studio to Fix RCE

Microsoft’s July 14 security release fixes CVE-2026-47305, a high-severity remote code execution vulnerability in Visual Studio that can let an attacker run code locally after persuading a user to interact with malicious content. The practical action for developers and IT teams is straightforward: update Visual Studio 2022 17.12 to 17.12.22 or later, Visual Studio 2022 17.14 to 17.14.36 or later, and Visual Studio 2026 to 18.7.4 or later.
Microsoft’s Security Response Center published the advisory as part of the July 2026 security updates. The National Vulnerability Database identifies the issue as a protection-mechanism failure, assigned CWE-693, and records Microsoft’s CVSS 3.1 score of 7.8 out of 10—High severity. BleepingComputer’s July Patch Tuesday coverage likewise lists the Visual Studio flaw as an Important-rated remote code execution issue amid a notably large Microsoft release.
This is not a Windows cumulative update problem that will disappear during the next operating-system patch cycle. The remediation belongs to the Visual Studio servicing process, so developer workstations, build machines, golden images, and offline installation layouts need to be checked separately.

Cybersecurity dashboard showing a Visual Studio vulnerability fixed through a verified software build pipeline.A Local Attack With a Real Developer-Workstation Impact​

The important qualifier in Microsoft’s scoring is local. CVE-2026-47305 is not described as a network-service flaw that an unauthenticated attacker can trigger merely by reaching a machine over the internet. Its CVSS vector specifies local attack access, low attack complexity, no privileges required, and required user interaction.
That combination points to a familiar developer endpoint risk: an attacker still needs a path to the user and a way to induce an action, but does not need pre-existing credentials on the target computer. Microsoft has not publicly detailed the precise file type, project asset, extension behavior, or Visual Studio workflow involved. Administrators should resist filling in those blanks with assumptions.
The potential result is nevertheless serious. Microsoft’s vector assigns high impact to confidentiality, integrity, and availability, meaning successful exploitation could expose code or secrets accessible to the developer, modify local work, or disrupt the workstation. On a machine that has access to source repositories, package registries, code-signing material, cloud subscriptions, or production deployment systems, the impact can extend well beyond a single IDE session.
The advisory does not indicate active exploitation. CISA’s Stakeholder-Specific Vulnerability Categorization data, as reflected by the NVD record on July 15, lists exploitation as none and automation as no. That is useful triage information, but it is not a reason to postpone the update: Visual Studio vulnerabilities become more operationally attractive once patch diffs and updated binaries give researchers a clearer view of what changed.

Three Visual Studio Lines Need Attention​

The affected-product list is narrower than “all Visual Studio,” but broad enough to catch organizations that intentionally hold separate channels for compatibility and support reasons. According to Microsoft’s submitted product data, the vulnerable ranges are:
  • Visual Studio 2022 version 17.12 from 17.12.0 through versions before 17.12.22.
  • Visual Studio 2022 version 17.14 from 17.14.0 through versions before 17.14.36.
  • Visual Studio 2026 versions before 18.7.4.
The version boundaries matter. A machine on Visual Studio 2022 17.12.21 remains exposed; a machine updated to 17.12.22 is outside the affected range. The same distinction applies to 17.14.35 versus 17.14.36, and to any Visual Studio 2026 installation below 18.7.4.
Visual Studio 2019 is not named in the affected configuration published for this CVE. Neither is Visual Studio Code. Those products have their own servicing tracks and should not be treated as affected by CVE-2026-47305 simply because they share a vendor or developer audience. Conversely, organizations should not let a healthy Visual Studio Code update posture create false confidence about the full Visual Studio IDE.
The version check should cover more than primary developer laptops. Build Tools installations, dedicated build agents, lab machines, shared Remote Desktop development hosts, persistent virtual desktops, and template images often lag behind interactive desktops because their update path is deliberately controlled. Those are precisely the systems where local code execution can become a build-pipeline or software-supply-chain concern.

The Fix Is an IDE Update, Not a Mitigation Exercise​

Microsoft has published a fixed version for every affected line, which means patching—not a registry workaround or a broad feature disablement—is the supported response. Developers using the Visual Studio Installer should update the installed instance and confirm the post-update version before returning to normal project intake.
For managed estates, Microsoft’s Visual Studio administration guidance is more relevant than standard Windows Update reporting. Microsoft Learn notes that administrator update packages can be obtained through the Microsoft Update Catalog and applied to installations or network layouts for their relevant channels. Enterprises using Microsoft Endpoint Configuration Manager, Microsoft Intune, WSUS-connected update processes, or internal Visual Studio layouts should validate that the intended package actually reaches the relevant channel.
A sensible first-pass response is:
  • Inventory Visual Studio 2022 17.12, Visual Studio 2022 17.14, and Visual Studio 2026 installations, including Build Tools where present.
  • Prioritize workstations used to open externally sourced repositories, project files, extensions, samples, or archive attachments.
  • Update each affected line to its specified fixed version or a newer supported release.
  • Refresh network installation layouts so that newly provisioned machines do not receive a vulnerable installer payload.
  • Recheck version compliance after deployment rather than relying only on a successful software-distribution job.
That last step is particularly important for Visual Studio because the product’s channels and components can diverge across an estate. A device may report that Visual Studio is installed while still being pinned to an older minor release, an obsolete layout, or a maintenance window that blocked the security update.

Why User Interaction Still Deserves Urgency​

The requirement for user interaction should change the response shape, not reduce it to a low-priority ticket. For engineering teams, accepting content is part of daily work: cloning repositories, opening pull-request branches, testing customer reproductions, unpacking samples, and installing tools. Social engineering that targets a developer does not need to resemble a conventional phishing campaign; it can arrive as a bug report, proof-of-concept, dependency update, or collaboration request.
Until every endpoint is updated, teams should apply ordinary caution around untrusted project material and avoid opening unsolicited repositories or attachments directly on privileged development systems. That is a temporary exposure-reduction measure, not an alternative to the patch. The absence of public technical detail means security teams cannot credibly claim that a particular project setting, extension policy, or endpoint-control product eliminates the risk.
The more meaningful control is separation of duties. Development machines that carry elevated local privileges, production cloud credentials, signing certificates, or deployment access should already be treated as high-value endpoints. CVE-2026-47305 is a reminder that an IDE is not merely a text editor; it is an execution environment deeply connected to compilers, debuggers, package managers, source control, local services, and often privileged infrastructure.

The Next Signal Will Be Patch Adoption​

As of July 15, the NVD entry remains marked as awaiting enrichment, and Microsoft has not publicly supplied an exploit narrative beyond the protection-mechanism failure and local code-execution outcome. The available evidence supports prompt remediation but not speculation about attack chains, vulnerable components, or detection signatures.
For Windows administrators, the immediate milestone is therefore measurable: no affected Visual Studio 2022 17.12 instance below 17.12.22, no affected 17.14 instance below 17.14.36, and no Visual Studio 2026 instance below 18.7.4. Once that inventory is clean—including layouts and build hosts—CVE-2026-47305 becomes a closed servicing task rather than an unquantified risk sitting inside the development toolchain.

References​

  1. Primary source: MSRC
    Published: 2026-07-14T07:00:00-07:00
 

Back
Top