Microsoft has confirmed that a high-severity vulnerability in Newtonsoft.Json, the ubiquitous JSON library for .NET, is being addressed through cumulative updates for SQL Server and other products. The flaw, tracked as CVE-2024-21907 with a CVSS score of 7.5, allows unauthenticated attackers to trigger denial-of-service conditions by sending specially crafted JSON payloads that cause stack overflows or resource exhaustion. All versions prior to 13.0.1 are affected, and the fix—which fundamentally changes how the library handles deeply nested objects—was introduced in that release. Organizations running .NET applications that parse JSON from untrusted sources face an immediate operational risk, especially those with Internet-facing APIs.

The Vulnerability: Unbounded Recursion in JSON Parsing

The vulnerability stems from unbounded recursion in Newtonsoft.Json's serialization and deserialization algorithms. When processing JSON with extremely deep nesting—thousands of nested {a:{a:{...}}} constructs—the library's recursive calls rapidly consume CPU and memory during deserialization, while serialization or calling JObject.ToString triggers a StackOverflowException that can crash the process. Public proofs of concept show that an attacker can craft a payload with tens of thousands of nesting levels to reliably crash an IIS worker process or slow a server to a halt. Because many .NET web applications and microservices use JsonConvert.DeserializeObject or JObject.Parse directly on user-supplied data, the attack surface is extensive.

Detailed technical analysis reveals that the core issue is classified under CWE-755: Improper Handling of Exceptional Conditions. Newtonsoft.Json historically imposed no conservative limits on parse depth, allowing an adversary to dictate recursion depth through input data. The fix in version 13.0.1 introduces sensible default depth limits and alters the internal recursive algorithms to prevent stack overflow and resource exhaustion. However, simply upgrading is not always straightforward. Thousands of projects reference Newtonsoft.Json as a direct or transitive dependency, and many commercial products embed the DLL without exposing a NuGet update path. Microsoft's own SQL Server installation, for instance, ships with Newtonsoft.Json.dll as part of its components; the SQL Server 2022 Cumulative Update 20 (KB5031777) replaces this with version 13.0.1.25517, confirming the vendor's acknowledgment and patch delivery.

Who Is Affected and How Severe Is the Risk?

Any .NET application that calls JsonConvert.DeserializeObject, JObject.Parse, JObject.ToString, or JsonConvert.SerializeObject with untrusted input is potentially vulnerable. Network-exposed APIs that accept JSON payloads are the highest-risk targets because they allow remote actors to deliver crafted payloads without needing credentials. Services hosted under IIS are particularly troublesome: an IIS worker process that crashes repeatedly because of StackOverflowExceptions can cause application pool stoppage and extended downtime, complicating recovery operations.

The vulnerability's high CVSS v3 base score of 7.5 reflects its network accessibility and the lack of required privileges in many scenarios—an attacker who can submit JSON input to a vulnerable endpoint can trigger availability impact without authentication. Independent vulnerability databases and scanners reproduce the score and emphasize DoS as the primary consequence. Real-world signals indicate that the vulnerability is actively tracked and patched across the ecosystem. The GitHub Advisory Database, National Vulnerability Database, and multiple security vendors have published detailed advisories with reproduction steps and mitigation guidance. Microsoft's MSRC portal lists the vulnerability and links to the KB article for SQL Server CU20, demonstrating a coordinated vendor response. In open-source communities, project maintainers are systematically upgrading their Newtonsoft.Json references to 13.0.1, often in patch releases.

Remediation: Upgrade and Mitigation

Two remediation approaches are both recommended and corroborated across advisories: upgrade and configuration mitigation.

Upgrade: The Preferred Fix

Update Newtonsoft.Json to 13.0.1 (or a later patched release). The GitHub advisory and major security trackers list 13.0.1 as the first patched version. This is the preferred and most robust fix because it changes library defaults to limit depth and prevents the pathological recursion that triggers crashes. For application code you control, update NuGet package references to 13.0.1, rebuild, run tests, and deploy. For vendor or packaged products, check vendor KBs and update binaries per vendor guidance. Microsoft’s SQL Server CU manifests and KB pages show the fixed DLL version in the CU; apply the relevant CU if your environment uses those components.

Temporary Mitigation: Set MaxDepth

Set an explicit maximum parse depth in JsonSerializerSettings so that extremely nested inputs fail fast with a JsonReaderException instead of inducing stack overflow or lengthy CPU consumption. For example:

JsonConvert.DefaultSettings = () => new JsonSerializerSettings { MaxDepth = 128 };

This global setting limits nested parsing and is a useful stopgap in legacy code or where an immediate library update is impractical. Advisories note that 13.0.1 also changes sensible defaults, so the configuration workaround is primarily a mitigation until a library update can be applied.

Practical Mitigation Checklist for Windows and .NET Administrators

