Improper input-type validation enables network tampering in Microsoft.NET Framework

Improper validation of specified type of input in.NET Framework allows an unauthorized attacker to perform tampering over a network.

• Microsoft.NET Framework 3.5: On Windows 11 version 26H1, Windows Server 2012, and Windows Server 2012 R2, 3.5.0 is affected when less than 2.0.50727.9188 AND 3.0.30729.9171.
• Microsoft.NET Framework 3.5 AND 4.6.2/4.7/4.7.1/4.7.2: On Windows 10 version 1607, Windows Server 2016, and Windows Server 2019, 3.0.0.0 is affected when less than 2.0.50727.8987 AND 3.0.30729.8982 AND 4.7.4150.0.
• Microsoft.NET Framework 3.5 AND 4.7.2: On Windows 10 version 1809, 4.7.0 is affected when less than 2.0.50727.9073 AND 3.0.30729.9070 AND 4.7.4150.0.
• Microsoft.NET Framework 3.5 AND 4.8: On Windows 10 version 1809, Windows 10 version 21H2, Windows 10 version 22H2, Windows Server 2019, and Windows Server 2022, 4.8.0 is affected when less than 2.0.50727.9073 AND 3.0.30729.9070 AND 4.8.4811.0.
• Microsoft.NET Framework 3.5 AND 4.8.1: On Windows 10 version 21H2, Windows 10 version 22H2, Windows 11 version 23H2, Windows 11 version 24H2, Windows 11 version 25H2, Windows 11 version 26H2, Windows Server 2022, and Windows Server 2025, 4.8.1 is affected when less than 2.0.50727.9188 AND 3.0.30729.9171 AND 4.8.9363.0.
• Microsoft.NET Framework 4.6.2/4.7/4.7.1/4.7.2: On Windows Server 2012 and Windows Server 2012 R2, 4.7.0 is affected when less than 4.7.4150.0.
• Microsoft.NET Framework 4.8: On Windows 10 version 1607, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016, 4.8.0 is affected when less than 4.8.4811.0.
• Microsoft.NET Framework 4.8.1: On Windows 11 version 26H1, 4.8.0.0 is affected when less than 4.8.9363.0.

Conditions joined with AND must be evaluated together. The record does not establish the status of branches or platforms that are not listed.

The weakness is classified as CWE-1287, Improper Validation of Specified Type of Input, in Microsoft.NET Framework. Insufficient validation of an input type may allow attacker-controlled data to reach an affected processing path without being checked correctly. The supplied attack model indicates network reachability, no authentication requirement, no user interaction, and low attack complexity. The record does not identify the relevant API, parser, protocol, endpoint, or specific input type, so the detailed exploit path remains unknown. The assessed impact stays within the same security authority, with the primary consequence affecting integrity; the record does not identify a direct confidentiality or availability consequence.

• Reachability: The issue is remotely reachable over a network.
• Authentication: No prior privileges or authentication are required.
• User interaction: No user interaction is required.
• Complexity: The attack is assessed as low complexity.
• Exploitation status: The returned CISA enrichment records exploitation as none, and the supplied record marks public exploit as false. This is a time-scoped record status and does not prove that exploitation cannot occur later.

The available record provides no specific exploit, campaign, victim, or indicator of compromise.

Successful exploitation could allow an attacker with no prior privileges to cause unauthorized tampering in a component or application using an affected.NET Framework branch. The primary outcome is an integrity impact, and the assessed scope does not extend beyond the affected security authority. The record does not establish direct data disclosure, service disruption, or privilege elevation as outcomes. Operationally, unauthorized changes could require data validation, service retesting, and application integrity investigation. The specific business functions affected remain unknown.

The confirmed consequence is primarily an integrity risk: a remote attacker may cause unauthorized modification or tampering in an affected processing path. Depending on how the framework is used, this could affect application data or state, but the record does not identify a specific business workflow. The record does not identify a confidentiality or availability impact. Organizations should prioritize version inventory, patch deployment, and post-update integrity checks for critical services.

1. Apply the Microsoft security update for the exact product branch and platform. The record confirms that a patch is available, but it does not provide separate solution text or one universal fixed release for every branch.
2. After updating, verify that the relevant components are no longer below all applicable thresholds: 2.0.50727.9188 AND 3.0.30729.9171 for the relevant.NET Framework 3.5 branches; 2.0.50727.8987 AND 3.0.30729.8982 AND 4.7.4150.0 for the branch combined with 4.6.2/4.7/4.7.1/4.7.2; 2.0.50727.9073 AND 3.0.30729.9070 AND 4.7.4150.0 for the branch combined with 4.7.2; 2.0.50727.9073 AND 3.0.30729.9070 AND 4.8.4811.0 for the branch combined with 4.8; 2.0.50727.9188 AND 3.0.30729.9171 AND 4.8.9363.0 for the branch combined with 4.8.1; 4.7.4150.0 for the standalone 4.6.2/4.7/4.7.1/4.7.2 branch; 4.8.4811.0 for the standalone 4.8 branch; and 4.8.9363.0 for the standalone 4.8.1 branch.
3. For combined installations, check every component in the AND condition. Meeting one component threshold does not establish that the complete configuration is remediated.
4. Do not treat an update for one.NET Framework branch as evidence that parallel branches or other platforms are fixed. The record provides no vendor-confirmed workaround.
5. After deployment, test services that accept network input and review the integrity of important application data or state.

1. Inventory servers, workstations, and applications using the Microsoft.NET Framework branches listed in affected_summary, and record the corresponding Windows platforms.
2. Determine the exact installed framework versions and build values for each system, then compare them with the affected boundaries in the record. Do not infer safety from the product name or Windows version alone.
3. Identify network-reachable services that use the affected.NET Framework branches. The record does not name a specific endpoint or input type, so testing cannot be narrowed to a particular protocol or API.
4. Review application and system telemetry for unauthorized changes to application data or state. This is precautionary monitoring, not a confirmed indicator.
5. No specific log event, identifying string, or IOC is supplied. The absence of matching log evidence does not prove that a system is safe.