CVE-2026-47285: Update Visual Studio Code to 1.132.1

The important detail buried beneath the “Information Disclosure” label is the weakness classification. Microsoft’s CVE record identifies CWE-77, improper neutralization of special elements used in a command—in other words, command injection. Microsoft says an unauthorized attacker can use that condition to disclose information over a network. That is a more meaningful description than the advisory title alone: this is not framed as a local crash, a permission mistake, or a file-reading bug. It involves attacker-controlled input reaching a command-processing path, with data exposure as the stated outcome.

Microsoft published the advisory on August 11, 2026. The CVE Program’s official record shows the identifier was reserved on May 18, made public at 14:00 UTC on August 11, published into the CVE system at 17:03 UTC, and updated again at 18:48 UTC the same day. Those timestamps resolve an apparent oddity in some third-party Patch Tuesday coverage: CVE-2026-47285 was reserved months before disclosure, but it was not public until August 11.

The score says user interaction remains part of the attack path​

Microsoft gave CVE-2026-47285 a CVSS 3.1 base score of 6.5, rated Medium, with the vector

. In practical terms, the vendor’s scoring describes a network attack that requires no attacker privileges and has low complexity, but does require user interaction. Successful exploitation can cause a high confidentiality impact; Microsoft assigns no integrity or availability impact.

The user-interaction requirement is material. It means this is not described as a wormable service flaw or a zero-click compromise of every VS Code machine exposed to a network. An attacker still needs to persuade a developer to take some action involving a malicious resource or workflow. Microsoft has not said what that resource is: the public record does not identify a repository, workspace, task definition, extension, terminal command, remote-development feature, chat interaction, URI handler, or file format involved in the vulnerable path.

That omission limits the value of broad “avoid opening untrusted projects” advice. It remains sensible operational hygiene, especially on developer endpoints with access to source code and credentials, but it cannot yet be presented as a confirmed mitigation for this CVE. Administrators should avoid inventing controls around a mechanism Microsoft has not disclosed.

Microsoft’s temporal metrics carry three other signals: the vulnerability report is confirmed, an official fix is available, and exploitation is unproven. The record does not say the issue is publicly disclosed beyond the advisory itself, nor does it say it is being exploited in the wild. There is no public proof of concept, researcher acknowledgment, or technical write-up attached to the CVE record as of August 11.

Version 1.132.1 is the remediation boundary​

The most operationally useful field in Microsoft’s record is the version range. It explicitly marks Visual Studio Code 1.0.0 up to, but not including, 1.132.1 as affected. A machine on 1.132.1 or a newer release falls outside Microsoft’s published affected range.

That wording has a consequence for organizations that treat VS Code as an unmanaged developer convenience rather than a security-managed application. The affected range reaches back to the product’s earliest releases, so there is no supported “old but safe” branch identified in the advisory. A long-lived installation that has been held back for extension compatibility, build tooling, or developer preference should be treated as vulnerable unless it has reached 1.132.1 or later.

Microsoft’s public record does not distinguish between Windows, macOS, and Linux builds, nor does it name a separate affected component such as the Windows installer, the Electron runtime, the integrated terminal, Remote Development, Dev Containers, WSL integration, or a particular extension. The safest reading is that the advisory covers the Visual Studio Code product version rather than a Windows-only binary. Windows endpoint teams should therefore avoid using operating system as an exclusion criterion during inventory.

For managed fleets, the check should be version-based rather than installation-based:

• Systems running Visual Studio Code 1.132.0 or older should be scheduled for update to 1.132.1 or newer.
• Systems where version reporting is incomplete should be investigated, because the advisory’s lower boundary is effectively every historical VS Code release.
• Teams that pin VS Code packages or suppress automatic updates should review the pin before assuming the normal update mechanism will remediate the issue.
• Security teams should confirm which package source supplies VS Code on Windows, because Microsoft’s record names the corrected version but does not provide separate deployment guidance for Microsoft Store, winget, enterprise software distribution, or manually installed user-scoped copies.

The last point is especially relevant on Windows. VS Code is frequently installed per user, outside the administrative software inventory path that tracks machine-wide applications. A corporate endpoint platform may show a compliant system while a developer retains an older user-level copy in their profile. This advisory does not create that visibility gap, but it exposes it.

The public advisory leaves the exploit mechanism undisclosed​

Microsoft’s description establishes the impact and vulnerability class, but it does not provide a reproducer or an attack narrative. The vendor has not said whether command injection happens before or after Workspace Trust, whether a malicious repository alone is sufficient, whether an extension must be installed, or whether the attacker needs to control a remote service that VS Code contacts.

That silence is understandable for a newly published flaw, but it changes how defenders should prioritize it. A CVSS 6.5 issue with high confidentiality impact deserves prompt remediation on developer workstations because VS Code commonly has access to proprietary code, local configuration, SSH keys, cloud credentials, tokens, and active terminal sessions. Still, there is no evidence in the public record that warrants emergency isolation of every VS Code endpoint or a conclusion that stored secrets have already been exposed.

The command-injection classification does justify a narrower review of high-risk workflows while updates roll out. Organizations should pay particular attention to developers who routinely open code from external contributors, use unfamiliar repositories in local clones, work with remote workspaces, or have VS Code connected to production-capable credentials. Those are the environments where a confidentiality-only impact can still become consequential: exposed tokens or environment values can become the first step in a larger intrusion even when the vulnerability itself does not modify files or execute arbitrary code on the host.

Microsoft’s official CVE data describes a network vector and zero attacker privileges, but that should not be mistaken for anonymous internet exploitation of a developer laptop. The required user interaction remains the primary control reflected in the score. The gap between “network” and “zero-click” is exactly where social engineering, malicious project content, and developer trust decisions tend to sit.

A June roundup exposes the risk of relying on Patch Tuesday lists​

SonicWall’s currently available June 2026 Microsoft security bulletin roundup includes CVE-2026-47285 in its information-disclosure list, alongside the related Visual Studio Code CVE-2026-47284. But the official CVE record for CVE-2026-47285 says its public disclosure date was August 11, not June 9 or June 10.

The available SonicWall page is labeled as June coverage, but it does not provide a revision history showing whether CVE-2026-47285 appeared in the article when it was first published or was added later. That means the page should not be used to conclude that Microsoft silently shipped a June fix for this vulnerability, or that the flaw had been publicly known for two months. The authoritative record supports a different conclusion: Microsoft reserved the identifier in May and disclosed the vulnerability on August 11.

This is more than a date-cleanup exercise. Vulnerability-management tools and security bulletins often ingest CVE identifiers before all fields stabilize, then backfill products, fixed versions, or dates later. For CVE-2026-47285, the version range and publication timestamps in Microsoft’s own CVE record are the reliable remediation anchors; the surrounding monthly roundup is context, not patch evidence.

The next concrete checkpoint is the availability of Visual Studio Code 1.132.1 across the channels your organization uses. Until Microsoft publishes a fuller technical explanation, the defensible response is to update affected installations, verify the installed version rather than assuming automatic updates succeeded, and treat unexplained exceptions as vulnerable developer endpoints rather than harmless legacy tooling.