CVE-2024-21907: Upgrade Newtonsoft.Json to 13.0.1 to prevent DoS

Newtonsoft.Json versions prior to 13.0.1 contain a well-documented flaw—tracked as CVE-2024-21907—where deeply nested or crafted JSON can force the library into a StackOverflow or resource‑exhaustion condition when parsing or serializing, producing a remote-denial‑of‑service (DoS) vector for applications that accept untrusted JSON. (nvd.nist.gov) (github.com)

Background / Overview​

Newtonsoft.Json (a.k.a. Json.NET) is one of the most widely used JSON libraries in the .NET ecosystem. Over many years it has been embedded directly in projects, bundled with third‑party packages, and even included inside vendor distributions. That ubiquity means a vulnerability in its core parsing or serialization logic has outsized operational consequences across application servers, desktop tools, and platform components.
The specific weakness cataloged as CVE‑2024‑21907 is a class of improper handling of exceptional conditions (CWE‑755). In practice, unbounded recursion and unprotected stack usage in serialization code, combined with unbounded nested parsing in deserialization, let an attacker craft JSON payloads with extremely high nesting depth that either (a) consume CPU and memory during deserialization, or (b) trigger StackOverflowException during serialization/ToString-style operations. The advisory and subsequent advisories confirm the vulnerability affects all versions earlier than 13.0.1 and that the fix was introduced in 13.0.1. (github.com) (osv.dev)
The NVD entry for CVE‑2024‑21907 summarizes the core risk: crafted data passed to JsonConvert.DeserializeObject may cause a StackOverflow exception and DoS, and depending on how the library is used, an unauthenticated, remote actor may be able to trigger the condition. This makes the issue more than a theoretical recursion bug—exposures in networked services that accept JSON from untrusted sources can be practical attack surfaces. (nvd.nist.gov)

---

What technically goes wrong​

Root cause, simply explained​

