KEY POINTS:
- AI-powered development is mainstream, with close to half of developers reporting they use AI tools daily in their development processes.1 With non-developers using AI more frequently, the level of Vibe Coding in use may be immeasurable.
- Standard OS patches only update the standalone .NET runtime, not runtime copies bundled inside other tools, "patched" devices can still be vulnerable.
- A blind spot outside normal patch management is created when developers are slow to update critical tools like Visual Studio, which leave vulnerable SDKs installed.
- Some of the organizations' most valuable assets “Source Code” could be at risk.
- Vibe coding is creating a new class of developers reliant on AI coding agents that install .NET SDKs, causing this problem to extend outside the core development organization.
Even if your organization has AI coding tools fully under control, there's another risk most teams don't know about.
This isn't about whether you allow AI copilots or agentic coding tools, it's about a side effect they quietly leave behind. When an AI assistant or agent takes over part of the coding work, it also takes over installing dependencies, including whatever version of the .NET SDK a given project or task needs. It does this quickly, automatically, and critically, without cleaning up prior versions.
A person manually setting up a dev environment usually has some sense of "tidiness," they'll eventually go back and update or remove old components. An AI agent has no such instinct. It solves the task in front of it, installs what's needed, and moves on. Over time, a developer's machine ends up with several SDK versions installed side by side, none of which anyone consciously chose to keep or remove.
Where the Real Problem Hides
Microsoft ships security updates for .NET on a near-monthly basis, and a single update can address 10+ CVEs at once, ranging from high to critical severity. But these updates only replace the standalone runtime component, the one delivered through Windows Update or WSUS. They can't remove the runtime version an already-installed SDK still depends on. The update sees that dependency and skips the cleanup rather than break the SDK. And it's not just one runtime. Each SDK carries its own copies of the .NET Runtime, the ASP.NET Core Runtime, and the .NET Desktop Runtime, which all live side by side under the same `dotnet\shared` folder, one set per SDK feature band, with older ones removed only when nothing depends on them. By design, .NET SDK feature bands are meant to live side by side with each other, and nothing automatically removes SDKs from other bands or major versions.
That means a machine can show as "patched," pass a standard compliance scan, and still have a fully functional, vulnerable .NET runtime sitting inside a forgotten SDK, waiting for something to use it.
This isn't theoretical. A single developer machine can carry six shared runtime folders side by side, spanning three major .NET versions, each with its own ASP.NET Core Runtime, .NET Runtime, and .NET Desktop Runtime—all fully installed and usable. Matched against proper vulnerability content, the machine we observed surfaced a high-rated (CVSS 8.8) elevation-of-privilege flaw in ASP.NET Core, sitting in versions that had technically already been "patched" elsewhere on the machine.
Then There's Visual Studio
There's another layer to this blind spot: Visual Studio.
An SDK installed alongside Visual Studio isn't updated through Windows Update, WSUS, or the MU Catalog the way a standalone .NET runtime is. It only updates when the developer updates Visual Studio itself. And IDE updates, unlike OS security patches, get deferred far more often and for far longer, out of fear of breaking a working environment, waiting on plugin compatibility, or simply not being identified as an immediate priority.
The result is a double gap. AI tools are multiplying the number of SDK versions on a machine faster than before. At the same time, a large share of those SDKs live under Visual Studio's umbrella, outside the reach of standard patch management, which watches Windows Update, not the state of the IDE itself.
For enterprise environments, this means a company can have excellent OS patch compliance, a clean dashboard, and still be carrying fully functional and invisible vulnerable runtimes on developer machines for months, because standard scanning only checks for the presence of the updated standalone component, not what's still alive inside an SDK or a Visual Studio install folder.
And developer machines are rarely ordinary endpoints. Access to source code, credentials, and CI/CD pipelines makes them exactly the kind of target an attacker would choose first, given the choice.
The Fix Isn't Slowing AI Down
None of this means locking down AI coding tools. It means not treating "update installed" as a security indicator on its own, it only confirms the standalone component is patched, not what's still alive inside an SDK. The gap closes with visibility: correctly identifying which SDK versions are actually present on a machine, the same way you track runtimes, and treating cleanup as a low-risk, build-time fix rather than something to avoid touching.
The catch is that most organizations don't have this visibility today. Closing this gap usually means deploying yet another agent, which is one more thing to install, manage, and justify. That's the wrong trade for a gap this specific.
The more practical path is content-driven detection: using data your endpoint agent is already collecting — app inventory, installed components, patch state — and matching it against vulnerability content that understands cases like this one. No new deployment required, no additional footprint on developer machines, just a smarter read of data you already have.
We've built exactly this workflow, ".NET SDK and Runtime Orphan Versions Detection": detection logic that tracks SDK and Visual Studio installs as they happen, flags orphaned old versions left behind after an update, and offers guided cleanup, checking for build-time dependencies first, without touching anything already compiled and running. That's the difference between finding out about a gap like this from a security researcher's side project and finding out about it from your own platform before it becomes one.
AI has genuinely opened up development to a much wider group of people, and that's a good thing. But the speed at which code is now written and shipped means dev environment hygiene can no longer be an afterthought. The question isn't whether you can trust AI tools to write code. It's whether your organization can already see what they've left behind. If you're not sure, that's usually the first thing worth checking.
How Absolute Security Can Help
If you are concerned about the critical security hygiene oversight revealed in this research, request your no-cost 30-day trial of Absolute Resilience for Automation to discover how to streamline patching and remediation of OS, software and security vulnerabilities through automation to reduce risk and your attack surface.
