Is your .NET vulnerability report going to get a CVE?
Recently, we’ve seen an increase in .NET vulnerability reports that fall into what we would call “bug-bug” territory rather than security vulnerability territory. To help guide future vulnerability research, we have a set of framing guidance.
Recently, we’ve seen an increase in .NET vulnerability reports that fall into what we would call “bug-bug” territory rather than security vulnerability territory. We understand why this can be frustrating, especially when a bug is later fixed after we have said, “This is not a vulnerability.” However, a bug fix does not automatically imply that the issue warranted a CVE.
Many of these reports are now backed by AI-generated findings. We do our best to explain our reasoning to each finder, but new finders often arrive with the same conclusions and the same questions.
To make that reasoning clearer, and to help guide future vulnerability research, Levi put together a set of framing guidance. The result is two important documents that describe our baseline security assumptions—things that are always true, even when they are not explicitly called out in documentation—and explain what is, and is not, considered a .NET vulnerability. These documents capture more than 15 years of vulnerability discussions that Levi and I have had with researchers, MSRC, and internal teams.
The baseline security assumptions document defines what we mean by fully trusted. One important distinction is that .NET is a framework, not an application, and AI-generated reports often miss that distinction. The key takeaway is that any entity that can legitimately influence program flow is fully trusted, including administrators and non-administrators. This differs from the promises Windows makes because our scope is an application written in .NET, not the host it runs on. Non-administrators can configure and supply operational input to an application, and therefore influence its flow, so under our model they are fully trusted.
The guidance also makes clear that diagnostic tools are fully trusted. We have received reports along the lines of, “Your debugging tool allows me to inspect the memory of an application I am running, so I can see secrets, and this is a vulnerability.” Inspecting memory is the purpose of a debugging tool; it is not, by itself, a vulnerability. The same reasoning applies to dump files. If you have a dump file and run our tools over it, we assume that you legitimately have that dump file. Protecting the dump file is an OS-level concern, not a .NET concern.
We also assume that the OS protects certain directories, such as installation directories and user profile directories. If an application is installed in a world-writable directory, that is an installer concern, not a .NET concern. From .NET’s perspective, the directory from which an application runs is fully trusted.
Similarly, anything that configures .NET or the application is considered trusted. That includes environment variables, configuration files, connection strings, and similar inputs.
Vulnerability Theory approaches the question from the other direction: it explains what we consider a vulnerability by first setting out what is not a vulnerability. We think in terms of privilege and the CIA triad. Many submissions are reliability bugs rather than security bugs, while others describe security-relevant behavior that does not have enough impact to cross into CVE territory. The line that must be crossed is an increase in privilege.
By publishing these documents, we hope to help researchers focus their time on issues that are more likely to result in a CVE or a bounty payout. For those of you using AI to assist with research, these rules can also serve as useful baselines that steer AI-driven investigation toward more productive areas.
None of this is meant to discourage you from submitting reports to MSRC. Quite the opposite: the goal is to make our expectations clearer, including why a response may say, “Not a vulnerability.” The best part of my job is the hour I spend each week with the MSRC Bug Bounty team approving bounty payouts. Help me spend more of Microsoft’s money.