CVE-2026-62872

This vulnerability is like a locked door with a faulty lock in a building’s security system. If someone already has a small amount of access, they can use the network to bypass the “who should be allowed” rules and take over with administrator-level control. The “network” part means the attacker doesn’t need to sit at your servers—just reach the system from the outside or internal network where it’s exposed.

This matters if you run or host applications on Microsoft .NET Framework versions listed as affected (3.5; 4.6.2/4.7/4.7.1/4.7.2; 4.8; 4.8.1). It’s most relevant when an attacker already has low-level access, because the flaw is triggered by an authenticated attacker and requires that foothold.

Reachability gate: it is reachable in default configuration over a network, but the attacker still needs low-privilege access to make use of it.

This is RED because attackers can elevate from low privileges to full high-privilege control over the network when they already have an initial foothold, and the issue is reachable in default configurations. Patch quickly according to Microsoft’s fixed versions; there’s no indication this is safe to ignore just because you haven’t seen an attack yet.

1. Confirm exposure (what you run)

   • Inventory your servers and application hosts for Microsoft .NET Framework installations on:
     • Microsoft .NET Framework 3.5
     • Microsoft .NET Framework 4.6.2/4.7/4.7.1/4.7.2
     • Microsoft .NET Framework 4.8
     • Microsoft .NET Framework 4.8.1
   • Identify the installed .NET Framework version on each machine (using your standard endpoint inventory method).

2. Confirm you’re below the fixed version (is it vulnerable?)

   • Compare each installed version against Microsoft’s fixed builds for CVE-2026-62872:
     • .NET Framework 3.5: fixed in 2.0.50727.9183 & 3.0.30729.9169
     • .NET Framework 3.5 AND 4.6.2/4.7/4.7.1/4.7.2: fixed in 2.0.50727.8984 & 3.0.30729.8980 & 4.7.4144.0
     • .NET Framework 3.5 AND 4.7.2: fixed in 2.0.50727.9070 & 3.0.30729.9068 & 4.7.4144.0
     • .NET Framework 3.5 AND 4.8: fixed in 2.0.50727.9070 & 3.0.30729.9068 & 4.8.4805.0
     • .NET Framework 3.5 AND 4.8.1: fixed in 2.0.50727.9183 & 3.0.30729.9169 & 4.8.9343.0
     • .NET Framework 4.6.2/4.7/4.7.1/4.7.2: fixed in 4.7.4144.0
     • .NET Framework 4.8: fixed in 4.8.4805.0
     • .NET Framework 4.8.1: fixed in 4.8.9344.0

3. Patch / upgrade (the fix)

   • Apply the Microsoft updates for CVE-2026-62872 and ensure each .NET Framework installation reaches the corresponding fixed version listed above.
   • Use Microsoft’s update guide as the source of truth for the exact update package(s) to apply: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62872

4. Temporary workaround while patching (if you must delay)

   • Restrict network access to any internet-facing or internal services that use these .NET Framework components.
   • Tighten access controls so fewer users/systems have “low privilege” access that could later be leveraged for this authorization bypass.

5. After patching: verify and monitor

   • Re-check installed .NET Framework versions to confirm they match (or exceed) the fixed builds.
   • Monitor logs for signs of unexpected privilege changes or suspicious authenticated activity that targets management/admin capabilities.

Severity is high (CVSS 8.8) with network attack surface and low attacker requirements beyond having low-privilege access; no user interaction is required. The weakness is CWE-863 (incorrect authorization), meaning the system makes an authorization decision incorrectly and allows privilege elevation.

From the findings: the vulnerability can be triggered over a network by an authenticated attacker with low_privilege, and it is reachable in default configuration. KEV is not listed, and there is no clear dated press claim of exploitation; there is no public exploit code recorded. However, the traffic light verdict is RED and patch activity is notable (including actor mention in PULSE), so treat this as an active, high-priority remediation.

Fixes are available for specific .NET Framework builds as listed in the Patch findings; upgrade each affected installation to the fixed version(s) for its branch.