CVE-2022-32511

What it actually does

jmespath.rb before 1.6.1 uses Ruby JSON.load in a code path where JSON.parse should be used. JSON.load can enable Ruby JSON additions and object materialization behavior that is unsafe for untrusted input. If an application passes attacker-controlled JSON into the vulnerable JMESPath parsing/search flow, a crafted JSON document may trigger unsafe deserialization behavior, potentially leading to arbitrary object creation, code execution through available gadget classes, data tampering, or denial of service. The CVSS 9.8 rating reflects the worst-case condition: network-reachable, unauthenticated attacker-controlled input reaching the vulnerable parser without user interaction.

Why it matters to the business

Applications that depend on vulnerable jmespath.rb versions may be exposed to compromise if they process untrusted JSON, especially APIs, webhook handlers, automation services, cloud SDK integrations, and backend data-processing jobs. Successful exploitation could allow an attacker to take over the affected application process, access sensitive data available to that process, modify application behavior, or disrupt service. The issue is not listed in CISA KEV and has low EPSS at the time of assessment, so broad active exploitation is not indicated, but the high technical severity means internet-facing or multi-tenant JSON-processing services should prioritize remediation.

How an attack unfolds

An attacker first identifies an application endpoint, integration, or background workflow that accepts JSON and uses jmespath.rb to query or transform that data. The attacker then submits a crafted JSON payload designed to exercise Ruby JSON.load behavior rather than safe parsing. If the vulnerable library version is present and the application passes the attacker-controlled payload into the affected code path, JSON.load may process metadata that causes Ruby object materialization or other unsafe deserialization side effects. The practical result depends on the classes and gems loaded in the application: in a worst case, available gadget chains can lead to command execution in the application process; in other cases, exploitation may cause application errors, memory/CPU exhaustion, or unexpected data manipulation. There are no named threat actors or public KEV-driven campaigns associated with this CVE in the provided data.

How to fix it

Upgrade jmespath.rb to version 1.6.1 or later. For source-based consumers, ensure the code includes fixed commit 6e429f62298ba61e05538a4ff623c7fcccfdc51b or a later commit containing the same change. Regenerate lockfiles and redeploy all affected services, workers, containers, and serverless artifacts that bundle the vulnerable gem. If immediate upgrade is not possible, reduce exposure by preventing untrusted JSON from reaching JMESPath processing, validating JSON strictly before use, rejecting JSON containing deserialization metadata such as json_class where feasible, and isolating the vulnerable processing path with least-privilege runtime permissions. Do not rely solely on input filtering as a permanent fix; replace JSON.load usage with safe parsing through the fixed library.

How to confirm the fix worked

Confirm dependency resolution shows jmespath.rb 1.6.1 or later in Gemfile.lock, gemspec.lock, container SBOMs, vendored gems, and deployed runtime images. For Git-based dependencies, verify the resolved revision is 6e429f62298ba61e05538a4ff623c7fcccfdc51b or later. Run software composition analysis against application repositories and built artifacts, not only source manifests. Where feasible, add a regression test that sends JSON containing Ruby JSON addition markers such as json_class through any JMESPath-processing path and verifies it is treated as plain JSON data or rejected, not deserialized into application objects. Validate that production deployments were restarted or rebuilt after the dependency update.

Typical attack path

1. Find a service or workflow that accepts JSON from an untrusted source, such as an API request, webhook, message queue, or uploaded document.
2. Determine or infer that the application uses a vulnerable jmespath.rb version before 1.6.1 to evaluate JMESPath expressions or process JSON.
3. Send a crafted JSON payload containing deserialization-oriented structures intended to trigger unsafe JSON.load behavior.
4. Cause the vulnerable Ruby process to deserialize or materialize attacker-influenced objects instead of safely parsing primitive JSON data.
5. Leverage available application classes or loaded gems for code execution, state manipulation, sensitive-data access, or denial of service.
6. Use the compromised application context to access downstream credentials, internal services, files, logs, or application data available to the process.

How to detect it

Retrospective detection should focus on applications that accepted untrusted JSON while running jmespath.rb before 1.6.1. Review web, API gateway, load balancer, WAF, application, and worker logs for requests or messages containing Ruby JSON addition markers such as json_class, especially near errors from JSON parsing, JMESPath evaluation, object allocation, or unexpected exceptions. Examine application telemetry for Ruby processes spawning shells or system utilities, making unusual outbound network connections, writing unexpected files, or accessing secrets shortly after suspicious JSON input. In containerized environments, review runtime security events for ruby processes executing child processes such as sh, bash, curl, wget, nc, python, or perl. Because exploitation artifacts are highly application- and gadget-dependent and no universal exploit campaign indicators are provided, absence of these indicators does not prove non-exploitation.

• "json_class"
• "create_additions"
• "JSON.load"
• "JMESPath"
• "jmespath"
• "unexpected token at"
• "JSON::ParserError"
• "NoMethodError"
• "TypeError"
• "ruby" spawning "sh"
• "ruby" spawning "bash"
• "ruby" spawning "curl"
• "ruby" spawning "wget"
• "ruby" spawning "nc"

What your security team should do

• Inventory all Ruby applications, containers, serverless packages, and background workers that include jmespath.rb, including transitive dependencies from cloud SDKs or automation tooling.
• Prioritize remediation for internet-facing APIs, webhook receivers, ingestion pipelines, and services that process customer- or partner-supplied JSON.
• Upgrade to jmespath.rb 1.6.1 or later, or verify inclusion of fixed commit 6e429f62298ba61e05538a4ff623c7fcccfdc51b for Git-sourced builds.
• Search repositories and deployed artifacts for direct JSON.load usage in application code and other dependencies, because the same unsafe pattern can create similar deserialization risk outside this package.
• Add WAF, API gateway, or application logging detections for suspicious JSON deserialization markers such as json_class in requests to JSON-processing endpoints.
• Review recent logs for malformed JSON errors, unexpected exceptions during JMESPath processing, suspicious child processes spawned by Ruby services, and outbound connections from Ruby application processes.
• Ensure Ruby application processes run with least privilege and do not have unnecessary shell, filesystem, cloud credential, or metadata-service access.
• Track this vulnerability through vulnerability management despite low EPSS and no KEV listing because the worst-case impact is full application compromise.