GHSA-H9MW-H4QC-F5JF

CVSS 6.5 Medium, The GraphQL API served by kubernetes-graphql-gateway is vulnerable to Denial-of-Service (DoS) attacks due to a complete absence of query resource controls (depth limiting, complexity analysis, response size capping, and rate limiting). An authenticated attacker can craft queries that force the server to compute and serialize multi-megabyte responses, consuming significant CPU, memory, and network bandwidth. Repeated requests can exhaust server resources and degrade or deny service to legitimate users.

Note: A previous version of this advisory (based on pre-v1 code) documented an unauthenticated attack surface via an HTTP GET method bypass in the former registry.go. That bypass has been removed in v1, all requests now require a Bearer token. The CVSS score has been adjusted from 7.5 to 6.5 accordingly (Privileges Required: None → Low). CWE-306 (Missing Authentication for Critical Function) no longer applies.

Root Cause

The kubernetes-graphql-gateway uses the graphql-go/graphql library (v0.8.1) with the graphql-go/handler HTTP handler. The handler is instantiated in gateway/gateway/graphql/graphql.go with only cosmetic configuration, no resource limits:

// gateway/gateway/graphql/graphql.go, CreateHandler()
func (s *GraphQLServer) CreateHandler(schema *graphql.Schema) *GraphQLHandler {
    graphqlHandler := handler.New(&handler.Config{
        Schema:     schema,
        Pretty:     s.config.Pretty,
        Playground: s.config.Playground,
        GraphiQL:   s.config.GraphiQL,
    })
    return &GraphQLHandler{
        Schema:  schema,
        Handler: graphqlHandler,
    }
}

The handler.Config struct does not include MaxDepth, MaxComplexity, MaxResponseSize, or any equivalent fields. Neither the graphql-go/handler nor the underlying graphql-go/graphql library provides built-in query depth or complexity analysis.

The application configuration (gateway/gateway/config/config.go) has no fields for resource limits:

// gateway/gateway/config/config.go, GraphQL config
type GraphQL struct {
    Pretty     bool
    Playground bool
    GraphiQL   bool
}

No rate limiting, throttling, or request size controls exist anywhere in the codebase.

Authentication Model

All requests pass through the HTTP handler in gateway/http/http.go, which extracts a Bearer token and injects it into the request context:

// gateway/http/http.go, Token extraction (applied to all methods)
s.Handle("/api/clusters/{clusterName}", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    clusterName := r.PathValue("clusterName")
    authHeader := r.Header.Get("Authorization")
    token := strings.TrimPrefix(authHeader, "Bearer ")
    ctx := utilscontext.SetToken(r.Context(), token)
    ctx = utilscontext.SetCluster(ctx, clusterName)
    c.Gateway.ServeHTTP(w, r.WithContext(ctx))
}))

The token is enforced at the Kubernetes API layer via gateway/gateway/roundtripper/bearer.go, which returns HTTP 401 for requests without a valid token. However, the GraphQL execution engine (query parsing, schema validation, introspection) still runs before the Kubernetes API is contacted, meaning authenticated users can trigger expensive operations that consume server resources without hitting the K8s API at all.

Attack Vectors

1. Nested Introspection Field Expansion

The GraphQL schema contains 3,508 types (Kubernetes resources + platform CRDs). Introspection meta-fields (__schema, __type) allow recursive field expansion. Each additional nesting level multiplies the response size exponentially. A single full introspection query generates ~5.2 MB of response data in ~1.15s.

2. Parallel Request Amplification

Without rate limiting, an authenticated attacker can issue many concurrent expensive queries. 5 parallel requests generate ~18.6 MB total response in under 4 seconds with no throttling. At scale (e.g. 999 concurrent requests), the backend becomes unresponsive and returns 503 to all users.

3. Subscription Resource Exhaustion

The HandleSubscription() method in gateway/gateway/graphql/graphql.go processes SSE (Server-Sent Events) subscription requests. A malicious authenticated client can open many subscription channels simultaneously, holding server connections and memory indefinitely:

// gateway/gateway/graphql/graphql.go, HandleSubscription()
subscriptionChannel := graphql.Subscribe(subscriptionParams)
for res := range subscriptionChannel {
    // ... marshal and flush indefinitely ...
}

There is no limit on the number of concurrent subscriptions, no idle timeout, and no per-client connection cap.

4. Deep Query Execution

Authenticated users can submit arbitrarily deep and complex GraphQL queries. The GraphQL execution engine processes the full query, consuming CPU and memory for schema validation, field resolution, and error/response formatting, before any Kubernetes API authorization is checked. The request handling in gateway/gateway/endpoint/endpoint.go passes directly to the handler with no query guards:

