An anonymous researcher discovered that a single malformed network request could bring down any .NET 9.0 or 10.0 application. The flaw lived inside a high-performance Base64Url decoder introduced less than two years ago. It was publicly known before Microsoft had a fix. Here is the full picture.
What Is CVE-2026-26127?
CVE-2026-26127 is a denial of service vulnerability in the .NET runtime and the Microsoft.Bcl.Memory NuGet package, disclosed and patched on March 10, 2026 as part of Microsoft's monthly Patch Tuesday security release. The flaw exists due to an out-of-bounds read when decoding malformed Base64Url input. An unauthenticated remote attacker can exploit this condition to crash any affected .NET application by sending a crafted network request containing malformed Base64Url-encoded data.
What distinguishes this vulnerability from routine patch cycle disclosures is its classification as a zero-day. The vulnerability was publicly disclosed before a patch was available. That means for an unknown window of time, the technical mechanics of this flaw were accessible to anyone paying attention—while the organizations running vulnerable applications had no official fix to apply.
The flaw was attributed to an anonymous researcher. Microsoft credited an anonymous researcher with the discovery and provided no additional information about the researcher's identity, the timeline of responsible disclosure, or the channel through which the vulnerability was reported prior to the patch being made available.
A zero-day is a vulnerability that was publicly known or actively exploited before the software vendor released an official patch. The term refers to the number of days the vendor has had to address the problem—zero. CVE-2026-26127 meets this definition because it was publicly disclosed prior to Microsoft shipping a fix on March 10, 2026.
Technical Root Cause: The Base64Url Decoder
Base64Url is a variant of standard Base64 encoding, defined in RFC 4648, that replaces the + and / characters with - and _ respectively, and omits or makes optional the = padding character. This makes it safe for use in URLs and HTTP headers without percent-encoding. Base64Url is used extensively in modern web infrastructure, particularly for JSON Web Tokens (JWTs), OAuth authorization codes, PKCE verifiers, and other mechanisms where binary data must be transmitted in URL-safe string form.
The flaw resides in the Base64Url decoding implementation introduced in Microsoft.Bcl.Memory to provide high-performance encoding and decoding compliant with RFC 4648. This implementation, shipped with .NET 9.0, leverages unsafe pointer arithmetic and SIMD (Single Instruction, Multiple Data) processor instructions to decode Base64Url data significantly faster than conventional approaches.
The underlying weakness is classified as CWE-125 (Out-of-bounds Read) combined with CWE-129 (Improper Validation of Array Index). The vulnerability exists where the pointer advances through the input buffer without strictly validating the remaining length against the required block size for decoding. When a malformed Base64Url string is supplied—one whose length does not align with expected block boundaries—the pointer arithmetic leads to a read operation that extends beyond the allocated memory buffer.
In managed .NET code, this condition surfaces as a System.IndexOutOfRangeException that goes unhandled on a critical runtime thread. In lower-level execution contexts involving the unsafe code paths and SIMD instructions used by the high-performance decoder, it can manifest as an access violation at the operating system level. Either outcome terminates the .NET process immediately.
Attack Surface and Exploitation Path
The attack surface for CVE-2026-26127 is broad. Any network-facing .NET 9.0 or 10.0 application that accepts and processes user-controlled Base64Url-encoded data is potentially vulnerable. This encompasses an enormous category of modern web applications.
Common implementations include JSON Web Token (JWT) validation, OAuth token parsing, and web-safe data transport mechanisms. Every web application that validates a JWT—which is to say, virtually every modern application that handles user authentication—passes Base64Url-encoded data through the runtime. A login endpoint accepting a malformed bearer token in an Authorization header is a viable attack vector. An API accepting Base64Url-encoded file attachments is equally exposed. An OAuth callback handler processing a malformed authorization code is another example.
The exploitation sequence requires minimal effort and no specialized network position. An attacker identifies a target endpoint that processes Base64Url data, constructs a crafted HTTP request containing a payload designed to trigger the out-of-bounds calculation, and upon processing the request, the application passes the payload to the vulnerable Microsoft.Bcl.Memory decoding function. The out-of-bounds read is triggered immediately, and because the vulnerability exists at the runtime level and involves unsafe memory access, the entire process terminates.
A sustained attack requires nothing more than a loop sending the same malformed request repeatedly. Each crashed process restarts, and each restart is equally vulnerable until the patch is applied. There is no computational expense, no cryptographic overhead, no sophisticated evasion technique required. The operational cost of a prolonged denial of service campaign against an unpatched service is negligible.
CVSS Scoring and What It Tells Us
CVE-2026-26127 carries a CVSS v3.1 base score of 7.5, rated High. The full vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:U/RL:O/RC:C. Each component is meaningful:
- AV:N (Attack Vector: Network) — exploitable remotely over the internet, no physical or local access required.
- AC:L (Attack Complexity: Low) — no special conditions, race conditions, or prior reconnaissance needed.
- PR:N (Privileges Required: None) — the attacker requires no account or authentication on the target system.
- UI:N (User Interaction: None) — no victim action is needed; the attacker triggers the flaw directly.
- C:N / I:N (Confidentiality / Integrity: None) — no data is disclosed or modified; this is a pure availability attack.
- A:H (Availability Impact: High) — complete service disruption; the application process terminates immediately.
The temporal modifiers are also informative. E:U indicates exploit code is unproven at this time. RL:O indicates an official fix is available. RC:C indicates confirmed vulnerability status. The 7.5 score accurately reflects the threat profile. For organizations operating internet-facing services, the practical risk can exceed what the base score alone conveys—repeated crashes can cause cascading failures in load-balanced environments, disrupt dependent microservices, and require operational intervention each time.
The Zero-Day Context: Public Before the Patch
According to Microsoft, this vulnerability was publicly disclosed prior to patches being made available. What this means in practice is that the vulnerability—or at minimum, enough technical information about it to identify the affected code path—entered the public domain before March 10, 2026, the date Microsoft shipped the fix.
This is a qualitatively different risk posture from a standard patch cycle disclosure. When a vulnerability is revealed simultaneously with its patch, administrators face a race between attackers weaponizing the information and defenders applying the fix. When a vulnerability is publicly known before a patch exists, that race has already started and defenders do not yet have the means to finish it.
The CVE record itself was reserved on February 11, 2026, nearly a month before the patch was published. This reservation timestamp is consistent with a coordinated disclosure process that, for some reason, resulted in partial or full public visibility of the vulnerability details before the fix was complete.
"Out-of-bounds read in .NET allows an unauthorized attacker to deny service over a network." — Microsoft Security Response Center, CVE-2026-26127 advisory, March 10, 2026
Despite the zero-day classification, Microsoft assessed that exploitation is unlikely and reported no evidence of active exploitation at the time the patch was released. The EPSS (Exploit Prediction Scoring System) score corroborates this, sitting at an extremely low 0.00041. However, that assessment reflects the state of affairs at the time of patching. The public disclosure of vulnerability mechanics means threat actors now possess the technical context needed to develop functional denial of service tools. The window of elevated risk—between public knowledge and widespread patching—is the period demanding the most vigilance.
Affected Products and the Transitive Dependency Problem
The vulnerability affects two categories of software. The first is the .NET runtime itself. Any application running .NET 9.0 versions from 9.0.0 through 9.0.13, or .NET 10.0 versions from 10.0.0 through 10.0.3, is affected on all supported platforms: Windows (x86, x64, Arm, Arm64), Linux (x64, Arm, Arm64, musl variants), and macOS (x64, Arm64).
The second category is applications using the standalone Microsoft.Bcl.Memory NuGet package. This package was created to backport the high-performance Base64Url decoding capabilities to applications targeting earlier framework versions. Any package or application referencing Microsoft.Bcl.Memory versions 9.0.0 through 9.0.13 or 10.0.0 through 10.0.3 is vulnerable, regardless of which .NET runtime version it runs on.
This second category introduces a significant complication: the transitive dependency problem. Many popular .NET libraries pull in Microsoft.Bcl.Memory as an indirect dependency without the consuming application's authors necessarily being aware of it. CVE-2026-26127 impacts applications built with idunno.Bluesky, idunno.AtProto, and idunno.AtProto.OAuthCallback due to a transitive dependency on Microsoft.Bcl.Memory. Duende IdentityModel, and the libraries built on top of it, also pulled in the vulnerable package transitively—and Duende's libraries underpin a large portion of the .NET identity and authentication ecosystem, including IdentityServer implementations used across enterprise applications.
The transitive dependency problem means that an organization's vulnerability surface extends beyond the direct packages they manage. Standard package audits that only examine direct dependencies will miss this exposure. Automated dependency scanning tools configured to surface transitive vulnerabilities are necessary for complete visibility.
March 2026 Patch Tuesday: The Broader Picture
CVE-2026-26127 was one of 83 CVEs addressed in Microsoft's March 2026 Patch Tuesday release, and one of two vulnerabilities that arrived with a zero-day designation. Eight vulnerabilities were rated critical and 75 were rated as important in the March 2026 release.
The other zero-day, CVE-2026-21262, was a publicly disclosed elevation of privilege vulnerability in Microsoft SQL Server with a CVSSv3 score of 8.8, assessed as "Exploitation More Likely"—making it the higher-urgency of the two zero-days from a prioritization standpoint. Elevation of privilege vulnerabilities accounted for 55.4% of this month's patches, followed by remote code execution at 20.5%.
Also of note was CVE-2026-26144, an information disclosure vulnerability in Microsoft Office Excel with implications for Microsoft Copilot. According to Microsoft's advisory, a successful exploit could cause Copilot Agent mode to exfiltrate data via unintended network egress, enabling a zero-click information disclosure attack. This represents an emerging class of AI-adjacent vulnerability where the attack surface extends into AI agent behavior.
Against that backdrop, CVE-2026-26127 stands out not for its severity score but for its combination of characteristics: no authentication required, no user interaction required, cross-platform impact, zero-day status, and an attack surface that spans the entire authentication and API layer of modern .NET applications.
Remediation: What You Need to Do Now
Update the .NET Runtime
Inventory all hosts and services running .NET 9.0 or .NET 10.0 using dotnet --info to list installed runtimes and SDKs. Organizations running .NET 9.0 must update to version 9.0.14. Organizations running .NET 10.0 must update to version 10.0.4. Updates are available through Windows Update, the .NET download portal, and operating system package managers on Linux—Ubuntu users should apply the USN-8085-1 update, which provides patched dotnet9 and dotnet10 packages.
Update Microsoft.Bcl.Memory via NuGet
Updating the runtime alone does not automatically update NuGet package references in application binaries. Applications that directly or transitively reference Microsoft.Bcl.Memory must update the package explicitly to version 9.0.14 or 10.0.4.
# .NET CLI
dotnet package update Microsoft.Bcl.Memory
# NuGet Package Manager Console
Update-Package -Id Microsoft.Bcl.MemoryAfter updating package references, the application must be recompiled and redeployed. A package reference update without a rebuild does not remediate the vulnerability in running applications.
Audit Transitive Dependencies
Run a full dependency audit using dotnet list package --include-transitive to reveal indirect references. Any library found to depend on a vulnerable version of Microsoft.Bcl.Memory should be updated to a release that bumps its own dependency to a patched version, or pinned directly at the application level. If your application uses Duende IdentityModel or frameworks in the idunno ecosystem, check their release notes—Duende shipped patch releases across their library stack specifically to resolve this transitive exposure.
Container and CI/CD Environments
The patch must be applied not just to development workstations but to all production servers, CI/CD pipelines, and container images that use affected .NET versions. Base container images built on .NET 9.0 or 10.0 must be rebuilt from updated base images. Existing running containers are not remediated by host-level updates alone.
Interim Mitigations
For organizations that cannot immediately apply the patch, a layered approach reduces exposure. Network segmentation can isolate vulnerable applications from untrusted networks. Input validation at a WAF or API gateway layer—rejecting requests whose Base64Url-encoded fields do not conform to expected length and character constraints—may intercept malformed payloads before they reach the vulnerable decoding code. Rate limiting reduces the effectiveness of sustained crash-loop attacks. None of these substitute for patching.
Exploitation Likelihood and Threat Outlook
Microsoft's official exploitability assessment is "Exploitation Unlikely." The EPSS score of 0.00041 places this vulnerability in the lowest percentile of predicted near-term exploitation probability. At the time of writing, no public proof-of-concept exploit code has been identified, and no threat intelligence reporting has surfaced evidence of active exploitation campaigns targeting CVE-2026-26127.
That posture is not static. The combination of zero-day status and the simplicity of the exploitation path means the technical barrier to developing a working denial of service tool is low. The CVE description itself—"out-of-bounds read when decoding malformed Base64Url input"—provides enough directional context for a competent reverse engineer to locate the vulnerable code path in an unpatched binary without access to the original researcher's report.
Denial of service vulnerabilities attract different attacker profiles than remote code execution. Ransomware operators and espionage actors prioritize code execution. But hacktivist groups, disruption campaigns, and opportunistic actors running automated scanners are all realistic threats for a low-complexity, no-authentication DoS flaw that works across Windows, Linux, and macOS. In a microservices deployment where multiple services share a vulnerable runtime, or where the authentication service runs on .NET 9.0, a single attacking endpoint can cascade disruptions across the entire application stack.
- Patch immediately: Update .NET runtimes to 9.0.14 or 10.0.4 and update
Microsoft.Bcl.MemoryNuGet references, then rebuild and redeploy. - Audit transitive dependencies: Run
dotnet list package --include-transitiveon every project. Direct dependency scans will miss this exposure. - Rebuild container images: Host-level patching does not reach containerized .NET applications. Every affected base image must be rebuilt.
- Monitor for crash patterns: Set up alerts for unusual .NET process termination patterns in application logs as an early indicator of exploitation attempts while patching is underway.
CVE-2026-26127 is a reminder that high-performance optimization in managed runtimes creates real security trade-offs, and that the dependencies we do not explicitly manage can be as dangerous as the ones we do. The anonymous researcher who found it did the ecosystem a service. The question now is how quickly organizations close the window that disclosure opened.
Sources: Microsoft Security Advisory CVE-2026-26127 (dotnet/announcements#384, GitHub); Microsoft Security Response Center; BleepingComputer, March 2026 Patch Tuesday; Tenable Research Special Operations, March 2026 Patch Tuesday analysis; CVEReports; Duende Software patch release blog, March 13, 2026; DailyCVE (idunno.Bluesky transitive dependency analysis); Windows Forum CVE-2026-26127 thread; SecPod Blog; MITRE / THREATINT CVE record; GitLab Advisory Database.