The practical takeaway: this requires a product-by-product update check, not a single Windows-only patch decision. Microsoft’s affected-product records specify separate fixed builds for .NET, Visual Studio and the test-platform command-line component.
What the vulnerability allows
Microsoft describes the flaw as follows: “Improper access control in .NET allows an authorized attacker to elevate privileges locally.”
The advisory places two important boundaries around that description:
- Privileges gained: A successful attacker would gain the rights of the user running the affected application.
- Exploitation requirement: Successful exploitation requires the attacker to win a race condition, explaining the high attack complexity identified by AC:H.
That first distinction matters. The advisory describes access to the affected application user’s rights—not an unconditional grant of administrator privileges. As a practical security interpretation, the consequences therefore depend in part on the permissions held by that user.
The race-condition requirement also matters, but it is not a substitute for patching. It makes successful exploitation dependent on timing; it does not remove the underlying access-control weakness.
Severity, scores and exploitation assessment
Microsoft’s security record provides the following details:
| Field | Microsoft advisory value |
|---|---|
| CVE | CVE-2026-105544 |
| Exact title | .NET Elevation of Privilege Vulnerability |
| Severity | Important |
| CVSS base score | 7.5 |
| CVSS temporal score | 6.5 |
| Weakness classification | CWE-15 |
| Exploitation assessment | Exploitation Less Likely |
The complete supplied CVSS vector is:
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C
Its base metrics describe a local attack requiring low privileges and user interaction, with high attack complexity and changed scope. The confidentiality, integrity and availability impact metrics are each high.
Microsoft’s advisory status fields state:
- Publicly disclosed: No
- Exploited: No
- Customer action required: Yes
These are the advisory’s recorded statuses, not a guarantee about future exploitation. “Exploitation Less Likely” should inform prioritization alongside the local-access and race-condition requirements; it should not turn a required update into an optional one.
Affected .NET products and exact fixes
Microsoft’s affected-product records associate KB5135241 with fixed build 10.0.404, KB5135243 with 8.0.428, and KB5135242 with 9.0.321. The listed fixed build for the .NET 11.0 products is 11.0.100.
The exact remediation for each affected operating-system and product combination follows.
.NET 10.0
- For .NET 10.0 installed on Linux, install KB5135241 to reach fixed build 10.0.404.
- For .NET 10.0 installed on Mac OS, install KB5135241 to reach fixed build 10.0.404.
- For .NET 10.0 installed on Windows, install KB5135241 to reach fixed build 10.0.404.
.NET 11.0
- For .NET 11.0 installed on Linux, update to fixed build 11.0.100 or later.
- For .NET 11.0 installed on Mac OS, update to fixed build 11.0.100 or later.
- For .NET 11.0 installed on Windows, update to fixed build 11.0.100 or later.
.NET 8.0
- For .NET 8.0 installed on Linux, install KB5135243 to reach fixed build 8.0.428.
- For .NET 8.0 installed on Mac OS, install KB5135243 to reach fixed build 8.0.428.
- For .NET 8.0 installed on Windows, install KB5135243 to reach fixed build 8.0.428.
.NET 9.0
- For .NET 9.0 installed on Linux, install KB5135242 to reach fixed build 9.0.321.
- For .NET 9.0 installed on Mac OS, install KB5135242 to reach fixed build 9.0.321.
- For .NET 9.0 installed on Windows, install KB5135242 to reach fixed build 9.0.321.
Deployment implication: The same KB-to-build mapping applies across the three listed operating systems within each of the .NET 8.0, .NET 9.0 and .NET 10.0 branches. However, the required build differs between branches. A compliance check should match both the installed product branch and its corresponding fixed build, rather than treating any .NET update as sufficient.
Visual Studio and test-platform fixes
Microsoft’s Visual Studio release notes and affected-product records identify these additional remediation targets:
- For Microsoft Visual Studio 2022 version 17.14, update to fixed build 17.14.45 or later.
- For Microsoft Visual Studio 2026 version 18.11, update to fixed build 18.11.4 or later.
- For Microsoft Visual Studio 2026 version 18.12, update to fixed build 18.12.0 or later.
- For Microsoft.TestPlatform.CLI, update to fixed build 18.11.1 or later.
There is an easy version-number trap here: Microsoft Visual Studio 2026 version 18.11 requires 18.11.4 or later, while Microsoft.TestPlatform.CLI requires 18.11.1 or later. Those are separate product-specific thresholds. Applying the command-line component’s fixed version as the Visual Studio compliance threshold would leave the check below Visual Studio’s stated remediation target.
A practical update plan
The supplied mappings support a straightforward remediation workflow:
- Inventory the listed products separately. Include the relevant .NET installations, Visual Studio branches and Microsoft.TestPlatform.CLI wherever they are present.
- Assign each installation its exact remediation target. Do not reuse a fixed-build threshold across different products or branches.
- Deploy the corresponding fix. Use the KB-to-build mappings and vendor fixed versions above.
- Verify the resulting product versions. Completion means each affected installation meets its own stated remediation target—not merely that an update operation completed.
- Validate normal application and development workflows. As general deployment practice, confirm that affected applications and relevant build or test tasks still function after updating.
The bottom line is measured urgency: Microsoft records no exploitation and assesses exploitation as less likely, but explicitly requires customer action. The strongest response is to patch the listed products and verify each against its own fixed build—without mistaking a difficult attack for an impossible one.