CVE-2022-29117: Regular expression denial of service in .NET

On May 10, 2022, Microsoft disclosed CVE-2022-29117, a denial-of-service vulnerability in .NET caused by a regular expression that is vulnerable to catastrophic backtracking. In plain terms: an attacker who can supply input to a .NET application that runs a vulnerable regex pattern can craft a string that forces the regex engine into exponential-time evaluation, pegging a CPU core (or several) and making the affected service unresponsive to legitimate traffic. No authentication or user interaction is required beyond the ability to send input the application will run through the pattern, which is what makes regular expression denial of service (ReDoS) bugs in widely used runtimes like .NET worth taking seriously even though they don't lead to data compromise.

This class of bug — CWE-1333, Inefficient Regular Expression Complexity — has shown up repeatedly across the .NET ecosystem. CVE-2022-29117 was one of several ReDoS advisories Microsoft shipped for .NET in the first half of 2022, alongside earlier and later fixes for similar backtracking issues in the runtime and in ASP.NET Core's request-handling stack. The recurring pattern is instructive: regex-based input validation and parsing logic embedded deep in a runtime's base class libraries is an easy thing to overlook during security review, because the code "just validates a string" and doesn't look like an attack surface until someone works out an input that makes the engine backtrack combinatorially.

Affected versions and components

CVE-2022-29117 affects the .NET runtime's regular expression engine (System.Text.RegularExpressions) as shipped with .NET 6.0, which was the current long-term-support release at the time of disclosure. Any application — ASP.NET Core web app, background service, desktop app, or library — that ran on an unpatched .NET 6.0 runtime and exercised the vulnerable regex pattern with attacker-influenced input was exposed. Because the flaw lives in the runtime itself rather than in application code, exposure wasn't limited to a specific framework feature; it applied wherever the affected pattern-matching path in the base class libraries was reachable with untrusted input.

As with most Patch Tuesday .NET advisories, Microsoft shipped the fix as part of the regular monthly servicing release for the supported .NET channel(s) at that time, distributed through the .NET SDK and runtime installers, Windows Update (for in-box components where applicable), and the corresponding container base images and package manager feeds. Organizations running .NET 6.0 in production — whether on Windows, Linux containers, or Azure App Service — needed to pull the updated SDK/runtime and redeploy, since simply patching the OS is not sufficient when the vulnerable code ships inside the .NET runtime itself.

If you're auditing for exposure today, the practical question isn't "did we apply the May 2022 Windows Update" — it's "what version of the .NET 6.0 runtime is actually loaded by each service, container image, and CI build agent," because .NET runtimes are frequently side-loaded or self-contained inside application deployments and can silently drift out of sync with the OS-level patch baseline.

CVSS, EPSS, and KEV context

Microsoft's advisory rated CVE-2022-29117 as High severity, consistent with the CVSS profile typical of network-exploitable denial-of-service issues: attack vector network, low attack complexity, no privileges required, no user interaction, and a high impact to availability with no impact to confidentiality or integrity. That combination is exactly what you'd expect from a ReDoS bug — an attacker doesn't read or modify anything, they just make the regex engine do a very large amount of unnecessary work.

On EPSS (Exploit Prediction Scoring System), ReDoS vulnerabilities in runtime libraries generally sit well below the threshold that indicates active, widespread exploitation, because there's no follow-on payload or persistence to weaponize — the "exploit" is a crafted string, and the impact is transient resource exhaustion rather than compromise. EPSS scores are dynamic and move over time as scanning and exploitation telemetry changes, so treat any single point-in-time percentile as a rough signal rather than a fixed fact; the more durable takeaway is that this CVE has not attracted the kind of active-exploitation attention that would push it into CISA's Known Exploited Vulnerabilities (KEV) catalog, and it does not appear on that list. That's a reasonable outcome for a DoS-only flaw with no confidentiality or integrity impact, but "not in KEV" should never be read as "not worth patching" — availability is still one of the three legs of the security triad, and a resource-exhaustion bug reachable pre-auth over the network is a real production risk for any internet-facing .NET service.

Timeline

• May 10, 2022 — Microsoft published the security advisory for CVE-2022-29117 as part of its regular Patch Tuesday release cycle, along with the updated .NET 6.0 runtime and SDK builds that address the backtracking issue.
• Ongoing — the advisory has since been indexed in NVD and mirrored by the major vulnerability databases and scanners; no subsequent revisions have materially changed the severity assessment.
• To date — there is no public evidence of large-scale exploitation campaigns targeting this specific CVE, and it remains absent from CISA's KEV catalog, though ReDoS as a bug class continues to be found and patched across many language runtimes and libraries.

Because .NET ships security fixes on a predictable monthly cadence tied to Patch Tuesday, the practical lesson from this timeline isn't about a long window of unpatched exposure — it's about how quickly the fix reached production. For most .NET shops, the gap between "Microsoft ships a runtime update" and "every service actually running that runtime version" is where the real risk lives.

Remediation steps

1. Identify every .NET 6.0 runtime instance in your environment. This includes VMs, on-prem servers, container base images, self-contained deployments that bundle their own runtime, and CI/CD build agents that compile or test against the SDK.
2. Upgrade the .NET SDK and runtime to a version that includes the May 2022 servicing fix, using your platform's standard channel — the official installers, your Linux distribution's package manager, or updated Microsoft container base images.
3. Rebuild and redeploy affected applications. Because the fix lives in the runtime, an application built or deployed against a stale, self-contained runtime will remain vulnerable even after the host OS is patched — redeployment is required, not optional.
4. Apply regex timeouts as defense-in-depth. Independent of this specific CVE, any application-level regular expression evaluated against untrusted input should specify a matchTimeout (via the Regex constructor or RegexOptions) so a single pathological pattern can't monopolize a thread indefinitely. This is good practice generally and mitigates unknown or future ReDoS issues, not just this one.
5. Audit custom regex patterns in your own codebase. This CVE was in the runtime, but application developers write plenty of their own regexes for validation, routing, and parsing. Review patterns with nested quantifiers or ambiguous alternation (classic ReDoS shapes) and test them against crafted worst-case inputs.
6. Add monitoring for anomalous CPU consumption on request-handling processes, which can serve as an early indicator of ReDoS exploitation attempts even for vulnerabilities not yet publicly known.

How Safeguard Helps

CVE-2022-29117 is a textbook example of why software supply chain visibility has to extend past your own source code and into the runtimes and platforms your applications are built on. Most teams have decent visibility into their direct application dependencies, but far less into "which exact .NET runtime build is actually deployed in this container" — and that's precisely the gap this CVE lives in.

Safeguard continuously inventories the components in your software supply chain — including language runtimes, SDKs, and the container base images and build agents they're embedded in — and correlates that inventory against newly disclosed CVEs like this one as soon as they land in NVD and vendor advisories. Instead of manually cross-referencing Patch Tuesday bulletins against every service's deployment manifest, Safeguard surfaces exactly which of your services, images, and pipelines are running an affected .NET version, so remediation work is scoped precisely rather than guessed at.

Because this vulnerability required a runtime upgrade and redeploy rather than a code change, Safeguard's build and pipeline integrations are particularly useful here: policy gates can flag CI/CD jobs and container builds that still pin an outdated SDK or base image, catching the drift between "we patched it once" and "it's still creeping back in via a stale Dockerfile or a self-contained publish profile." Combined with SBOM generation and provenance tracking across your build pipeline, this gives security and platform teams a durable answer to "are we exposed to CVE-2022-29117 today" — not just at disclosure time, but every time a new build ships.