GHSA-H9MW-H4QC-F5JF

Vulnerability from github – Published: 2026-04-08 15:05 – Updated: 2026-04-08 15:05
VLAI
Summary
kubernetes-graphql-gateway: GraphQL Endpoint Vulnerable to Authenticated Denial-of-Service via Unrestricted Query Execution
Details

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)
}

Impact

  • 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.

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

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

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.8"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/platform-mesh/kubernetes-graphql-gateway"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:05:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "**CVSS 6.5 Medium** \u2014 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.\n\n\u003e **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 \u2014 all requests now require a Bearer token. The CVSS score has been adjusted from 7.5 to 6.5 accordingly (Privileges Required: None \u2192 Low). CWE-306 (Missing Authentication for Critical Function) no longer applies.\n\n## Root Cause\n\nThe 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 \u2014 no resource limits:\n\n```go\n// gateway/gateway/graphql/graphql.go \u2014 CreateHandler()\nfunc (s *GraphQLServer) CreateHandler(schema *graphql.Schema) *GraphQLHandler {\n    graphqlHandler := handler.New(\u0026handler.Config{\n        Schema:     schema,\n        Pretty:     s.config.Pretty,\n        Playground: s.config.Playground,\n        GraphiQL:   s.config.GraphiQL,\n    })\n    return \u0026GraphQLHandler{\n        Schema:  schema,\n        Handler: graphqlHandler,\n    }\n}\n```\n\nThe `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.\n\nThe application configuration (`gateway/gateway/config/config.go`) has no fields for resource limits:\n\n```go\n// gateway/gateway/config/config.go \u2014 GraphQL config\ntype GraphQL struct {\n    Pretty     bool\n    Playground bool\n    GraphiQL   bool\n}\n```\n\nNo rate limiting, throttling, or request size controls exist anywhere in the codebase.\n\n## Authentication Model\n\nAll requests pass through the HTTP handler in `gateway/http/http.go`, which extracts a Bearer token and injects it into the request context:\n\n```go\n// gateway/http/http.go \u2014 Token extraction (applied to all methods)\ns.Handle(\"/api/clusters/{clusterName}\", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n    clusterName := r.PathValue(\"clusterName\")\n    authHeader := r.Header.Get(\"Authorization\")\n    token := strings.TrimPrefix(authHeader, \"Bearer \")\n    ctx := utilscontext.SetToken(r.Context(), token)\n    ctx = utilscontext.SetCluster(ctx, clusterName)\n    c.Gateway.ServeHTTP(w, r.WithContext(ctx))\n}))\n```\n\nThe 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 \u2014 meaning authenticated users can trigger expensive operations that consume server resources without hitting the K8s API at all.\n\n## Attack Vectors\n\n### 1. Nested Introspection Field Expansion\n\nThe 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.\n\n### 2. Parallel Request Amplification\n\nWithout 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.\n\n### 3. Subscription Resource Exhaustion\n\nThe `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:\n\n```go\n// gateway/gateway/graphql/graphql.go \u2014 HandleSubscription()\nsubscriptionChannel := graphql.Subscribe(subscriptionParams)\nfor res := range subscriptionChannel {\n    // ... marshal and flush indefinitely ...\n}\n```\n\nThere is no limit on the number of concurrent subscriptions, no idle timeout, and no per-client connection cap.\n\n### 4. Deep Query Execution\n\nAuthenticated users can submit arbitrarily deep and complex GraphQL queries. The GraphQL execution engine processes the full query \u2014 consuming CPU and memory for schema validation, field resolution, and error/response formatting \u2014 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:\n\n```go\n// gateway/gateway/endpoint/endpoint.go \u2014 ServeHTTP()\nfunc (e *Endpoint) ServeHTTP(w http.ResponseWriter, r *http.Request) {\n    if e.handler == nil || e.handler.Handler == nil {\n        http.Error(w, \"Endpoint not ready\", http.StatusServiceUnavailable)\n        return\n    }\n    if r.Header.Get(\"Accept\") == \"text/event-stream\" {\n        e.graphqlServer.HandleSubscription(w, r, e.handler.Schema)\n        return\n    }\n    e.handler.Handler.ServeHTTP(w, r)\n}\n```\n\n## Impact\n\n- **Availability (High):** Service denial achievable \u2014 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.\n- **Confidentiality (None):** Information disclosure is covered in a separate finding.\n- **Integrity (None):** No data modification possible.\n\n## Affected Components\n\n- `gateway/gateway/graphql/graphql.go` \u2014 Handler creation with no resource limits; subscription handler with no connection limits\n- `gateway/gateway/endpoint/endpoint.go` \u2014 Direct passthrough to handler, no query depth/complexity middleware\n- `gateway/gateway/config/config.go` \u2014 No configuration fields for resource limits\n- `gateway/http/http.go` \u2014 No rate limiting middleware\n- `graphql-go/graphql` library \u2014 No built-in depth/complexity limiting\n- `graphql-go/handler` \u2014 No resource limit configuration options\n\n## Recommendations\n\n1. **Disable Introspection in Production** \u2014 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.\n2. **Implement Query Depth and Complexity Limiting** \u2014 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 \u2014 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).\n3. **Implement Rate Limiting and Response Size Controls** \u2014 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.\n4. **Add Resource Limit Configuration** \u2014 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.\n\n## References\n\n- [OWASP GraphQL Cheat Sheet \u2014 Resource Limits](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)\n- [OWASP API4:2023 \u2014 Unrestricted Resource Consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/)\n- [CWE-770: Allocation of Resources Without Limits or Throttling](https://cwe.mitre.org/data/definitions/770.html)\n- [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)\n\n## Classification\n\n- **CWE-770** \u2014 Allocation of Resources Without Limits or Throttling\n- **CWE-400** \u2014 Uncontrolled Resource Consumption\n- **OWASP Top 10 2021:** A05:2021 \u2014 Security Misconfiguration\n- **OWASP API Security Top 10:** API4:2023 \u2014 Unrestricted Resource Consumption\n- **STRIDE:** Denial of Service (D)\n\n## Internal Reference\n\nHASI2026141-32 \u2014 Due: 2026-04-16",
  "id": "GHSA-h9mw-h4qc-f5jf",
  "modified": "2026-04-08T15:05:10Z",
  "published": "2026-04-08T15:05:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/platform-mesh/kubernetes-graphql-gateway/security/advisories/GHSA-h9mw-h4qc-f5jf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/platform-mesh/kubernetes-graphql-gateway/commit/61509656fbab2dbf158f634d6700478ee94221ab"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/platform-mesh/kubernetes-graphql-gateway"
    },
    {
      "type": "WEB",
      "url": "https://github.com/platform-mesh/kubernetes-graphql-gateway/releases/tag/v1.2.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kubernetes-graphql-gateway: GraphQL Endpoint Vulnerable to Authenticated Denial-of-Service via Unrestricted Query Execution"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…