Newtonsoft.Json historically used recursive algorithms for traversing JSON object graphs during serialization and deserialization. When no conservative limits are enforced, JSON with extremely deep nesting (for example, repeating {a:{a:{... many thousands of times) produces:

• During deserialization: long-running parsing that consumes CPU and memory as objects are built; with sufficient depth this can saturate thread execution and memory, effectively creating a resource exhaustion DoS.
• During serialization or when calling JObject.ToString(): recursive algorithms hit the thread stack and throw a StackOverflowException, which terminates the process unless handled at the application boundary.

Public advisories and reproductions show thresholds in the order of tens of thousands of nested levels for a full StackOverflow, and millions for high-latency CPU exhaustion depending on hardware and runtime. These practical figures vary with environment, but the pattern—deep nesting → CPU/memory/stack collapse—is consistent. (github.com, security.snyk.io)

Repro pattern (conceptual)​

A simple reproduction pattern used in multiple advisories:

• Build a JSON string with N nested object opens, e.g. string.Concat(Enumerable.Repeat("{a:", N)) + "1" + string.Concat(Enumerable.Repeat("}", N));
• Call JsonConvert.DeserializeObject(json) or JObject.Parse(json);
• Observe CPU spike and memory allocation during parse; then call ToString() or JsonConvert.SerializeObject(parsed) to reproduce StackOverflow at lower nesting thresholds.

The GitHub advisory and public PoCs document that deserialization tends to cause long-running consumption while serialization/ToString provokes a stack crash faster. This distinction matters for defensive strategies. (github.com, security.snyk.io)

---

Who’s affected and how severe is the risk?​

Broad impact vectors​

• 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 can be particularly troublesome: an IIS worker process that crashes repeatedly because of StackOverflowExceptions can cause application pool stoppage and extended downtime, complicating recovery operations. (github.com, scout.docker.com)

Severity and scoring​

CVE‑2024‑21907 has been assigned a High severity (CVSS v3 base 7.5) by multiple aggregators. The vector reflects network accessibility and the lack of required privileges in many scenarios—i.e., 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. (github.com, osv.dev)

Microsoft product surface (SQL Server example)​

Vendor distributions sometimes include Newtonsoft.Json inside product binaries. Microsoft’s SQL Server cumulative updates, for example, have begun shipping an updated Newtonsoft.Json.dll at the patched 13.0.1.x version in recent CUs. The published KB for SQL Server 2022 CU20 lists Newtonsoft.json.dll 13.0.1.25517 in the file manifest, confirming that Microsoft incorporated the fixed library into that SQL Server release. If you run SQL Server tooling or management components that parse JSON (or ship plugins that do), that built-in dependency matters for risk and mitigation planning. (support.microsoft.com)

---

Confirmed fixes and official remediation paths​

Two remediation approaches are both recommended and corroborated across advisories:

• Upgrade: 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. (github.com, osv.dev)
• Configuration mitigation (temporary): Set an explicit maximum parse depth in JsonSerializerSettings so that extremely nested inputs fail fast with a JsonReaderException instead of inducing StackOverflow 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. (github.com, security.snyk.io)

---

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 Newtonsoft.Json 13.0.1 (or later), 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. (support.microsoft.com)
• 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 in the API layer (e.g., max content length = 1–10 MB depending on expected use).
• Network-level controls:
• Restrict access to JSON‑accepting endpoints to known clients where possible.
• 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 in hosted environments.
• 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 (no independent NuGet reference), request guidance and updated packages from vendors.
• Apply vendor-supplied hotfixes or configuration changes; where vendors cannot patch, isolate the component until a path forward exists.

---

How to detect vulnerable installs and examples of checks​

• PowerShell quick check (search server disks for the DLL and show version info):
• Find files:
  Get-ChildItem -Path C:\ -Filter Newtonsoft.Json.dll -Recurse -ErrorAction SilentlyContinue
• Show file version:
  ICODE.VersionInfo.FileVersion[/ICODE]

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 updated in the KB—use that as a reference when validating patched dependencies. (support.microsoft.com)

• Codebase search:
• Search your 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 that need attention. (security.snyk.io, github.com)

---

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.

---

Why simply “library upgrade” is necessary (and why it’s not always easy)​

Upgrading to 13.0.1 is the correct fix because it changes library defaults and addresses the underlying recursive behavior. However, three practical friction points arise:

• Transitive dependencies: Many packages include Newtonsoft.Json as a dependency or embed a copy of the DLL. Upgrading those applications can require vendor cooperation or rebuilding third‑party tooling.
• Binary‑bundled DLLs: Products that ship a private copy of Newtonsoft.Json in their installation directory may not honor a systemwide NuGet update—these must be patched by the vendor or via vendor patch channels (for example, Microsoft issuing updated CU files that replace the DLL). The SQL Server CU manifest shows the vendor approach for Microsoft products. (support.microsoft.com)
• Operational constraints: Patching libraries often requires testing and a controlled rollout—especially for enterprise applications and appliances—so mitigations like MaxDepth and network controls remain important while patches are scheduled.

These tradeoffs mean remediation planning must be pragmatic: inventory → prioritize network-exposed services → apply fixes/mitigations with measurable rollback/testing plans.

---

Risk analysis — strengths, residual risks, and likely attacker behavior​

• Strengths
• A clear, single‑library fix exists (13.0.1) and is straightforward to apply for codebases that use NuGet-managed dependencies.
• Multiple public advisories and scanners have visible PoCs and consensus on the vulnerability, which helps defenders quickly validate and test fixes. (github.com, security.snyk.io)
• Residual risks
• Long tail of embedded and vendor-supplied binaries that may not be patched promptly.
• Attackers may weaponize the low-effort nature of the exploit against public-facing APIs and microservices, particularly where rate limits and input validation are weak.
• Detection is non-trivial in environments where large, legitimate JSON payloads are normal (e.g., document stores, telemetry ingestion).
• Likely attacker tactics
• Opportunistic DoS against APIs that parse JSON payloads without pre‑validation.
• Targeting management and automation endpoints where JSON parsing may be unauthenticated or allowed from broad networks.
• Chaining DoS with other weaknesses (e.g., lack of process isolation under IIS) to force prolonged outages or to mask other malicious activity.

These considerations mean defenders should treat CVE‑2024‑21907 as a high-priority operational risk where remediation is not purely a developer task but an infrastructure and vendor‑management issue. (nvd.nist.gov, wiz.io)

---

Real-world signals and vendor responses​

• Public vulnerability databases, security vendors, and the GitHub Advisory Database list the issue and mark 13.0.1 as the first patched release. Scanners such as Snyk and platform advisories include reproduction details and mitigation guidance. (security.snyk.io, github.com)
• Microsoft’s own product updates demonstrate vendor adoption: the SQL Server CU manifest for a recent cumulative update shows the updated Newtonsoft.Json.dll version, indicating that Microsoft acknowledged and remedied the dependency inside that product line. This pattern is important: large vendors that embed third‑party libraries generally incorporate fixes into product updates rather than expecting administrators to patch a DLL in place. (support.microsoft.com)
• Internal forums and project issue trackers for large open‑source projects have active conversations about upgrading embedded or referenced Newtonsoft.Json DLLs—this is typical in large ecosystems and underlines the need for supply‑chain scanning in CI/CD. (github.com)

---

Recommended immediate action plan (first 72 hours)​

• Identify public/Internet‑facing endpoints that accept JSON and place them in a high‑priority bucket.
• Apply temporary network controls (WAF rules, rate limiting, IP allow‑lists) to the highest‑risk endpoints.
• Set or enforce MaxDepth in server code where you cannot immediately upgrade the library.
• Schedule and test upgrades to Newtonsoft.Json 13.0.1 in development and staging, and plan a controlled production rollout.
• Contact third‑party vendors and appliance providers to confirm whether their products include vulnerable Newtonsoft.Json binaries and request patch timelines.
• Monitor logs for spikes in JSON‑related parsing failures, StackOverflowExceptions, 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. (nvd.nist.gov, github.com, support.microsoft.com)

---

Newtonsoft.Json’s recursive parsing behavior and the resulting availability impact are representative of 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. Audit your dependencies, tighten JSON parsing assumptions, and ensure your vendor update channels are active and trusted.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center