It’s the highest-ever vulnerability score in .NET’s history — a staggering 9.9. The issue has been open for a week now, and the developer community is buzzing with concern. Let’s take a closer look at what’s happening, why everyone is talking about it, and what it means for developers and organizations worldwide.

Putting It Into Perspective

To understand the gravity of this, recall the Log4J vulnerability — the one that was so severe it made BBC News. That vulnerability scored a 10.0, the highest possible rating on the CVSS scale. In fact, Microsoft even funded a professionally produced documentary highlighting how terrifying the Log4J “Log4Shell” incident was.

Now, Microsoft has announced a 9.9 vulnerability in .NET — almost on par with Log4J. The announcement immediately triggered waves of confusion, fear, and countless awkward conversations across IT departments worldwide.

The Typical Conversation Happening Everywhere

Here’s what this looks like in practice.

Boss: “This new 9.9 score security issue in .NET just showed up on my Super Expensive Executive Security Dashboard 3000. Remember the Log4J thing four years ago? That was a 10. This seems close. Are we vulnerable?”

Full-Stack Hero Clyde: “It’s okay, boss. The .NET team has released a patch.”

Boss: “This issue has been in .NET for years. How do we know we haven’t already been hacked?”

Clyde: “We don’t know…”

And that’s the crux of the problem — there is no clear guidance from the .NET security team. Developers are left without any official direction on what to check, how to detect breaches, or how to verify whether they’re affected.

You could comb through your logs — assuming you’ve actually kept them — but beyond that, you’re largely on your own.

No Guidance, No Clarity

Understandably, the lack of transparency has angered many in the developer community. Questions are being raised directly to Microsoft engineers like Barry Dorans, who’s been active in GitHub discussions. Unfortunately, the answers have not been particularly reassuring.

For example:

  • Q: Is the app vulnerable if hosted with IIS? Does IIS mitigate this?
    A: “That’s a question for the IIS product group. I cannot speak on their behalf.”

  • Q: Does Azure Front Door (Microsoft’s WAF) mitigate this vulnerability?
    A: “That’s a question for the Azure Front Door product group. I cannot speak on their behalf.”

  • Q: When will Azure App Service update their runtime?
    A: “That’s a question for Azure App Service. I cannot speak on their behalf.”

  • Q: Will there be a patch for .NET 6?
    A: “No, it’s end of the line.”

Even when asked for practical examples of how the vulnerability could be exploited, the response was blunt:

“As I’ve said above — no.”

Azure App Service Still Running Vulnerable Versions

One week after the vulnerability was made public, testing new Azure App Service instances shows that they’re still running .NET 8.0.16, which is vulnerable. The safe version — 8.0.21 — has not yet been rolled out.

This is particularly frustrating, considering how quickly Microsoft integrates updates elsewhere. For instance, GitHub Copilot had access to GPT-5 the same day OpenAI released it. So why is updating a .NET runtime taking so long, especially for something tagged as a 9.9 CVE?

Microsoft’s Official Response

The App Service team published a blog post stating that they are “working closely with the .NET team to address issues impacting our ability to deliver updates in the .NET runtime versions provided by the platform on Windows.”

They’ve also mentioned developing a load balancer patch to mitigate the vulnerability for both Windows and Linux instances. However, the blog hasn’t been updated to confirm whether that patch has been deployed.

In the meantime, Microsoft advises developers to use self-contained deployments — compiling your app with --self-contained and manually selecting a runtime version. This is currently the only reliable way to ensure your .NET apps are patched on Azure.

Community Efforts and Testing

Interestingly, the team at HeroDevs — who sell patches for out-of-support runtimes like .NET 6 — released a GitHub repository to test whether your runtime is vulnerable.

Their test app is a simple console tool that sends “request-smuggled” HTTP packets and checks for exceptions. On the vulnerable .NET 8 runtime, the test fails; on the patched .NET 10, it passes.

But this test doesn’t prove any real exploitability. It only shows that the new runtime handles malformed requests differently — not that attackers can actually bypass authorization or access restricted actions.

Breaking Down the Vulnerability

Let’s attempt to understand what might be happening here.

The issue appears related to HTTP request smuggling. Essentially, a malicious actor hides an additional HTTP request (like a DELETE) within another valid request using HTTP chunking.

For example:

  • A GET /user request that anyone can access (requires User role)

  • A DELETE /user request that requires Admin role

If both requests are smuggled together, the server might process them separately. Normally, Kestrel (the .NET web server) throws a BadHttpRequestException, which is safe.

However, if your app removes authorization checks and delegates them to an external gateway (like a WAF or API gateway), that external service might miss the hidden DELETE request. Your app then processes it as valid — a potential security flaw.

In short:

  • Apps relying on external authorization could be affected.

  • Apps that perform authorization internally in .NET code are likely safe.

  • Web Application Firewalls (WAFs) should detect malformed requests — if properly configured.

A Call for Better Communication

Despite the technical nuances, the biggest issue isn’t the vulnerability itself — it’s the lack of communication.

“Barry, please — as the head of .NET security — communicate better. Write a detailed blog post explaining what’s actually happening and how we can check if our applications are affected.”

Because labeling a vulnerability as 9.9 without providing actionable guidance does one of two things:

  1. Makes it seem like something huge is being hidden.

  2. Or, it creates unnecessary panic — the classic “crying wolf” scenario.

If the vulnerability were rated a 7 or 8, most developers would quietly patch and move on. But a 9.9 makes everyone nervous, especially when Azure services themselves remain unpatched.

Final Thoughts

This situation highlights an important truth: security is not just about patching code — it’s about managing trust and communication.

Microsoft’s .NET security leadership needs to do more than issue CVE scores. They must guide developers, explain risks clearly, and ensure Azure environments stay up-to-date.

Until then, the only reliable mitigation for developers is to deploy self-contained apps with updated runtimes — and keep monitoring for official updates.