Microsoft delivers the missing .NET Windows fix in an out-of-band update

An earlier update is not enough evidence of remediation

Microsoft revised its CVE-2026-70197 advisory on October 25, 2026 to deliver .NET packages containing a fix missing from earlier updates. Windows .NET operators should review affected applications, particularly UDP services meeting the advisory’s implementation conditions. Microsoft rates the issue High,8.1 on CVSS3.1.

The original advisory was published on October 13. The new event is the October 25 out-of-band delivery of the missing fix, not a newly discovered CVE on October 26. An inventory showing a mid-month update is insufficient without checking the corrected package versions.

The affected path is more specific than every .NET website

On Windows, reusing SocketAsyncEventArgs across IPv4 and IPv6 datagram sockets can retain an undersized native address buffer during ReceiveFromAsync. That creates an out-of-bounds write. A socket is an application’s network endpoint; datagram processing commonly concerns UDP.

The CVE describes unauthenticated remote code execution. Merely finding .NET installed, or an ASP.NET website serving HTTP, does not establish that an application exercises the affected path. Review the platform, library version and actual network API usage.

CVSS describes severity under technical assumptions, not the probability of an individual company being attacked. The October 25 advisory reviewed here does not confirm an active exploitation campaign. Public technical details alone do not establish that a particular system has been compromised.

Match the corrected package to the deployed branch

The advisory lists Windows runtime packages in .NET 8 before8.0.33, .NET 9 before9.0.22 and .NET 10 before10.0.14, starting at each branch’s initial release. Corrected versions are8.0.33,9.0.22 and10.0.14. Match the exact package and architecture to Microsoft’s list; the .NET 8 scope also includes specified Mono packages.

The .NET 11 preview branch has its own affected range and corrected release candidate. Stable-production users should not move to a preview merely to address this CVE. Select a corrected version for the application’s existing branch and deployment model.

Microsoft’s .NET 8 download interface shows8.0.33 with an October 25 release date. The advisory identifies SDK 8.0.133 and8.0.427 for this branch. The NuGet page for Microsoft.NETCore.App.Runtime.win-x64 8.0.33 represents an internal runtime-distribution package; its generated package-install command is not a substitute for the application’s upgrade procedure.

Shared and self-contained deployments need different work

For an application using a machine-wide runtime, install the appropriate corrected runtime or SDK and restart the application as Microsoft instructs. If Visual Studio installed the SDK, review the Visual Studio update and the SDK versions actually delivered.

A self-contained application ships its own runtime. Updating the shared machine-wide installation does not replace those bundled files. Microsoft instructs affected self-contained applications to be rebuilt and redeployed. Include copies distributed to customers and deployment directories still in service.

Verify the actual running application

Friday Works recommends inventorying Windows .NET services, recording runtime branches and deployment models, and prioritizing the relevant UDP workloads. Back up and trial the update with the application’s normal network and business operations.

Compare installed versions with the runtime actually used. For self-contained software, inspect the published output and confirm that every deployment received the new build. Monitor startup, errors and business functions after deployment; do not test exploit code on systems owned by others.

If updating is temporarily impossible, review restrictions on access to the relevant network functionality according to the actual exposure. That is a Friday Works risk-reduction suggestion, not a vendor-validated replacement for the fix. Keep a concrete update plan; an absence of suspicious logs does not establish that the vulnerable code was removed.

Next steps

Friday Works recommends testing against a copy and keeping evidence before changing a customer-facing system.