A remediation ticket for CVE-2026-102870 should not close on a generic .NET update notice. Microsoft's advisory requires the affected Blazor WebAssembly debugger packages to move to fixed versions. The evidence needs to show which package version the project actually resolved.
Vulnerability overview
Microsoft rates CVE-2026-102870 High with CVSS 3.1 score 8.8. It is a CWE-94 code injection issue in the Blazor WebAssembly debugger. The affected package names are Microsoft.AspNetCore.Components.WebAssembly.Server and Microsoft.AspNetCore.Components.WebAssembly.DevServer.
The vulnerable ranges are 10.0.0 through 10.0.13 and 11.0.0-preview.1 through 11.0.0-rc.3.26522.148. Fixed versions are 10.0.14 and 11.0.0-rc.3.26522.148.
Build the evidence chain
Begin with the project or branch that developers use to debug the application. Capture the target framework, direct package reference and resolved dependency version. A lockfile, restore log or generated SBOM can provide that record.
Next, confirm the environment can actually load the fixed package. A clean restore reduces the chance that a cached or manually copied package hides the result. For a containerized development environment, rebuild the image rather than editing only the host runtime.
Finally, restart the debugger and development environment. Package replacement without a restart can leave the old process active. The verification should state when the restart occurred and which branch or workspace was tested.
What the fixed package changes
The vulnerable debug proxy generates and compiles C# source when expressions are evaluated. It embeds application-originated values such as ToString() results, descriptions and class names without consistent escaping. An attacker-controlled value may escape a generated string literal and execute code on the developer machine.
The package update addresses this escaping issue. It does not turn every application value into a safe input for every tool. Developers should still treat expression evaluation involving external data as a sensitive operation.
Scope and impact
Windows, Linux and macOS are affected across all architectures when the vulnerable packages are used. The attack requires a developer to evaluate an expression involving attacker-controlled application data. Successful exploitation can execute code with the developer session's access.
That access can expose source, credentials or connected build services. The advisory confirms the execution behavior but does not report compromise of every Blazor deployment. Verification and incident conclusions should keep the package and interaction conditions explicit.
Exposure context
On 2026-11-12, a count-only ZoomEye query for title="Blazor" returned 1,917 assets. app="Blazor" returned 4 and vul.cve="CVE-2026-102870" returned 0. The title count does not establish debugger versions or developer interaction, so it should not be used as patch evidence.
Remediation and closure criteria
Update both package references to the fixed version, regenerate dependency evidence and restart the debugging environment. Record the resolved package version and the date of the current advisory. Note that Microsoft re-released the advisory on October 25 because the earlier fix was incomplete.
A useful closure record includes the affected project, the old and fixed package versions, the verification command or manifest used, the person who reviewed the source, and confirmation that the debugger restarted. That record shows the package-level change rather than merely reporting that .NET looks current.