Constant MAX_JSON_NESTING_DEPTH 

pub const MAX_JSON_NESTING_DEPTH: usize = 64;

Maximum allowed nesting depth for JSON array/object recursion before check_json_nesting_depth rejects the input.

serde_json itself already caps recursion at a default depth of 128 for every container it enters — deserialize_any/Value, but equally deserialize_seq/deserialize_map (check_recursion! in its de.rs, guarding all three), so ordinary typed struct/Vec deserialization is covered exactly the same as parsing into a bare Value. This workspace never enables the unbounded_depth feature or calls disable_recursion_limit, so pathologically nested JSON cannot crash this workspace via stack overflow regardless of which of these paths a given call site uses. This guard is defense-in-depth, not a vulnerability fix: an early, cheap, byte-level rejection that fails faster and with a repo-specific error type than waiting for serde_json’s own limit, and keeps every untrusted-JSON parse site consistent with the MAX_TOML_NESTING_DEPTH/MAX_YAML_NESTING_DEPTH guards already applied to manifests of those formats. The depth is intentionally set narrower than serde_json‘s built-in 128 — real payloads (OSV database_specific/ecosystem_specific, npm’s time map, Packagist’s abandoned field, ordinary package.json/composer.json manifests and lockfiles) never approach double digits of nesting, so 64 is an arbitrary but generous ceiling chosen to match the existing TOML/YAML constants’ value, not a stack-size bisection.