Apply these steps in priority order to reduce exposure quickly and safely.

  • Inventory: Find every instance of Newtonsoft.Json across your estate.
  • Search code repositories and project files for package references to Newtonsoft.Json.
  • Scan deployed servers and product installations for the DLL (file name: Newtonsoft.Json.dll) and record assembly versions.
  • Patch hosts and builds:
  • For application code you control: update NuGet package references to 13.0.1, rebuild, test, deploy.
  • For vendor products: check vendor KBs and apply updates. For Microsoft SQL Server, apply the relevant cumulative update that ships the fixed DLL.
  • Temporary code mitigations (where updates are slow):
  • Set MaxDepth in JsonSerializerSettings globally or per‑parser.
  • Validate incoming JSON shapes and reject suspiciously deep or oversized payloads before parsing.
  • Enforce payload size limits in application gateways or API layer (e.g., max content length 1–10 MB).
  • Network-level controls:
  • Restrict access to JSON‑accepting endpoints to known clients.
  • Use a Web Application Firewall (WAF) or API gateway with custom rules to detect and block unusually nested JSON patterns (see detection guidance below).
  • Monitoring and detection:
  • Instrument for high CPU or memory spikes correlated with JSON parse calls.
  • Log and alert on StackOverflowException or frequent process restarts.
  • Use dependency scanners and CI checks to catch older Newtonsoft.Json package versions prior to release.
  • Supply‑chain and third‑party vendors:
  • For third‑party packages and appliances that include Newtonsoft.Json embedded, request guidance and updated packages from vendors.
  • Apply vendor-supplied hotfixes; where vendors cannot patch, isolate the component.

Detection Heuristics and Practical WAF Rules

Because the exploit vector is obvious (abnormally deep nesting), detection can be pragmatic and conservative:
- Block or throttle requests containing JSON with nesting depth > 128–1024 depending on legitimate application needs.
- Flag JSON bodies larger than expected for the API’s contract—typical REST APIs rarely need multi‑megabyte deeply nested objects.
- Use regex or streaming JSON parsers in the API gateway that can quickly scan nesting depth without full materialization; drop or challenge (403 / 413) suspicious payloads.
- Instrument servers to correlate spikes in CPU / GC activity with requests that included large JSON payloads.

These rules reduce false positives if tuned to application expectations, and they are useful interim protections while libraries are updated.

How to Detect Vulnerable Installs

  • PowerShell quick check (search server disks for the DLL and show version info):
    powershell Get-ChildItem -Path C:\ -Filter Newtonsoft.Json.dll -Recurse -ErrorAction SilentlyContinue | ForEach-Object { [System.Diagnostics.FileVersionInfo]::GetVersionInfo($_.FullName).FileVersion }
    Any file version earlier than 13.0.1.x should be prioritized for update. Microsoft’s CU manifest shows 13.0.1.25517 for SQL Server components—use that as a reference.
  • Codebase search: Search repositories for uses of JsonConvert.DeserializeObject, JObject.Parse, JsonConvert.SerializeObject, and direct JObject.ToString calls. Prioritize those that consume user-supplied data.
  • CI/CD and SBOM: Add dependency scanning (Snyk, OSS Index, GitHub Dependabot) into CI pipelines. These tools already flag CVE‑2024‑21907 and will identify transitive uses.

Broader Implications and Supply Chain Considerations

CVE-2024-21907 exemplifies a broader class of supply‑chain risks: a small library bug can cascade into system outages when the library is embedded and exposed on networked surfaces. The deep embedding of widely used libraries like Newtonsoft.Json means that a single bug can ripple through countless systems, from line-of-business applications to enterprise infrastructure. Defenders must maintain comprehensive dependency inventories, enforce depth limits as a defense-in-depth measure, and pressure vendors to keep their bundled components up to date. While the fix is clear and available, the operational complexity of applying it across heterogeneous environments ensures that CVE-2024-21907 will remain a concern for months to come.

  1. Identify public/Internet‑facing endpoints that accept JSON and place them in a high‑priority bucket.
  2. Apply temporary network controls: WAF rules, rate limiting, IP allow‑lists to the highest‑risk endpoints.
  3. Set or enforce MaxDepth in server code where you cannot immediately upgrade the library.
  4. Schedule and test upgrades to Newtonsoft.Json 13.0.1 in development and staging, and plan a controlled production rollout.
  5. Contact third‑party vendors and appliance providers to confirm whether their products include vulnerable Newtonsoft.Json binaries and request patch timelines.
  6. Monitor logs for spikes in JSON‑related parsing failures, StackOverflowException, or repeated worker process crashes.

These steps balance immediate risk reduction and long‑term remediation, and they prioritize continuity while closing the vulnerability vector.

Conclusion

CVE‑2024‑21907 is a high‑impact availability vulnerability rooted in well-understood parsing and serialization recursion risks in Newtonsoft.Json versions prior to 13.0.1. A straightforward, verified remediation—the 13.0.1 library update—exists, and major product vendors including Microsoft have begun rolling the fixed DLL into product cumulative updates. However, the operational reality of transitive dependencies, embedded binaries, and legacy vendor software means many organizations will need a mixed strategy: inventory, patch where possible, apply MaxDepth or input validation mitigations, and harden network exposure for JSON‑accepting endpoints. Treat this issue as a priority for both developers and infrastructure teams: update where you control code, apply mitigations where you cannot, and verify vendor-supplied products are on a patched track. Audit your dependencies, tighten JSON parsing assumptions, and ensure your vendor update channels are active and trusted.