CVE-2026-103572 is a remote code execution vulnerability that Microsoft released on October 13, 2026, rated Important with a CVSS score of 8.8. According to researcher Johann Rehberger's write-up, a check in Copilot's file-editing tool compared file names as text, and because Windows ignores a trailing dot, a name ending in a dot passed the check and reached a protected configuration file. Microsoft's advisory says exploitation needs a user to interact with Copilot and a prompt injection, and lists fixed builds 17.14.42 and 18.10.4. The lesson for anyone commissioning agents: a restriction is only as strong as the code that enforces it, so check the resolved target and enforce critical limits independently of the agent. We did not test this.
This decode is based on Microsoft's security advisory and on one researcher's published write-up, both read on November 2, 2026, and we did not test the software. Technical findings are attributed to those sources, and our recommendations are marked as ours. The reason to read it, if you commission or run AI agents rather than write code, is a pattern: a rule such as "the agent may not edit its own settings" was enforced by a few lines of code inside the agent's own tool, and a detail of how Windows names files made those lines miss.
What is CVE-2026-103572?
Microsoft's Security Update Guide lists CVE-2026-103572 as a remote code execution vulnerability titled "Visual Studio Tools for Applications and SQL Server Management Studio Remote Code Execution Vulnerability". It was released on October 13, 2026 and last updated on October 16. Microsoft rates it Important with a CVSS 3.1 base score of 8.8 and classes the weakness as CWE-94, improper control of code generation. At original publication, Microsoft's exploitability assessment read "Exploitation Less Likely", with "Publicly disclosed: No" and "Exploited: No". Those fields describe the day of publication, so check the page for its current state.
The advisory's FAQ explains the link to AI. It says an attacker can deliver a malicious prompt remotely, that a user must interact with Copilot for exploitation to occur, and that prompt injection can escalate into code execution when the compromised prompt makes integrated tools run unintended commands. Microsoft's acknowledgements credit Johann Rehberger of Embrace The Red and a second reporter from TXOne.
How did a trailing dot get past the guard?
This part comes from the write-up by Johann Rehberger, published on October 13, 2026. According to the write-up, Copilot in Visual Studio has a check that decides whether an edit to sensitive files, such as its own configuration files, needs the user's confirmation. That check compared the requested file name to a list of protected names as plain text. Under ordinary Win32 file-path handling, a trailing period at the end of a file name is normalized away, so a name such as .mcp.json. looks different to the check but lands on the same protected file, .mcp.json, when it is written. The write-up's author reads the fix as a call that resolves the path to its canonical form before comparing; that is the author's inference, and Microsoft has not described the fix that way.
The write-up reports further weaknesses in the same code. We leave those details to the write-up, which is linked below, because they add no lesson for a buyer. This is a separate issue from the Copilot address-spoofing problem in our EMBRACE decode: both have October 13 fix dates in the sources, but they involve different components, attack paths and version numbers.
What could an attacker do, and what had to be true?
According to the write-up, an attacker who could get the agent to follow hidden instructions could use its write access to change configuration so that the editor launches a program of the attacker's choosing; the write-up describes this for Visual Studio and for SQL Server Management Studio. The precondition is the important part. In the advisory's words, a user has to interact with Copilot, and the instructions have to reach the agent through prompt injection, for example inside a file the user opens or data a connected tool returns. The write-up does not describe an attack that works without a person using the agent, and Microsoft's own assessment at publication was "Exploitation Less Likely".
Which versions are fixed?
On November 2, 2026, the product table in Microsoft's advisory lists two rows, both for Visual Studio: Visual Studio 2022 version 17.14 with fixed build 17.14.42, and Visual Studio 2026 version 18.10 with fixed build 18.10.4. The advisory's revision note says the October 16 update only added download and KB links and left the fixed builds unchanged. The table does not list SQL Server Management Studio, although the advisory title names it; the write-up says both products share the same code. We did not find build numbers for SQL Server Management Studio in the table. Microsoft's SSMS 22 release notes list version 22.11.0, released October 13, 2026, which updates its bundled Visual Studio component to 18.11.0, and version 22.11.3, released October 29, 2026, whose security entry points to the Visual Studio release notes. They do not name this CVE, so we cannot state an SSMS-specific fixed build; check Microsoft's pages and keep SSMS on a current release rather than treating Visual Studio build numbers as SSMS versions.
What did the timeline look like?
| Date | Event | Source |
|---|---|---|
| August 4, 2026 | Initial path bypass reported to Microsoft's security response center | Write-up |
| September 16, 2026 | Microsoft confirmed the vulnerability | Write-up |
| October 13, 2026 | Fix released in the monthly security update; advisory published | Advisory and write-up |
| October 16, 2026 | Advisory updated with download and KB links; fixed builds unchanged | Advisory |
What is the lesson for people who build or buy agents?
These are our reading and recommendations, not Microsoft's or the researcher's. The agent in this case was not the weak point by itself; the weak point was where the limit lived. A rule enforced by code inside the agent's own tool is only as strong as that code, and the code compared a name before the system had finished resolving what the name pointed to. Three habits follow for anyone commissioning an agent that touches real systems:
- Check the resolved target, not the requested name. A limit such as "never write to X" has to be tested against what the system will actually open, after names, links and relative paths are resolved. Normalizing a path is not a cure-all: links, and a file changing between the check and the write, need separate care.
- Enforce critical limits independently of the agent. Scoped credentials, an allow-list held by the host and permissions on the files themselves still hold when the agent has been talked into something. A check inside the agent's tool can be sound, but it is only as good as its implementation, so it should not be the only line.
- Treat an agent's execution-related settings as security-sensitive. Configuration that selects executable paths or starts tools automatically can turn a file write into code execution.
How does this connect to the EMBRACE research?
It is a second case of the same shape. In our EMBRACE decode, researchers report that an assistant's built-in browser gave a web page abilities a normal browser denies, and that in one demonstration the agent retried a blocked command outside its sandbox. The mechanics differ; in both, a protection that sat inside the product was the one that gave way. For the controls GitHub describes for its own cloud agents, see our GitHub Copilot teardown, and for how guardrails are usually layered in production, see why AI agents break in production.
What should you ask a vendor or your own team?
- Where is each limit on the agent enforced: inside the agent's code, or by the system it runs on?
- Is the check made before or after the target has been resolved?
- If the agent's own check fails, what is its account still allowed to do?
- Which AI features run inside the editors your developers and contractors use, and on which versions?
- Who can see the agent's configuration, and who is told when it changes?
What does this mean if you run sales, logistics or retail?
You probably do not use Visual Studio, but the agents you commission will have rules like "do not touch this table" or "do not send above this amount". The question to put to whoever builds them is where those rules are enforced and how that was tested, not whether the agent was told. We are not claiming that any product is unsafe, and we have not tested this one.
What is still unknown?
Microsoft's table lists fixed builds for Visual Studio only, so the status of other affected builds is for Microsoft's page to say. The advisory's exploitability fields describe October 13 and may change. In the two documents we read we found no report of exploitation against real users, which is not proof that none has occurred. We rely on the advisory and one write-up, and we have not reproduced anything. Other outlets have written about this issue; we cite only the two primary documents we read. If you spot an error, tell us and we will correct the page.