// gateway/gateway/endpoint/endpoint.go, ServeHTTP()
func (e *Endpoint) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if e.handler == nil || e.handler.Handler == nil {
        http.Error(w, "Endpoint not ready", http.StatusServiceUnavailable)
        return
    }
    if r.Header.Get("Accept") == "text/event-stream" {
        e.graphqlServer.HandleSubscription(w, r, e.handler.Schema)
        return
    }
    e.handler.Handler.ServeHTTP(w, r)
}

Affected Components

• gateway/gateway/graphql/graphql.go, Handler creation with no resource limits; subscription handler with no connection limits
• gateway/gateway/endpoint/endpoint.go, Direct passthrough to handler, no query depth/complexity middleware
• gateway/gateway/config/config.go, No configuration fields for resource limits
• gateway/http/http.go, No rate limiting middleware
• graphql-go/graphql library, No built-in depth/complexity limiting
• graphql-go/handler, No resource limit configuration options

Recommendations

1. Disable Introspection in Production, As a defense-in-depth measure, disable introspection in non-development environments. This removes the highest-cost query path. If GraphiQL/Playground must remain accessible for development, gate it behind an environment flag.
2. Implement Query Depth and Complexity Limiting, Implement middleware that parses the query AST and rejects queries exceeding configurable thresholds before execution. Recommended maximum depth: 10 levels. Assign cost values to fields and enforce a maximum query cost budget, introspection meta-fields (__schema, __type) should carry elevated costs. Alternatively, consider migrating to a GraphQL library with built-in depth/complexity support (e.g., gqlgen with its complexity extension, or graph-gophers/graphql-go with its MaxDepth option).
3. Implement Rate Limiting and Response Size Controls, Add per-user rate limiting on the GraphQL endpoint. Suggested thresholds: 60 requests/minute for authenticated users, 2 requests/minute for introspection queries. Cap response payload size (e.g., 5 MB). For subscriptions, enforce maximum concurrent connections per client, idle timeouts, and maximum subscription duration.
4. Add Resource Limit Configuration, Extend the GraphQL struct in gateway/gateway/config/config.go to expose all resource limits (max query depth, max complexity, max response size, rate limit thresholds) as configurable parameters. This ensures all protective thresholds can be tuned per environment without code changes.

References

• OWASP GraphQL Cheat Sheet, Resource Limits
• OWASP API4:2023, Unrestricted Resource Consumption
• CWE-770: Allocation of Resources Without Limits or Throttling
• CWE-400: Uncontrolled Resource Consumption

Classification

• CWE-770, Allocation of Resources Without Limits or Throttling
• CWE-400, Uncontrolled Resource Consumption
• OWASP Top 10 2021: A05:2021, Security Misconfiguration
• OWASP API Security Top 10: API4:2023, Unrestricted Resource Consumption
• STRIDE: Denial of Service (D)

Internal Reference

HASI2026141-32, Due: 2026-04-16

• Availability (High): Service denial achievable, concurrent expensive queries cause backend to become unresponsive (503 for all users). With 3,508 types and no depth limits, each introspection query generates a ~5.2 MB response. The absence of rate limiting, query complexity controls, and response size caps allows an authenticated attacker to exhaust server CPU, memory, and bandwidth.
• Confidentiality (None): Information disclosure is covered in a separate finding.
• Integrity (None): No data modification possible.

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

GHSA-H9MW-H4QC-F5JF has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.2.9); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is GHSA-H9MW-H4QC-F5JF? GHSA-H9MW-H4QC-F5JF is a medium-severity uncontrolled resource consumption vulnerability in github.com/platform-mesh/kubernetes-graphql-gateway (go), affecting versions <= 1.2.8. It is fixed in 1.2.9. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
2. How severe is GHSA-H9MW-H4QC-F5JF? GHSA-H9MW-H4QC-F5JF has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/platform-mesh/kubernetes-graphql-gateway are affected by GHSA-H9MW-H4QC-F5JF? github.com/platform-mesh/kubernetes-graphql-gateway (go) versions <= 1.2.8 is affected.
4. Is there a fix for GHSA-H9MW-H4QC-F5JF? Yes. GHSA-H9MW-H4QC-F5JF is fixed in 1.2.9. Upgrade to this version or later.
5. Is GHSA-H9MW-H4QC-F5JF exploitable, and should I be worried? Whether GHSA-H9MW-H4QC-F5JF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-H9MW-H4QC-F5JF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-H9MW-H4QC-F5JF? Upgrade github.com/platform-mesh/kubernetes-graphql-gateway to 1.2.9 or later.