CVE-2020-1045: Security feature bypass in ASP.NET Core

CVE-2020-1045 is a security feature bypass vulnerability in Microsoft ASP.NET Core, disclosed and patched by Microsoft in March 2020. The flaw affects how ASP.NET Core applications enforce Cross-Origin Resource Sharing (CORS) policy checks when processing certain web requests, allowing a remote, unauthenticated attacker to bypass a CORS configuration that was intended to restrict which origins could interact with an application's endpoints. In practice, this means an application that trusted its CORS policy to block cross-origin requests from untrusted sites could, in a vulnerable configuration, be reached anyway — undermining a control that many teams treat as a hard boundary rather than defense-in-depth.

Security feature bypass vulnerabilities like this one rarely make headlines the way remote code execution bugs do, but they matter for exactly the reason CORS exists in the first place: browsers rely on it to stop malicious pages from making authenticated cross-origin requests on a victim's behalf. A CORS bypass in the underlying framework can quietly erode that assumption across every application built on the affected runtime, regardless of how carefully individual teams configured their own AddCors policies.

Affected Versions and Components

CVE-2020-1045 lives in the ASP.NET Core shared framework — specifically in the request-handling path responsible for evaluating and applying CORS middleware decisions. Because the defect sits in the framework rather than in application code, every ASP.NET Core application running on an unpatched version of the affected runtime was potentially exposed, independent of how well-written the application's own CORS policy declarations were.

The practical impact was scoped to ASP.NET Core applications that:

• Actively use the CORS middleware (UseCors) to restrict cross-origin access to APIs or endpoints.
• Rely on that CORS enforcement as a meaningful access control boundary (for example, gating access to authenticated APIs consumed by a specific first-party frontend origin).
• Were running on an ASP.NET Core runtime build released prior to Microsoft's March 2020 security update.

Applications that did not use CORS middleware at all, or that already treated CORS as a convenience rather than a security boundary (backed by server-side authentication/authorization), had a lower practical risk profile even if technically running an affected runtime version.

As with most .NET Core runtime advisories, remediation was delivered as an update to the shared framework and SDK rather than a single NuGet package bump — meaning the fix required updating the installed .NET Core runtime/SDK on hosts and, for self-contained deployments, republishing the application against the patched shared framework.

CVSS, EPSS, and KEV Context

Microsoft classified CVE-2020-1045 as a security feature bypass, and public vulnerability databases list it at Medium severity, consistent with a CVSS v3 base score in the 5.x range — reflecting a network-exploitable, low-complexity issue with no privileges or user interaction required, but with limited confidentiality/integrity impact rather than full compromise of the host. This is a meaningfully different risk profile than a remote code execution or privilege escalation bug: exploitation doesn't hand an attacker code execution or data exfiltration directly, but it can strip away a control that other parts of an application's threat model depend on.

CVE-2020-1045 predates the EPSS (Exploit Prediction Scoring System) program's broad public rollout, and it has not been a notable subject of EPSS score revisions since — there is no indication of elevated or rising exploitation-probability scoring associated with this CVE. It also does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there has been no widely reported evidence of active exploitation in the wild. That combination — Medium severity, no KEV listing, low observed exploitation interest — is exactly the profile of vulnerability that tends to get deprioritized in patch cycles, which is part of why it's worth revisiting: "low observed exploitation" is not the same as "not exploitable," and CORS-bypass primitives are frequently chained with other weaknesses (like overly permissive authentication assumptions) to produce a higher-impact outcome.

Timeline

