Microsoft has disclosed CVE-2026-50506, a high-severity denial-of-service vulnerability affecting OData server packages for ASP.NET and ASP.NET Core. An unauthenticated attacker can exploit the flaw remotely to consume uncontrolled resources and make a vulnerable OData service unavailable, so administrators should identify exposed applications and update their NuGet dependencies rather than waiting for a Windows operating-system patch.
Detailed in the Microsoft Security Response Center advisory published July 14, 2026, the vulnerability carries a CVSS 3.1 base score of 7.5. Microsoft describes the underlying weakness as resource allocation without adequate limits or throttling, classified as CWE-770.
The affected components are application libraries, not the ASP.NET runtime installed on a server. Microsoft’s CVE record identifies two package lines:
CVE-2026-50506 does not require an attacker to authenticate, hold application privileges, or persuade a user to open a file. Microsoft’s CVSS vector marks the attack as network-accessible, low complexity, requiring no privileges and no user interaction.
The confidentiality and integrity ratings are both zero, meaning Microsoft is not describing the flaw as a route to steal or modify data. The availability impact is rated high: a successful request or sequence of requests can reportedly force the application to allocate resources without an effective limit, disrupting service for legitimate clients.
That distinction matters for incident response. A denial-of-service flaw may not produce the account compromise, malware execution, or suspicious file changes that many endpoint-detection products are designed to catch. The practical symptoms could instead be elevated CPU or memory consumption, request queues, latency, worker-process recycling, container restarts, health-check failures, or an OData endpoint that stops responding under comparatively modest hostile traffic.
OData applications are potentially attractive targets for this class of bug because the protocol supports expressive, client-controlled queries. Microsoft has not publicly documented the precise request structure or affected processing path, which limits immediate technical validation but also avoids handing attackers a ready-made recipe.
The absence of those details should not be treated as evidence that only unusually configured services are vulnerable. Microsoft’s description ties the weakness to the affected OData packages themselves, and the CVSS assessment assumes exploitation over a network without authentication.
Developers and administrators therefore need to inspect the dependency graph for each service. A package might be declared directly in a
Useful checks include:
and, on newer SDKs:
Teams can also search repositories and generated dependency files for the exact package IDs:
A complete remediation requires more than editing a project file. The package must be restored, the application rebuilt, the resulting artifact or container image redeployed, and every old instance removed from rotation. Long-running IIS worker processes, stale deployment directories and previously published container tags can otherwise continue serving the vulnerable assemblies.
For
Administrators should not assume that an application using ASP.NET Core OData 8.x is covered by the listed 9.x range. The initial Microsoft record names the 9.0.0-to-9.5.0 line specifically, while NuGet has also carried older OData branches. Until Microsoft clarifies whether unsupported or separately maintained versions share the vulnerable code, teams should inventory those deployments and avoid interpreting omission as a guarantee of safety.
In practical terms, Microsoft is confirming that the vulnerability exists and that an official correction is available or designated. At the same time, the initial advisory does not indicate that functional public exploit code or active attacks have been observed.
That combination lowers the case for panic but not for remediation. A network-reachable, unauthenticated denial-of-service condition with low attack complexity can become significantly more urgent once researchers compare package versions, locate the corrected code and reconstruct the triggering input.
Microsoft has not published a proof of concept, detailed root-cause narrative, mitigating factor or request signature in the initial CVE material. Defenders consequently have little basis for creating a precise web application firewall rule without risking false positives or blocking legitimate OData functionality.
Rate limiting, request timeouts, memory limits and reverse-proxy controls can reduce exposure, but they are compensating controls rather than substitutes for the corrected package. Generic throttling may also be ineffective if one request is sufficient to trigger disproportionate work inside the application.
Operations teams should review telemetry around OData routes for abnormal request rates, unusually expensive queries, sharp changes in process memory, garbage-collection pressure, thread-pool starvation and repeated application restarts. Those signals do not prove exploitation of CVE-2026-50506, but they can reveal attempts to exhaust the same resources targeted by the vulnerability.
After deploying the update, teams should run both normal query tests and load tests. OData package updates can affect routing, query validation, serialization and compatibility with libraries used for API versioning, so a successful compilation alone is not enough evidence that the service remains healthy.
The immediate task is concrete: locate
Detailed in the Microsoft Security Response Center advisory published July 14, 2026, the vulnerability carries a CVSS 3.1 base score of 7.5. Microsoft describes the underlying weakness as resource allocation without adequate limits or throttling, classified as CWE-770.
The affected components are application libraries, not the ASP.NET runtime installed on a server. Microsoft’s CVE record identifies two package lines:
Microsoft.AspNet.ODataversions from 7.0.0 up to, but not including, 7.8.0 are affected.Microsoft.AspNetCore.ODataversions from 9.0.0 up to the patched 9.5.0 boundary are affected.
9.5.0[SX1] in parts of the ASP.NET Core version range. That appears to be a publication artifact rather than a valid NuGet version, so teams should verify the corrected package number in MSRC and NuGet metadata before encoding the value into automated compliance rules.
A Remote Request Can Become a Resource-Exhaustion Attack
CVE-2026-50506 does not require an attacker to authenticate, hold application privileges, or persuade a user to open a file. Microsoft’s CVSS vector marks the attack as network-accessible, low complexity, requiring no privileges and no user interaction.The confidentiality and integrity ratings are both zero, meaning Microsoft is not describing the flaw as a route to steal or modify data. The availability impact is rated high: a successful request or sequence of requests can reportedly force the application to allocate resources without an effective limit, disrupting service for legitimate clients.
That distinction matters for incident response. A denial-of-service flaw may not produce the account compromise, malware execution, or suspicious file changes that many endpoint-detection products are designed to catch. The practical symptoms could instead be elevated CPU or memory consumption, request queues, latency, worker-process recycling, container restarts, health-check failures, or an OData endpoint that stops responding under comparatively modest hostile traffic.
OData applications are potentially attractive targets for this class of bug because the protocol supports expressive, client-controlled queries. Microsoft has not publicly documented the precise request structure or affected processing path, which limits immediate technical validation but also avoids handing attackers a ready-made recipe.
The absence of those details should not be treated as evidence that only unusually configured services are vulnerable. Microsoft’s description ties the weakness to the affected OData packages themselves, and the CVSS assessment assumes exploitation over a network without authentication.
The Fix Belongs in the Application Build
This advisory will not necessarily be resolved by running Windows Update on an IIS server.Microsoft.AspNet.OData and Microsoft.AspNetCore.OData are distributed through NuGet and are normally restored, compiled, and deployed as application dependencies.Developers and administrators therefore need to inspect the dependency graph for each service. A package might be declared directly in a
.csproj, supplied through Central Package Management in Directory.Packages.props, or introduced transitively by another library.Useful checks include:
dotnet list package --include-transitiveand, on newer SDKs:
dotnet package list --include-transitive --vulnerableTeams can also search repositories and generated dependency files for the exact package IDs:
Code:
Microsoft.AspNet.OData
Microsoft.AspNetCore.ODataFor
Microsoft.AspNet.OData, Microsoft’s affected-version data indicates that 7.8.0 is the security boundary. For Microsoft.AspNetCore.OData, the intended fixed boundary appears to be 9.5.0, although the malformed suffix in the initial CVE record warrants a manual check against Microsoft’s corrected advisory and the live NuGet package listing.Administrators should not assume that an application using ASP.NET Core OData 8.x is covered by the listed 9.x range. The initial Microsoft record names the 9.0.0-to-9.5.0 line specifically, while NuGet has also carried older OData branches. Until Microsoft clarifies whether unsupported or separately maintained versions share the vulnerable code, teams should inventory those deployments and avoid interpreting omission as a guarantee of safety.
Exploitation Is Unproven, but the Vulnerability Is Confirmed
The temporal portion of Microsoft’s CVSS vector provides an important reading of the evidence available on disclosure day. It marks exploit-code maturity as unproven, remediation as official, and report confidence as confirmed.In practical terms, Microsoft is confirming that the vulnerability exists and that an official correction is available or designated. At the same time, the initial advisory does not indicate that functional public exploit code or active attacks have been observed.
That combination lowers the case for panic but not for remediation. A network-reachable, unauthenticated denial-of-service condition with low attack complexity can become significantly more urgent once researchers compare package versions, locate the corrected code and reconstruct the triggering input.
Microsoft has not published a proof of concept, detailed root-cause narrative, mitigating factor or request signature in the initial CVE material. Defenders consequently have little basis for creating a precise web application firewall rule without risking false positives or blocking legitimate OData functionality.
Rate limiting, request timeouts, memory limits and reverse-proxy controls can reduce exposure, but they are compensating controls rather than substitutes for the corrected package. Generic throttling may also be ineffective if one request is sufficient to trigger disproportionate work inside the application.
Internet-Facing OData Services Need the Shortest Deadline
The highest priority should go to anonymously accessible OData endpoints exposed through IIS, Azure App Service, Kubernetes ingress controllers, API gateways or public reverse proxies. Internal services still require attention, particularly where guest networks, partner connections or compromised client systems can reach them.Operations teams should review telemetry around OData routes for abnormal request rates, unusually expensive queries, sharp changes in process memory, garbage-collection pressure, thread-pool starvation and repeated application restarts. Those signals do not prove exploitation of CVE-2026-50506, but they can reveal attempts to exhaust the same resources targeted by the vulnerability.
After deploying the update, teams should run both normal query tests and load tests. OData package updates can affect routing, query validation, serialization and compatibility with libraries used for API versioning, so a successful compilation alone is not enough evidence that the service remains healthy.
The immediate task is concrete: locate
Microsoft.AspNet.OData and Microsoft.AspNetCore.OData in deployed applications, confirm the final corrected versions published by Microsoft, rebuild the services and replace every vulnerable artifact. The remaining uncertainty is not whether CVE-2026-50506 exists, but how quickly attackers can turn Microsoft’s confirmed resource-exhaustion flaw into a reproducible request.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 - Official source: devblogs.microsoft.com
Announcing ASP.NET Core OData 9 Official Release - OData
ASP.NET Core OData 9 has been officially released and is available on NuGet. ASP.NET Core OData 9 supports .NET 8 or later.devblogs.microsoft.com
