Microsoft has released emergency security updates for .NET 8, 9, 10 and 11 to address multiple vulnerabilities, including a buffer overflow flaw that could allow unauthenticated attackers to access or corrupt application memory.
The critical buffer overflow vulnerability, CVE-2026-111497, affects all platforms and could lead to information disclosure, denial of service or privilege escalation. Microsoft also patched CVE-2026-114148, a Linux vulnerability that could allow local attackers to modify files and gain elevated privileges.ㅤ
Microsoft additionally reissued fixes for two vulnerabilities after discovering that its October 13 updates had not fully addressed them. The company urged immediate patching, noting that organizations running self-contained applications or containers must rebuild and redeploy them rather than simply updating their systems.
ㅤDenis Calderone, Principal / CTO, Suzu Labs:
“Organizations that did everything right on October 13 are still running vulnerable code, and Microsoft’s own advisories say so. The flaw is getting the headlines, but the detail that should stop security teams cold is that CVE-2026-70197, the SocketAsyncEventArgs memory corruption fix, was disclosed in the October 13 advisory but never made it into that release. The Blazor WebAssembly debugger fix the same day, CVE-2026-102870, shipped with a packaging error that kept the corrected component from reaching machines. Unfortunately, we have two vul announcements, but neither got fully delivered.
“This lands in an awkward spot for the patching process most organizations actually run. CVE-2026-70197 is an unauthenticated out-of-bounds write in the socket layer, and the new Brotli flaw, CVE-2026-111497, is an out-of-bounds write in a decompression library embedded across .NET 8 through 11. Anyone relying on a patch report dated October 13 has been carrying a false green light for almost two weeks, and a version check would not have caught it, because on paper those deployments looked current. When the vendor’s release notes are the source of truth and the source of truth was wrong, verification has to mean more than a version number.
“The operational part turns this from a bad afternoon into a bad week. Self-contained applications and containers bundle the .NET runtime inside the artifact, so installing the October 25 update on the host changes nothing for them. They have to be rebuilt and redeployed. Ask yourself whether you can list, right now, which applications in your environment are self-contained versus framework-dependent, and where they run. Most can’t, and that inventory gap is what turns a one-day emergency patch into a two-week project.
“So, you should be updating the runtimes, rebuilding and redeploying every self-contained application and container, and updating the Blazor NuGet packages directly instead of trusting the shared runtime. For anything that can’t be rebuilt this week, the Brotli exposure has a configuration work around. The work around is simple enough. Brotli decompression is off by default, so the first question is whether you turned it on anywhere. If you did, remove “br” from request decompression and drop Brotli from HttpClient automatic decompression. That is a config change you can ship in hours, and it is your bridge until the rebuild lands. Then confirm the runtime version actually running in production, not the one in the change ticket. The teams that verify just had a better two weeks than the teams that checked a box.”
ㅤ
John Strand, Owner, Black Hills Information Security:
“This story almost feels like Microsoft saw the PHP vulnerabilities, looked around, said, ‘Hold my beer,’ and handed us these .NET vulnerabilities.
“It’s been bad. Apparently, Black October isn’t done yet. These critical .NET vulnerabilities look like they’re hitting a large section of the websites that the PHP vulnerabilities missed.
“I do wonder if there were some .NET developers and Microsoft website maintainers feeling a little smug last week, thinking, ‘Well, good thing we weren’t running PHP.’ Now they have their own critical vulnerabilities to deal with.”
ㅤ
Seemant Sehgal, Founder & CEO, BreachLock:
“When vulnerabilities like CVE-2026-111497 are left unpatched, an attacker exploiting this chain can start with memory corruption inside a vulnerable .NET process, escalate privileges against the service account running it, and inherit whatever reach that account has. Enterprises typically grant those accounts more reach than they need.
“Teams that already know what runtime versions are running in production and who owns each one will patch this fast. The rest should start that inventory work now.”
ㅤIf you rely on .NET, you need to patch all the things and do it fast.
Related
This entry was posted on October 27, 2026 at 8:47 am and is filed under Commentary with tags Microsoft. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Microsoft issues emergency .NET patches
Microsoft has released emergency security updates for .NET 8, 9, 10 and 11 to address multiple vulnerabilities, including a buffer overflow flaw that could allow unauthenticated attackers to access or corrupt application memory.
The critical buffer overflow vulnerability, CVE-2026-111497, affects all platforms and could lead to information disclosure, denial of service or privilege escalation. Microsoft also patched CVE-2026-114148, a Linux vulnerability that could allow local attackers to modify files and gain elevated privileges.ㅤ
Microsoft additionally reissued fixes for two vulnerabilities after discovering that its October 13 updates had not fully addressed them. The company urged immediate patching, noting that organizations running self-contained applications or containers must rebuild and redeploy them rather than simply updating their systems.
ㅤDenis Calderone, Principal / CTO, Suzu Labs:
“Organizations that did everything right on October 13 are still running vulnerable code, and Microsoft’s own advisories say so. The flaw is getting the headlines, but the detail that should stop security teams cold is that CVE-2026-70197, the SocketAsyncEventArgs memory corruption fix, was disclosed in the October 13 advisory but never made it into that release. The Blazor WebAssembly debugger fix the same day, CVE-2026-102870, shipped with a packaging error that kept the corrected component from reaching machines. Unfortunately, we have two vul announcements, but neither got fully delivered.
“This lands in an awkward spot for the patching process most organizations actually run. CVE-2026-70197 is an unauthenticated out-of-bounds write in the socket layer, and the new Brotli flaw, CVE-2026-111497, is an out-of-bounds write in a decompression library embedded across .NET 8 through 11. Anyone relying on a patch report dated October 13 has been carrying a false green light for almost two weeks, and a version check would not have caught it, because on paper those deployments looked current. When the vendor’s release notes are the source of truth and the source of truth was wrong, verification has to mean more than a version number.
“The operational part turns this from a bad afternoon into a bad week. Self-contained applications and containers bundle the .NET runtime inside the artifact, so installing the October 25 update on the host changes nothing for them. They have to be rebuilt and redeployed. Ask yourself whether you can list, right now, which applications in your environment are self-contained versus framework-dependent, and where they run. Most can’t, and that inventory gap is what turns a one-day emergency patch into a two-week project.
“So, you should be updating the runtimes, rebuilding and redeploying every self-contained application and container, and updating the Blazor NuGet packages directly instead of trusting the shared runtime. For anything that can’t be rebuilt this week, the Brotli exposure has a configuration work around. The work around is simple enough. Brotli decompression is off by default, so the first question is whether you turned it on anywhere. If you did, remove “br” from request decompression and drop Brotli from HttpClient automatic decompression. That is a config change you can ship in hours, and it is your bridge until the rebuild lands. Then confirm the runtime version actually running in production, not the one in the change ticket. The teams that verify just had a better two weeks than the teams that checked a box.”
ㅤ
John Strand, Owner, Black Hills Information Security:
“This story almost feels like Microsoft saw the PHP vulnerabilities, looked around, said, ‘Hold my beer,’ and handed us these .NET vulnerabilities.
“It’s been bad. Apparently, Black October isn’t done yet. These critical .NET vulnerabilities look like they’re hitting a large section of the websites that the PHP vulnerabilities missed.
“I do wonder if there were some .NET developers and Microsoft website maintainers feeling a little smug last week, thinking, ‘Well, good thing we weren’t running PHP.’ Now they have their own critical vulnerabilities to deal with.”
ㅤ
Seemant Sehgal, Founder & CEO, BreachLock:
“When vulnerabilities like CVE-2026-111497 are left unpatched, an attacker exploiting this chain can start with memory corruption inside a vulnerable .NET process, escalate privileges against the service account running it, and inherit whatever reach that account has. Enterprises typically grant those accounts more reach than they need.
“Teams that already know what runtime versions are running in production and who owns each one will patch this fast. The rest should start that inventory work now.”
ㅤIf you rely on .NET, you need to patch all the things and do it fast.
Share this:
Like this:
Related
This entry was posted on October 27, 2026 at 8:47 am and is filed under Commentary with tags Microsoft. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.