CVE-2026-47304, an Important-rated .NET security feature bypass, was fixed in Microsoft’s July 14, 2026 security releases for .NET 8, .NET 9, .NET 10, .NET Framework, and supported Visual Studio editions. The flaw carries a CVSS 3.1 score of 8.1 and could let an unauthenticated remote attacker bypass cryptographic protections without user interaction.
Microsoft describes the vulnerability as improper verification of a cryptographic signature in .NET. In practical terms, affected software may accept data whose authenticity has not been established correctly, undermining a security decision that depends on that signature.
The Microsoft Security Response Center has not published the protocol, API, or application workflow involved. That lack of detail limits immediate exposure analysis, but it should not be mistaken for uncertainty about whether the bug exists: Microsoft has confirmed it, assigned two relevant weakness categories, and shipped fixes across multiple servicing channels.
Microsoft’s CVSS vector rates CVE-2026-47304 as remotely reachable, requiring no privileges and no user interaction. A successful attack is assessed as having a high potential impact on confidentiality, integrity, and availability, all without crossing into a separate security authority.
The principal constraint is high attack complexity. That generally indicates that exploitation depends on conditions outside an attacker’s direct control, such as a particular application configuration, cryptographic workflow, timing condition, or form of signed input. Microsoft has not disclosed which prerequisite applies here, so administrators cannot reliably determine safety merely by checking whether an application exposes a conventional web endpoint.
The vulnerability is mapped to CWE-347, Improper Verification of Cryptographic Signature, and CWE-345, Insufficient Verification of Data Authenticity. Those classifications point to a trust-validation failure rather than a weakness in the underlying cryptographic algorithm.
A signature can be generated using strong cryptography and still provide no useful security if the receiving code fails to verify it properly. Depending on where that validation occurs, the result could range from accepting modified content to treating an attacker-controlled object as trusted.
Microsoft’s exploitability assessment, as reflected in the July Patch Tuesday material collected by the SANS Internet Storm Center, did not identify CVE-2026-47304 as publicly disclosed or actively exploited when the updates were released. That lowers the evidence of immediate attack activity, but the network vector and lack of authentication still argue against delaying deployment solely because proof-of-concept code is not yet public.
However, treating this as a Visual Studio-only problem would be a mistake. Microsoft’s .NET servicing announcement says CVE-2026-47304 also applies to .NET 8.0, .NET 9.0, and .NET 10.0, with corrected servicing releases published on July 14:
The difference between the early NVD product list and Microsoft’s broader servicing documentation likely reflects how the initial CVE data was populated rather than a narrow technical scope. NVD still marked the record as awaiting enrichment on July 14. Administrators should therefore use Microsoft’s product-specific update guidance and installed-runtime inventory instead of relying only on the first affected-products block in the CVE record.
Self-contained deployments require more attention. Those applications carry their own .NET runtime, so installing a shared runtime update on Windows does not necessarily replace the vulnerable components embedded with the application. Development teams may need to install the corrected SDK, republish the application, and redeploy its output.
Containers present the same inventory problem in another form. Updating the host does not repair an old .NET runtime inside an existing image. Teams should rebuild images from Microsoft’s refreshed July 2026 base images, move workloads onto the rebuilt image, and verify that old image digests are no longer running in production.
Visual Studio also deserves separate handling because an IDE update and a machine-wide runtime update are not interchangeable. Build agents, developer workstations, and offline Visual Studio layouts should all be checked against the fixed version floors. An organization can otherwise patch its production servers while leaving vulnerable toolchain components on CI workers or developer PCs.
For .NET Framework, remediation follows the Windows servicing model. KB5102203 is offered through Windows Update, Windows Update for Business, the Microsoft Update Catalog, and WSUS for applicable Windows 10 version 22H2 systems. Other supported Windows and Windows Server releases receive their own corresponding .NET Framework packages, so deployment teams should approve updates by operating-system version rather than trying to apply KB5102203 universally.
Confidence in public understanding of the exploitation mechanism is much lower. Microsoft has not explained what signed material is checked incorrectly, which .NET component performs the check, or whether exposure depends on an application opting into a particular API. There is also no public workaround or configuration-based mitigation that administrators can use as a substitute for updating.
That combination changes the defensive task. Security teams cannot currently create a dependable application-level hunt based on a disclosed request pattern, file format, exception message, or event ID. They can, however, find outdated runtimes and development tools.
Useful checks include installed .NET runtime versions, self-contained deployment manifests, container base-image tags and digests, Visual Studio channel versions, and pending .NET Framework updates in WSUS or endpoint-management platforms. Internet-facing services deserve priority, but internal applications that process signed packages, tokens, manifests, or other authenticity-sensitive data should not be assumed safe simply because they are not public web applications.
Microsoft says it is not aware of known issues with KB5102203. Organizations should still use their normal deployment rings because the July .NET releases contain numerous security and non-security changes beyond CVE-2026-47304.
The immediate milestone is straightforward: move shared runtimes to .NET 8.0.29, 9.0.18, or 10.0.10; update Visual Studio past the affected version boundaries; deploy the applicable July .NET Framework packages; and rebuild self-contained applications and containers. Until Microsoft publishes deeper technical details, version-based remediation is the only reliable control for CVE-2026-47304.
Microsoft describes the vulnerability as improper verification of a cryptographic signature in .NET. In practical terms, affected software may accept data whose authenticity has not been established correctly, undermining a security decision that depends on that signature.
The Microsoft Security Response Center has not published the protocol, API, or application workflow involved. That lack of detail limits immediate exposure analysis, but it should not be mistaken for uncertainty about whether the bug exists: Microsoft has confirmed it, assigned two relevant weakness categories, and shipped fixes across multiple servicing channels.
A High Score With a Difficult Attack Path
Microsoft’s CVSS vector rates CVE-2026-47304 as remotely reachable, requiring no privileges and no user interaction. A successful attack is assessed as having a high potential impact on confidentiality, integrity, and availability, all without crossing into a separate security authority.The principal constraint is high attack complexity. That generally indicates that exploitation depends on conditions outside an attacker’s direct control, such as a particular application configuration, cryptographic workflow, timing condition, or form of signed input. Microsoft has not disclosed which prerequisite applies here, so administrators cannot reliably determine safety merely by checking whether an application exposes a conventional web endpoint.
The vulnerability is mapped to CWE-347, Improper Verification of Cryptographic Signature, and CWE-345, Insufficient Verification of Data Authenticity. Those classifications point to a trust-validation failure rather than a weakness in the underlying cryptographic algorithm.
A signature can be generated using strong cryptography and still provide no useful security if the receiving code fails to verify it properly. Depending on where that validation occurs, the result could range from accepting modified content to treating an attacker-controlled object as trusted.
Microsoft’s exploitability assessment, as reflected in the July Patch Tuesday material collected by the SANS Internet Storm Center, did not identify CVE-2026-47304 as publicly disclosed or actively exploited when the updates were released. That lowers the evidence of immediate attack activity, but the network vector and lack of authentication still argue against delaying deployment solely because proof-of-concept code is not yet public.
The Affected-Product Record Is Broader Than It First Appears
The initial National Vulnerability Database record lists three Visual Studio product lines:- Microsoft Visual Studio 2022 version 17.12 releases before 17.12.22 are affected.
- Microsoft Visual Studio 2022 version 17.14 releases before 17.14.36 are affected.
- Microsoft Visual Studio 2026 version 18.7 releases before 18.7.4 are affected.
However, treating this as a Visual Studio-only problem would be a mistake. Microsoft’s .NET servicing announcement says CVE-2026-47304 also applies to .NET 8.0, .NET 9.0, and .NET 10.0, with corrected servicing releases published on July 14:
- .NET 8.0.29
- .NET 9.0.18
- .NET 10.0.10
The difference between the early NVD product list and Microsoft’s broader servicing documentation likely reflects how the initial CVE data was populated rather than a narrow technical scope. NVD still marked the record as awaiting enrichment on July 14. Administrators should therefore use Microsoft’s product-specific update guidance and installed-runtime inventory instead of relying only on the first affected-products block in the CVE record.
Runtime Servicing Is Not the Same as Rebuilding Every Application
For framework-dependent .NET applications, updating the machine’s shared runtime can place applications on the corrected servicing release without rebuilding them. Administrators should nevertheless confirm the effective runtime version withdotnet --list-runtimes, especially on servers that retain multiple major or servicing versions.Self-contained deployments require more attention. Those applications carry their own .NET runtime, so installing a shared runtime update on Windows does not necessarily replace the vulnerable components embedded with the application. Development teams may need to install the corrected SDK, republish the application, and redeploy its output.
Containers present the same inventory problem in another form. Updating the host does not repair an old .NET runtime inside an existing image. Teams should rebuild images from Microsoft’s refreshed July 2026 base images, move workloads onto the rebuilt image, and verify that old image digests are no longer running in production.
Visual Studio also deserves separate handling because an IDE update and a machine-wide runtime update are not interchangeable. Build agents, developer workstations, and offline Visual Studio layouts should all be checked against the fixed version floors. An organization can otherwise patch its production servers while leaving vulnerable toolchain components on CI workers or developer PCs.
For .NET Framework, remediation follows the Windows servicing model. KB5102203 is offered through Windows Update, Windows Update for Business, the Microsoft Update Catalog, and WSUS for applicable Windows 10 version 22H2 systems. Other supported Windows and Windows Server releases receive their own corresponding .NET Framework packages, so deployment teams should approve updates by operating-system version rather than trying to apply KB5102203 universally.
Sparse Disclosure Makes Inventory More Important
The supplied vulnerability text discusses confidence in whether a vulnerability and its technical details are known. In this case, confidence in the flaw’s existence is high because Microsoft is the assigning authority, identifies specific weakness classes, names corrected releases, and has issued official patches.Confidence in public understanding of the exploitation mechanism is much lower. Microsoft has not explained what signed material is checked incorrectly, which .NET component performs the check, or whether exposure depends on an application opting into a particular API. There is also no public workaround or configuration-based mitigation that administrators can use as a substitute for updating.
That combination changes the defensive task. Security teams cannot currently create a dependable application-level hunt based on a disclosed request pattern, file format, exception message, or event ID. They can, however, find outdated runtimes and development tools.
Useful checks include installed .NET runtime versions, self-contained deployment manifests, container base-image tags and digests, Visual Studio channel versions, and pending .NET Framework updates in WSUS or endpoint-management platforms. Internet-facing services deserve priority, but internal applications that process signed packages, tokens, manifests, or other authenticity-sensitive data should not be assumed safe simply because they are not public web applications.
Microsoft says it is not aware of known issues with KB5102203. Organizations should still use their normal deployment rings because the July .NET releases contain numerous security and non-security changes beyond CVE-2026-47304.
The immediate milestone is straightforward: move shared runtimes to .NET 8.0.29, 9.0.18, or 10.0.10; update Visual Studio past the affected version boundaries; deploy the applicable July .NET Framework packages; and rebuild self-contained applications and containers. Until Microsoft publishes deeper technical details, version-based remediation is the only reliable control for CVE-2026-47304.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