• March 2020 — Microsoft disclosed CVE-2020-1045 through the Microsoft Security Response Center (MSRC) as part of that month's Patch Tuesday release cycle, alongside an update to the ASP.NET Core shared framework that corrected the CORS enforcement logic.
• Post-disclosure — The vulnerability was indexed in the National Vulnerability Database and downstream vulnerability feeds as a Medium-severity security feature bypass. No public proof-of-concept exploitation campaign or CISA KEV addition followed, and it has remained a comparatively low-profile advisory relative to other .NET Core CVEs from the same era.
• Present day — Because the fix landed at the runtime/shared-framework level, any application still running an unpatched .NET Core 2.1 or 3.1-era runtime (both long-term support branches at the time of disclosure) that has never been rebuilt or redeployed against an updated shared framework remains technically exposed, even years later. This is the long tail that matters most for organizations doing supply chain and dependency inventory work today: legacy services that were "patched" at the infrastructure level in 2020 but whose container images or deployment artifacts were pinned to an older shared framework version and never rebuilt.

Remediation Steps

1. Identify affected applications. Inventory every ASP.NET Core service and determine which runtime version each is built against or deployed with — including framework-dependent deployments (which rely on a shared, host-installed runtime) and self-contained deployments (which bundle their own runtime and must be individually rebuilt).
2. Update the .NET Core runtime and SDK. Apply Microsoft's March 2020 (or later) security update to any host running the affected shared framework. For framework-dependent apps, this alone remediates the issue once the host runtime is updated.
3. Rebuild and redeploy self-contained applications. Self-contained deployments and container images that bundle the runtime must be rebuilt against a patched SDK and redeployed — an updated host runtime does not help these artifacts.
4. Audit CORS configuration independent of the patch. Use this as an opportunity to review AddCors policies across services: avoid AllowAnyOrigin() combined with credentialed requests, prefer explicit origin allow-lists, and confirm CORS is not the sole control protecting sensitive endpoints.
5. Add server-side authorization as a backstop. CORS is a browser-enforced convention, not a server-side access control. Ensure authenticated APIs also enforce authorization checks independent of request origin, so that a future CORS-adjacent bypass — in this framework or any other — cannot alone grant unauthorized access.
6. Verify with a rebuilt SBOM. After remediation, regenerate software bills of materials for affected services and confirm the ASP.NET Core shared framework version reflected in build and deployment artifacts actually matches the patched version — not just the version declared in a .csproj or global.json file.

How Safeguard Helps

CVE-2020-1045 is a textbook example of why point-in-time patching isn't the same as sustained remediation. The runtime got fixed in 2020; the risk that lingers today is entirely about drift — container images built from stale base layers, self-contained deployments that were never rebuilt, and legacy services that fell out of the patch cadence once the initial advisory cycle passed. That's a software supply chain visibility problem, not a patching-discipline problem, and it's exactly where Safeguard is built to help.

Safeguard continuously inventories the real, deployed composition of your applications — not just what a manifest or .csproj declares, but what shared frameworks, runtime versions, and dependencies are actually present in the artifacts running in production. That means a service quietly pinned to a pre-March-2020 ASP.NET Core shared framework gets flagged with the same rigor as a newly disclosed critical CVE, rather than disappearing into the long tail of "probably fine" legacy services.

Beyond detection, Safeguard correlates each finding with real-world exploitation signals — including KEV status and EPSS trends — so security and platform teams can tell the difference between a Medium-severity bypass like CVE-2020-1045 that's been quiet for years and a Medium-severity finding that's suddenly trending toward active exploitation. That context turns a flat CVE list into a prioritized remediation queue, and it's what lets teams confidently defer low-urgency findings without losing track of them entirely.

Finally, Safeguard's SBOM generation and drift detection close the loop that manual patch tracking usually misses: once a service is remediated, Safeguard verifies the fix is reflected in the actual build artifact, and flags any future rebuild that reintroduces a stale, vulnerable framework version — whether through a rolled-back base image, a misconfigured pipeline, or an old cached layer. For vulnerabilities like CVE-2020-1045, where the risk is less about whether a patch exists and more about whether it was ever truly applied everywhere it needed to be, that continuous verification is the difference between a finding that gets fixed once and a finding that stays fixed.