CVE-2025-27407

What it actually does

This vulnerability allows remote code execution in graphql-ruby when an application loads a malicious GraphQL introspection schema from an untrusted JSON source using `GraphQL::Schema.from_introspection` or `GraphQL::Schema::Loader.load`. The flaw affects graphql-ruby versions starting at 1.11.5 and before the patched releases 1.11.8, 1.12.25, 1.13.24, 2.0.32, 2.1.14, 2.2.17, and 2.3.21. Successful exploitation executes attacker-controlled code in the context of the Ruby application process, potentially allowing full compromise of application confidentiality, integrity, and availability. The CVSS score is high at 9.0, but exploitation requires the application to load attacker-controlled schema JSON, which makes exposure dependent on application design.

Why it matters to the business

An exploited application can be taken over by an attacker, leading to theft of application data, modification of business logic, service disruption, credential exposure, and possible movement into connected systems. The issue is not currently listed in CISA KEV, is not marked as ransomware-used, and has no known mature public exploit in the provided data, but it has been public for over a year and should be prioritized anywhere schema loading from external or user-controlled sources is supported.

How an attack unfolds

An attacker first identifies an application, integration service, developer portal, CI workflow, or background job that imports GraphQL schemas from JSON or from a remote GraphQL introspection endpoint. The attacker then supplies or influences the schema source, such as by providing a URL, uploading schema JSON, compromising a schema registry, or controlling an upstream GraphQL endpoint used by `GraphQL::Client`. When the vulnerable graphql-ruby version parses the malicious introspection result through `GraphQL::Schema.from_introspection` or `GraphQL::Schema::Loader.load`, attacker-controlled content triggers code execution inside the Ruby runtime. The attacker can then run commands with the privileges of the application process, read secrets available to the app, modify files, establish persistence, or pivot through credentials and network access available from that process.

How to fix it

Upgrade graphql-ruby to a patched version matching the deployed release line: 1.11.8 or later in the 1.11 line, 1.12.25 or later, 1.13.24 or later, 2.0.32 or later, 2.1.14 or later, 2.2.17 or later, or 2.3.21 or later. Rebuild and redeploy all Ruby applications, background workers, CI jobs, and developer tooling that bundle the vulnerable gem. If immediate upgrade is not possible, disable loading schemas from untrusted JSON or remote introspection endpoints, allowlist approved schema sources, require signed or pinned schema artifacts, block user-controlled schema URLs, and restrict outbound network access from processes that perform schema loading. The supplied affected-product list references Ubuntu kernel packages and does not align with the graphql-ruby application flaw; if those package records are used for infrastructure tracking, validate against the relevant vendor advisory and update to the listed fixed package versions where applicable, but remediate this exposure by updating the graphql-ruby gem itself.

How to confirm the fix worked

Confirm the deployed graphql-ruby version at runtime or from dependency manifests. Use `bundle info graphql`, inspect `Gemfile.lock` for the `graphql` gem version, or run a controlled application console check such as `ruby -rgraphql -e 'puts GraphQL::VERSION'`. Verify that all deployed images, serverless packages, background worker builds, and CI containers contain a patched version. Search code for `GraphQL::Schema.from_introspection`, `GraphQL::Schema::Loader.load`, and `GraphQL::Client.load_schema` to identify risky schema-loading paths. Confirm those paths only use trusted, pinned, or signed schema inputs. Review outbound network policies to ensure schema-loading components cannot fetch arbitrary external URLs. After patching, run regression tests for schema loading and confirm no vulnerable gem versions remain in SBOM, dependency scanner, or container image results.

Typical attack path

1. Find a Ruby application or automation workflow that uses graphql-ruby and imports external GraphQL schema JSON or remote introspection results.
2. Confirm the application uses a vulnerable graphql-ruby version from 1.11.5 up to but not including the applicable fixed release.
3. Gain control over the schema source, such as an uploaded schema file, a schema URL parameter, an external introspection endpoint, or a compromised schema registry.
4. Deliver a malicious introspection schema that is loaded through `GraphQL::Schema.from_introspection` or `GraphQL::Schema::Loader.load`.
5. Trigger schema loading through the application, background worker, CI job, or GraphQL client initialization path.
6. Achieve code execution in the Ruby application process.
7. Use the compromised process to access secrets, databases, internal services, source code, or deployment credentials.

How to detect it

To determine whether this was already exploited, review application logs, background job logs, CI/CD logs, web access logs, API gateway logs, outbound proxy logs, DNS logs, EDR telemetry, and container runtime events around any schema import activity. Focus on events where schema JSON was uploaded, a schema URL was submitted, or a remote GraphQL introspection endpoint was contacted, especially if followed by Ruby process crashes, unusual exceptions, child-process creation, shell execution, outbound connections, file writes, credential access, or unexpected package downloads. Hunt for Ruby application processes spawning shells or network utilities such as `sh`, `bash`, `curl`, `wget`, `nc`, or `python`. Search source and runtime logs for use of `GraphQL::Schema.from_introspection`, `GraphQL::Schema::Loader.load`, and `GraphQL::Client.load_schema`; these are exposure indicators rather than proof of compromise. If suspicious activity is found, preserve the malicious schema artifact, application container or host image, process execution telemetry, environment variables, temporary files, and outbound network logs, then rotate credentials available to the affected process.

• GraphQL::Schema.from_introspection
• GraphQL::Schema::Loader.load
• GraphQL::Client.load_schema
• IntrospectionQuery
• __schema
• __type
• /bin/sh -c
• bash -c
• curl http
• wget http
• nc -e
• ruby -e
• Gemfile.lock: graphql (1.11.5)
• Gemfile.lock: graphql (1.11.6)
• Gemfile.lock: graphql (1.11.7)

What your security team should do

• Prioritize inventory of Ruby applications and automation that use the `graphql` gem and perform schema loading from JSON, URLs, schema registries, or remote introspection endpoints.
• Patch graphql-ruby to 1.11.8, 1.12.25, 1.13.24, 2.0.32, 2.1.14, 2.2.17, 2.3.21, or a later release appropriate for the active branch.
• Treat any externally supplied schema-loading feature as high risk until patched and validated.
• Temporarily disable user-controlled schema imports and remote introspection fetching where business operations allow.
• Add code-review and SAST checks for `GraphQL::Schema.from_introspection`, `GraphQL::Schema::Loader.load`, and `GraphQL::Client.load_schema`.
• Review application, proxy, EDR, and job logs for historical schema imports followed by Ruby child-process execution, outbound command-and-control-like traffic, or access to secrets.
• Rotate credentials exposed to any application where suspicious schema loading or process execution is identified.
• Do not rely on KEV status alone; the vulnerability has high technical impact despite no current KEV listing or known ransomware association in the provided data.