AI Threat AlertCVE-2026-120194: json-glib: infinite loop in JSONPath slice causes DoS
HIGHA flaw in the json-glib library lets a JSONPath slice expression with a negative step send json_path_query() into an infinite loop, so any application that evaluates attacker-controlled JSONPath expressions can be hung remotely without authentication (CVSS 7.5, availability impact only). The library is a general-purpose GNOME dependency, but it ships inside 30+ Red Hat OpenShift AI (RHOAI) component images, including the dashboard, KServe controllers, MLflow, model registry, KubeRay and training operators, and the OpenShift CoreOS base images. That makes the potential blast radius broad: 695 downstream dependents and a package risk score of 81/100, with an OpenSSF Scorecard of 5.4/10. There is no EPSS score, no public exploit, no Nuclei template, no KEV listing and no SSVC decision, so there is no evidence of active exploitation and the trigger is trivial to build once the bug is understood. Exposure depends on whether a component actually passes untrusted input to json_path_query(), which is not confirmed for the RHOAI images. Track the Red Hat advisory for fixed image versions, patch affected RHOAI and CoreOS images when released, and until then prevent untrusted users from supplying JSONPath expressions and make sure liveness probes restart hung pods.
What is the risk?
Medium-to-high. The attack is network-reachable, needs low complexity, no privileges and no user interaction, but it only affects availability (A:H). No exploit, EPSS score or KEV listing exists, so near-term exploitation likelihood looks low. Real risk depends on whether a service exposes JSONPath evaluation to untrusted input. Services where that is not the case are practically unaffected, while those that do are trivially hangable by a single request.
How does the attack unfold?
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
1 step1) Monitor the Red Hat CVE page and Bugzilla 2564418 and apply the fixed RHOAI and OpenShift CoreOS images or json-glib package as soon as they are available; the upstream fix is tracked in GNOME json-glib issue 96. 2) Identify which workloads actually call json_path_query() with externally supplied expressions (SBOM scan for json-glib, code review of the call sites). 3) Where possible, reject or validate JSONPath expressions, in particular slices with negative steps, and do not accept user-defined paths from untrusted clients. 4) Configure liveness and readiness probes, CPU limits and request timeouts so hung pods are detected and restarted. 5) Alert on sustained 100% CPU on affected pods and on unresponsive endpoints.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-120194?
A flaw in the json-glib library lets a JSONPath slice expression with a negative step send json_path_query() into an infinite loop, so any application that evaluates attacker-controlled JSONPath expressions can be hung remotely without authentication (CVSS 7.5, availability impact only). The library is a general-purpose GNOME dependency, but it ships inside 30+ Red Hat OpenShift AI (RHOAI) component images, including the dashboard, KServe controllers, MLflow, model registry, KubeRay and training operators, and the OpenShift CoreOS base images. That makes the potential blast radius broad: 695 downstream dependents and a package risk score of 81/100, with an OpenSSF Scorecard of 5.4/10. There is no EPSS score, no public exploit, no Nuclei template, no KEV listing and no SSVC decision, so there is no evidence of active exploitation and the trigger is trivial to build once the bug is understood. Exposure depends on whether a component actually passes untrusted input to json_path_query(), which is not confirmed for the RHOAI images. Track the Red Hat advisory for fixed image versions, patch affected RHOAI and CoreOS images when released, and until then prevent untrusted users from supplying JSONPath expressions and make sure liveness probes restart hung pods.
Is CVE-2026-120194 actively exploited?
No confirmed active exploitation of CVE-2026-120194 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-120194?
1) Monitor the Red Hat CVE page and Bugzilla 2564418 and apply the fixed RHOAI and OpenShift CoreOS images or json-glib package as soon as they are available; the upstream fix is tracked in GNOME json-glib issue 96. 2) Identify which workloads actually call json_path_query() with externally supplied expressions (SBOM scan for json-glib, code review of the call sites). 3) Where possible, reject or validate JSONPath expressions, in particular slices with negative steps, and do not accept user-defined paths from untrusted clients. 4) Configure liveness and readiness probes, CPU limits and request timeouts so hung pods are detected and restarted. 5) Alert on sustained 100% CPU on affected pods and on unresponsive endpoints.
What systems are affected by CVE-2026-120194?
This vulnerability affects the following AI/ML architecture patterns: model serving, MLOps platforms, Kubernetes operators for ML, experiment tracking, model registry, notebook and workbench environments, training pipelines.
What is the CVSS score for CVE-2026-120194?
CVE-2026-120194 has a CVSS v3.1 base score of 7.5 (HIGH).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
A flaw was found in json-glib. The JSONPath slice evaluator used by json_path_query() can enter an infinite loop when given a slice expression with a negative step. An application that evaluates attacker-controlled JSONPath expressions can be forced into a hang, leading to a denial of service.
Exploitation Scenario
An attacker finds an endpoint in an ML platform component that accepts a user-supplied JSONPath filter, for example to query model registry metadata or experiment results. They send a request containing a slice expression with a negative step such as $[::-1] variant that triggers the non-terminating loop. The worker thread spins forever at full CPU. Repeating the request across threads exhausts the service's worker pool, making the model registry or serving control plane unresponsive until the pods are restarted.
Weaknesses (CWE)
CWE-835 — Loop with Unreachable Exit Condition: The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- access.redhat.com/security/cve/CVE-2026-120194vdb-entryx_refsource_REDHAT
- bugzilla.redhat.com/show_bug.cgiissue-trackingx_refsource_REDHAT
- gitlab.gnome.org/GNOME/json-glib/-/issues/96
Timeline
Related Vulnerabilities
CVE-2025-1537910.0MLflow: RCE via unsanitized model dependency specs
Same package: mlflowCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same package: mlflowCVE-2023-11779.8MLflow: path traversal allows arbitrary file read/write
Same package: mlflowCVE-2026-26359.8mlflow: security flaw enables exploitation
Same package: mlflowCVE-2023-27809.8MLflow: path traversal allows arbitrary file read/write
Same package: mlflow