Microsoft has patched CVE-2026-45646, a remotely triggerable denial-of-service vulnerability in OData components for ASP.NET and ASP.NET Core. Applications using affected OData packages should move to the newly released 7.8.0 or 9.5.0 servicing versions and redeploy rather than waiting for a Windows or .NET runtime update.
Published by the Microsoft Security Response Center on July 14, 2026, the vulnerability carries a CVSS 3.1 base score of 7.5 High. Microsoft describes the underlying weakness as uncontrolled resource allocation that allows an unauthenticated attacker to exhaust a vulnerable service over the network.
The National Vulnerability Database is still enriching its record, and Microsoft has disclosed little about the precise request pattern involved. The available scoring data nevertheless makes the operational risk clear: exploitation requires no account, no user interaction, and low attack complexity.
CVE-2026-45646 affects application dependencies rather than the Windows operating system itself. Installing July's Windows security updates will not necessarily repair an OData service whose deployed binaries still reference a vulnerable package.
Microsoft's CVE record identifies two affected version ranges:
That distinction matters in environments where platform servicing and application servicing are handled by different teams. A Windows Server administrator may fully patch the host while an older OData assembly remains inside an application directory, container image, deployment ZIP, or self-contained .NET build.
Applications using centralized package management should inspect
A basic project inspection can begin with commands such as:
Teams should also search source and deployment manifests for
OData services are particularly sensitive to resource-control mistakes because clients can express structured operations through URL query options. Features such as
Microsoft has not publicly identified which OData operation triggers CVE-2026-45646. It would therefore be premature to claim that a particular query option, parser path, or database operation is responsible. The CVSS vector and Microsoft's description establish only that an unauthorized network attacker can trigger unbounded resource allocation and cause an availability failure.
The CVSS vector is
That profile points to service disruption rather than data theft or server takeover. An attacker may be able to make an API slow, unresponsive, or unavailable, but the published assessment does not indicate that CVE-2026-45646 exposes records, changes data, or executes arbitrary code.
CISA's initial Stakeholder-Specific Vulnerability Categorization data recorded no observed exploitation as of July 14. It also judged the attack automatable, meaning defenders should not interpret the absence of known attacks as evidence that exposed services can safely remain unpatched.
For defenders, this creates a familiar asymmetry. There is enough information to identify affected dependencies and apply a fix, but not enough to build a reliable request signature or determine whether an unusual burst of expensive OData queries was an attempted exploit.
That limitation makes patching more dependable than filtering. A web application firewall rule created without knowledge of the malformed or abusive request structure could miss variants, while broad restrictions on OData syntax could break legitimate clients.
Existing defensive controls can still reduce exposure while updated builds move through testing:
Traditional IIS deployments require similar verification. Teams should confirm that the application pool restarted against the updated files and that no older deployment directory remains active behind a load balancer. Self-contained executables and single-file deployments must be republished because their dependencies may be embedded in the output.
OData upgrades also deserve functional testing. Administrators should validate
The newly published packages had essentially no download history at disclosure time, which is expected for same-day releases but leaves little public evidence about compatibility in varied production applications. Staging tests should focus on complex queries and integrations that depend on exact OData behavior, while the security priority argues against allowing routine change windows to delay an internet-facing fix for weeks.
Organizations that cannot deploy immediately should consider restricting vulnerable endpoints to trusted networks, requiring authentication upstream, or temporarily disabling affected OData routes. Capacity monitoring and automatic process recovery may shorten an outage, but they do not remove the attacker's ability to repeat the request.
CVE-2026-45646 is not a Windows desktop emergency, and it does not call for indiscriminate patching of every .NET machine. It is a targeted application-security issue: find services carrying the affected OData packages, update them to 7.8.0 or 9.5.0 as appropriate, rebuild every deployable artifact, and verify the version actually running in production.
Published by the Microsoft Security Response Center on July 14, 2026, the vulnerability carries a CVSS 3.1 base score of 7.5 High. Microsoft describes the underlying weakness as uncontrolled resource allocation that allows an unauthenticated attacker to exhaust a vulnerable service over the network.
The National Vulnerability Database is still enriching its record, and Microsoft has disclosed little about the precise request pattern involved. The available scoring data nevertheless makes the operational risk clear: exploitation requires no account, no user interaction, and low attack complexity.
The Fix Lives in NuGet, Not Windows Update
CVE-2026-45646 affects application dependencies rather than the Windows operating system itself. Installing July's Windows security updates will not necessarily repair an OData service whose deployed binaries still reference a vulnerable package.Microsoft's CVE record identifies two affected version ranges:
- AspNet.OData versions 7.0.0 through versions earlier than 7.8.0 are affected.
- AspNetCore.OData versions 9.0.0 through versions earlier than 9.5.0 are affected.
That distinction matters in environments where platform servicing and application servicing are handled by different teams. A Windows Server administrator may fully patch the host while an older OData assembly remains inside an application directory, container image, deployment ZIP, or self-contained .NET build.
Applications using centralized package management should inspect
Directory.Packages.props, while conventional projects should check their .csproj files and generated dependency assets. Software bills of materials, NuGet lock files, container inventories, and endpoint-detection telemetry can help locate copies that are no longer tied to an actively maintained source repository.A basic project inspection can begin with commands such as:
dotnet list package --include-transitiveTeams should also search source and deployment manifests for
Microsoft.AspNet.OData and Microsoft.AspNetCore.OData. Transitive references deserve attention because an application may consume the vulnerable component through an API framework, versioning extension, or internal shared library without declaring it directly.A Small Request Can Create a Large Server-Side Cost
Microsoft maps CVE-2026-45646 to CWE-770, Allocation of Resources Without Limits or Throttling. This class of flaw arises when software permits a request or operation to consume memory, CPU time, threads, database work, or another finite resource without an effective upper bound.OData services are particularly sensitive to resource-control mistakes because clients can express structured operations through URL query options. Features such as
$filter, $expand, $orderby, $select, and $count can translate a comparatively short HTTP request into substantial parsing, query-building, serialization, or database activity.Microsoft has not publicly identified which OData operation triggers CVE-2026-45646. It would therefore be premature to claim that a particular query option, parser path, or database operation is responsible. The CVSS vector and Microsoft's description establish only that an unauthorized network attacker can trigger unbounded resource allocation and cause an availability failure.
The CVSS vector is
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. In practical terms, Microsoft rates the flaw as remotely reachable, straightforward to trigger, and capable of producing a high availability impact, while assigning no confidentiality or integrity impact.That profile points to service disruption rather than data theft or server takeover. An attacker may be able to make an API slow, unresponsive, or unavailable, but the published assessment does not indicate that CVE-2026-45646 exposes records, changes data, or executes arbitrary code.
CISA's initial Stakeholder-Specific Vulnerability Categorization data recorded no observed exploitation as of July 14. It also judged the attack automatable, meaning defenders should not interpret the absence of known attacks as evidence that exposed services can safely remain unpatched.
Microsoft's Confirmation Raises Confidence, Not Disclosure Depth
The vulnerability's report confidence should not be confused with the amount of public exploit detail. Microsoft is the assigning CVE Numbering Authority, has acknowledged the flaw, supplied the affected ranges, assigned the CVSS score, and released replacement packages. Those facts provide strong confidence that the vulnerability exists even though the public description remains brief.For defenders, this creates a familiar asymmetry. There is enough information to identify affected dependencies and apply a fix, but not enough to build a reliable request signature or determine whether an unusual burst of expensive OData queries was an attempted exploit.
That limitation makes patching more dependable than filtering. A web application firewall rule created without knowledge of the malformed or abusive request structure could miss variants, while broad restrictions on OData syntax could break legitimate clients.
Existing defensive controls can still reduce exposure while updated builds move through testing:
- Internet-facing OData endpoints should be placed behind rate limiting and request-concurrency controls.
- Anonymous access should be disabled wherever the application's design does not require it.
- Query complexity, expansion depth, page size, and execution time should be bounded independently of this CVE.
- Monitoring should alert on sudden CPU or memory growth, repeated worker recycling, long-running requests, and spikes in identical OData query patterns.
- Reverse proxies and load balancers should enforce sensible request and upstream timeouts.
Updating the Package Is Only Half the Deployment
Changing a package reference does not protect a production service until the application is rebuilt and the new artifacts are deployed. Containerized environments must rebuild images without reusing a stale dependency layer, update image tags or digests in the deployment platform, and replace running pods or tasks.Traditional IIS deployments require similar verification. Teams should confirm that the application pool restarted against the updated files and that no older deployment directory remains active behind a load balancer. Self-contained executables and single-file deployments must be republished because their dependencies may be embedded in the output.
OData upgrades also deserve functional testing. Administrators should validate
$metadata responses, routing, serialization, pagination, filtering, ordering, expansion, API-versioning behavior, and any custom query validators before promoting the patched build.The newly published packages had essentially no download history at disclosure time, which is expected for same-day releases but leaves little public evidence about compatibility in varied production applications. Staging tests should focus on complex queries and integrations that depend on exact OData behavior, while the security priority argues against allowing routine change windows to delay an internet-facing fix for weeks.
Organizations that cannot deploy immediately should consider restricting vulnerable endpoints to trusted networks, requiring authentication upstream, or temporarily disabling affected OData routes. Capacity monitoring and automatic process recovery may shorten an outage, but they do not remove the attacker's ability to repeat the request.
CVE-2026-45646 is not a Windows desktop emergency, and it does not call for indiscriminate patching of every .NET machine. It is a targeted application-security issue: find services carrying the affected OData packages, update them to 7.8.0 or 9.5.0 as appropriate, rebuild every deployable artifact, and verify the version actually running in production.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: nuget.org
Microsoft.OData.Core 8.4.4
Classes to serialize, deserialize and validate OData JSON payloads. Supports OData v4 and v4.01. Enables construction of OData services and clients. Targets .NET 8 or above. OData .NET library is open source at http://github.com/OData/odata.net. Documentation for the library can be found at...www.nuget.org
