The Copilot inside Visual Studio was slipped past its own guardrail by a single dot at the end of a filename. On October 13, 2026, security researcher Johann Rehberger publicly disclosed the technical details of vulnerability CVE-2026-103572, and Microsoft shipped the fix the same day in its October Patch Tuesday release. Rated Important for remote code execution with a CVSS score of 8.8, the flaw affects both Visual Studio and SQL Server Management Studio (SSMS).
One trailing dot, written into configuration files that should have been protected
The problem sits in the path validation of Microsoft.VisualStudio.Copilot.Core.dll, a component shared by both products: appending a dot to the end of a filename bypasses the check and lets Copilot write into settings and configuration files that should be protected, such as MCP configuration and Visual Studio settings files, which in turn enables arbitrary command execution. The researcher also demonstrated another path: a third party hides malicious instructions in files or external data that Copilot processes, using indirect prompt injection to induce the write, without the developer having to do anything deliberate. Because SSMS shares the same shell and code base as Visual Studio, the same flaw also hits the database administrators' tool. Affected releases include Visual Studio 2022 version 17.14 and Visual Studio 2026 version 18.10, fixed in builds 17.14.42 and 18.10.4 respectively; Microsoft's fix normalizes the path before validation, eliminating tricks such as trailing dots in advance. Microsoft says there is no confirmed exploitation in the wild so far, and exploitation requires the user to interact with Copilot. The researcher had reported the issue to Microsoft back in August.
If you use Visual Studio or SSMS, update first
The order of action is clear. First, update Visual Studio and SSMS to the fixed builds above, prioritizing machines with Copilot installed in enterprise environments. Second, until the patch is in place, do not let Copilot casually process repositories of unknown origin, external files, or content returned by MCP services, especially operations that write configuration automatically. The nasty part of this class of flaw is that the entry point looks like merely asking the assistant to read a file, while the landing point is the developer machine itself, which usually holds source code, cloud keys and release credentials.
Guardrails cannot rest on the model's good behavior
This vulnerability offers a concrete reminder for coding agents: when an assistant can write files, change configuration, set up tools and even execute commands, the security checks must live where the model cannot reach them, and must assume the model itself can be led astray by external content. A check as mundane as path validation is exactly the thinnest, and least dispensable, layer between an agent and the real system. Microsoft has closed the trailing-dot gap with path normalization this time, but problems of this kind will not disappear: as agents keep connecting to more local tools, every configuration file and executable they can touch deserves to be rechecked against the same standard.
