GHSA-xf7x-x43h-rpqh: Denial of Service via Unconstrained Circular Reference Resolution in json-repair

The json-repair Python package is a utility designed to parse and repair malformed JSON structures, which is frequently integrated into workflows that process outputs from Large Language Models (LLMs). The library includes a schema-aware parser designed to correct structural JSON issues based on a provided JSON Schema definition. The vulnerability exists within the schema reference ($ref) resolution mechanism of this component.

An attacker can trigger a Denial of Service (DoS) condition by providing a maliciously crafted, circular JSON Schema containing self-referencing pointers. When the parser attempts to resolve these cyclic references, it enters an infinite loop, consuming a single CPU core entirely. This technical analysis explores the mechanics of this flaw, its exploitability, and the official mitigation strategies.

Because json-repair is commonly deployed to sanitize untrusted output in automated parsing pipelines, exposing the loads() interface to user-controlled schemas provides an immediate attack path. Remote, unauthenticated attackers can leverage this behavior to systematically exhaust host processor resources with minimal network overhead.

The flaw is located in the $ref resolution engine of the schema-aware JSON repair utility, implemented in src/json_repair/schema_repair.py within the SchemaRepairer class. When a JSON Schema containing a $ref key is processed, the SchemaRepairer.resolve_schema() method initiates a while loop designed to sequentially resolve pointers until no more references exist.

The logic evaluates the statement while "$ref" in schema_dict and delegates resolution to the helper function _resolve_ref(). This helper function parses the pointer and returns the corresponding sub-schema relative to the root_schema object, which represents the initial user-provided schema. If the schema contains self-referential definitions (such as node a pointing to node a or a circular chain a -> b -> a), the returned resolved structure continually contains the same $ref key.

Because the resolution engine lacked cycle tracking or recursion depth limits, the loop condition remains satisfied indefinitely. This design flaw allows an unauthenticated actor to force the thread of execution into an infinite loop, resulting in 100 percent CPU utilization on the executing core.

The vulnerable implementation of the reference resolver in src/json_repair/schema_repair.py demonstrates the lack of traversal state preservation. In the unpatched codebase, the loop simply assigns the output of _resolve_ref back to schema_dict without any historical tracking:

# Vulnerable implementation in src/json_repair/schema_repair.py
schema_dict = cast("dict[str, Any]", schema)
while "$ref" in schema_dict:
    ref = schema_dict["$ref"]
    resolved = self._resolve_ref(ref)
    if isinstance(resolved, bool):
        return resolved
    schema_dict = resolved

The patched version introduces cycle tracking using unique Python object identifiers. By tracking the id() of each traversed schema dictionary, the engine detects when a node is revisited within the current path:

# Patched implementation in src/json_repair/schema_repair.py
schema_dict = cast("dict[str, Any]", schema)
seen_schema_ids: set[int] = set()
while "$ref" in schema_dict:
    ref = schema_dict["$ref"]
    if not isinstance(ref, str):
        raise SchemaDefinitionError("$ref must be a string.")
    schema_id = id(schema_dict)
    if schema_id in seen_schema_ids:
        raise SchemaDefinitionError(f"Circular $ref detected: {ref}")
    seen_schema_ids.add(schema_id)
    resolved = self._resolve_ref(ref)
    if isinstance(resolved, bool):
        return resolved
    schema_dict = resolved
return schema_dict

This remediation is robust because the components of the root schema remain in scope during the lifetime of the SchemaRepairer instance, which guarantees that Python's id() values are stable and not reused during the resolution process. Additionally, enforcing type checking on the $ref key prevents unexpected schema parsing exceptions.

Exploitation of this vulnerability requires that the target application accepts user-supplied JSON schemas and applies them to the loads() interface of the json-repair library. This is a common pattern in platforms that allow users to define structured output validation for LLM responses.

An attacker can trigger this behavior by constructing a minimal JSON payload accompanied by a schema dictionary containing circular references. The most direct vector involves pointing a $ref key to a definition path that resolves back to itself. The following JSON payload represents a reliable proof of concept:

{
  "malformedJSON": "{}",
  "schema": {
    "$ref": "#/definitions/a",
    "definitions": {
      "a": {
        "$ref": "#/definitions/a"
      }
    }
  }
}

When processed by an application using the vulnerable library version, the thread handling the parsing operation will freeze indefinitely. If the application runs in a single-threaded server environment, such as a basic Flask application, the entire server process becomes unresponsive to subsequent incoming requests.

The impact of this vulnerability is a complete loss of availability for the affected application components. Because the execution logic is CPU-bound rather than I/O-bound, the thread cannot yield execution control, which leads to total exhaustion of the hosting CPU core.

In containerized or shared environments, a series of requests utilizing this exploit can exhaust all available processor cores, affecting adjacent services. This vulnerability carries a CVSS v3.1 score of 7.5 (High) with an attack vector of Network, low attack complexity, and no privileges or user interaction required.

While the vulnerability does not allow remote code execution or data exposure, it represents an effective and low-cost vector for denial of service (DoS) against LLM middleware applications that dynamically evaluate user schemas.

The primary remediation strategy is upgrading the json-repair package to version 0.60.1 or later, where the cycle-detection logic has been integrated. This upgrade completely mitigates the loop condition by raising a SchemaDefinitionError when circular structures are encountered.

If upgrading is not immediately feasible, developers must implement schema sanitization before passing objects to the repair utility. Applications should use stable third-party schema validators that support recursion limiters to validate the schema's structure prior to processing.

Additionally, hosting environments should enforce strict resource limits, such as maximum execution timeouts on web workers (e.g., Gunicorn or uWSGI timeout configurations). This ensures that any thread entering an infinite loop is automatically terminated before causing system-wide degradation.