.NET Brotli fix: update this week

If your business runs a web app or an API built on .NET, there's an update to install this week. On 25 October Microsoft put out an emergency release of .NET to fix the same Brotli flaw I wrote about for Node.js and Python.

Yes, the Brotli flaw again. I did say plenty of software uses it.

What happened

Microsoft's announcement covers CVE-2026-111497, a buffer overflow in the code .NET uses to unpack Brotli compressed data. According to the advisory on GitHub, an attacker with no login may be able to read or corrupt the app's memory. That could leak information, crash it, or give the attacker more access than they should have.

Microsoft scores it 8.1 out of 10. Its own guide lists the flaw as publicly known but not exploited, and rates exploitation "more likely". The Register's report also says there's no evidence yet of criminals using it in successful attacks. Microsoft's advice is to update "as soon as possible".

The fixed versions are:

.NET 8: 8.0.33
.NET 9: 9.0.22
.NET 10: 10.0.14
.NET 11 preview: Release Candidate 3

The same release also fixes a second flaw that only affects some Linux installs, and finishes two fixes from the 13 October release that turned out to be incomplete. So it's worth installing even if Brotli doesn't apply to you.

Does it affect you?

The good news is that most .NET apps probably aren't exposed. Microsoft says that having the affected version installed isn't enough on its own. An app is only at risk if it unpacks Brotli data from an attacker, and it would have to do that in one of three ways:

ASP.NET Core request decompression, with Brotli switched on
HttpClient automatic decompression, with Brotli included
The Brotli code in .NET used directly, through BrotliStream or BrotliDecoder

The first two aren't switched on by default. But unless you wrote the app yourself, you probably don't know which of these it does. That's why I'd update anyway rather than spend an afternoon reading someone else's code.

If you're on the older .NET Framework, the one that comes with Windows, Microsoft says it is "not affected". This is only about .NET 8 and later.

What to do this week

1. Find out which versions you have. On each server, Windows or Linux:

dotnet --list-runtimes

Anything below the version numbers above needs updating. Look at the Microsoft.NETCore.App and Microsoft.AspNetCore.App lines.

2. Install the update. Download it from Microsoft, or use your Linux package manager if that's how .NET got onto the server. Then run the command again and check the numbers have changed.

3. Restart the apps. A running app keeps using the old code until it restarts. On Windows with IIS, recycle the app pool or restart the site. On Linux, restart the systemd service.

4. Watch out for self-contained apps. Some .NET apps carry their own copy of .NET instead of using the one on the server. Microsoft says that updating the server does nothing for these. The app has to be rebuilt and redeployed by whoever looks after the code. The same goes for anything published as NativeAOT.

5. Rebuild your containers. If the app runs in Docker, the container has its own .NET. Rebuild the image from Microsoft's updated base images and redeploy.

6. Test something afterwards. Load the site, log in, and check the bits that make money still work.

If you can't update straight away and you know your app uses Brotli in one of the three ways above, the advisory gives workarounds, such as taking Brotli out of the decompression settings. It also warns against adding settings your app doesn't already have. That's a job for your developer.

The bigger job: .NET 8 and 9 are nearly out of support

This is the part I'd circle in red. According to Microsoft's support policy, .NET 8 and .NET 9 both reach end of support on 10 November 2026. That's two weeks from today.

After that, they get no more security fixes. If another Brotli turns up in December, an app on .NET 8 or 9 won't get a patch. .NET 10 is supported until 14 November 2028, so that's where they need to go.

Moving an app from 8 to 10 isn't just installing an update. Someone has to change the target version in the code, rebuild it, test it and deploy it. For a small, tidy app that might take a day. For something built years ago by someone who's since moved on, it could take longer. Either way, it won't happen in two weeks unless somebody starts now.

Anything on .NET 6 or 7 is already out of support and has been for a while.

The bigger point

This is my third Brotli post in a week. One flaw in a shared library has turned into separate updates for Node.js, Python, curl's library and now .NET, each installed a different way.

That's why it helps to know what's on each server: which languages, which versions, and who updates them. If you're not sure, that's what my server health check is for.