CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5521 vulnerabilities reference this CWE, most recent first.
GHSA-H9C5-X7G8-4Q7F
Vulnerability from github – Published: 2026-07-03 21:31 – Updated: 2026-07-09 18:31Gitea versions before 1.25.5 do not enforce a timeout on git grep searches, allowing expensive searches to consume server resources.
{
"affected": [],
"aliases": [
"CVE-2026-26307"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-03T21:16:58Z",
"severity": "HIGH"
},
"details": "Gitea versions before 1.25.5 do not enforce a timeout on git grep searches, allowing expensive searches to consume server resources.",
"id": "GHSA-h9c5-x7g8-4q7f",
"modified": "2026-07-09T18:31:28Z",
"published": "2026-07-03T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26307"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/36809"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/36835"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.25.5"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.25.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H9H2-6W4Q-6C52
Vulnerability from github – Published: 2024-06-20 12:31 – Updated: 2024-07-03 18:46In the Linux kernel, the following vulnerability has been resolved:
net: bridge: vlan: fix memory leak in __allowed_ingress
When using per-vlan state, if vlan snooping and stats are disabled, untagged or priority-tagged ingress frame will go to check pvid state. If the port state is forwarding and the pvid state is not learning/forwarding, untagged or priority-tagged frame will be dropped but skb memory is not freed. Should free skb when __allowed_ingress returns false.
{
"affected": [],
"aliases": [
"CVE-2022-48748"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T12:15:13Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: vlan: fix memory leak in __allowed_ingress\n\nWhen using per-vlan state, if vlan snooping and stats are disabled,\nuntagged or priority-tagged ingress frame will go to check pvid state.\nIf the port state is forwarding and the pvid state is not\nlearning/forwarding, untagged or priority-tagged frame will be dropped\nbut skb memory is not freed.\nShould free skb when __allowed_ingress returns false.",
"id": "GHSA-h9h2-6w4q-6c52",
"modified": "2024-07-03T18:46:09Z",
"published": "2024-06-20T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48748"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14be8d448fca6fe7b2a413831eedd55aef6c6511"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/446ff1fc37c74093e81db40811a07b5a19f1d797"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5e216e880fa6f2cd9d4a6541269377657163098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd20d9738395cf8e27d0a17eba34169699fccdff"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H9MR-RH28-V9R2
Vulnerability from github – Published: 2026-06-30 12:31 – Updated: 2026-07-20 09:31Net::BitTorrent versions through 2.0.1 for Perl allow remote memory exhaustion via an uncapped peer-wire message-length prefix.
The peer-wire framing in _process_messages trusts the 4-byte length prefix sent by a connected peer with no upper bound, while receive_data appends every inbound byte to the input buffer. A peer announces a length prefix of up to about 4 GiB and then streams bytes; the decoder waits until the buffer holds the full message before processing it, so the buffer grows without limit.
Peer connections are unauthenticated, so any peer in the swarm exhausts the downloading process's memory. The largest legitimate message is a 16 KiB piece block, so any announced length far above that is anomalous.
{
"affected": [],
"aliases": [
"CVE-2026-57080"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T12:16:25Z",
"severity": "HIGH"
},
"details": "Net::BitTorrent versions through 2.0.1 for Perl allow remote memory exhaustion via an uncapped peer-wire message-length prefix.\n\nThe peer-wire framing in _process_messages trusts the 4-byte length prefix sent by a connected peer with no upper bound, while receive_data appends every inbound byte to the input buffer. A peer announces a length prefix of up to about 4 GiB and then streams bytes; the decoder waits until the buffer holds the full message before processing it, so the buffer grows without limit.\n\nPeer connections are unauthenticated, so any peer in the swarm exhausts the downloading process\u0027s memory. The largest legitimate message is a 16 KiB piece block, so any announced length far above that is anomalous.",
"id": "GHSA-h9mr-rh28-v9r2",
"modified": "2026-07-20T09:31:05Z",
"published": "2026-06-30T12:31:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sanko/Net-BitTorrent.pm/security/advisories/GHSA-7jr6-2jf4-6qc4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57080"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/SANKO/Net-BitTorrent-v2.1.0/changes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H9MW-H4QC-F5JF
Vulnerability from github – Published: 2026-04-08 15:05 – Updated: 2026-04-08 15:05CVSS 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 limitsgateway/gateway/endpoint/endpoint.go— Direct passthrough to handler, no query depth/complexity middlewaregateway/gateway/config/config.go— No configuration fields for resource limitsgateway/http/http.go— No rate limiting middlewaregraphql-go/graphqllibrary — No built-in depth/complexity limitinggraphql-go/handler— No resource limit configuration options
Recommendations
- 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.
- 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.,gqlgenwith its complexity extension, orgraph-gophers/graphql-gowith itsMaxDepthoption). - 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.
- Add Resource Limit Configuration — Extend the
GraphQLstruct ingateway/gateway/config/config.goto 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
{
"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"
}
GHSA-H9W4-3HV9-J8R3
Vulnerability from github – Published: 2024-04-10 18:30 – Updated: 2024-04-10 18:30A Denial of Service (DoS) vulnerability exists in the mintplex-labs/anything-llm repository when the application is running in 'just me' mode with a password. An attacker can exploit this vulnerability by making a request to the endpoint using the [validatedRequest] middleware with a specially crafted 'Authorization:' header. This vulnerability leads to uncontrolled resource consumption, causing a DoS condition.
{
"affected": [],
"aliases": [
"CVE-2024-3569"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T17:15:58Z",
"severity": "HIGH"
},
"details": "A Denial of Service (DoS) vulnerability exists in the mintplex-labs/anything-llm repository when the application is running in \u0027just me\u0027 mode with a password. An attacker can exploit this vulnerability by making a request to the endpoint using the [validatedRequest] middleware with a specially crafted \u0027Authorization:\u0027 header. This vulnerability leads to uncontrolled resource consumption, causing a DoS condition.",
"id": "GHSA-h9w4-3hv9-j8r3",
"modified": "2024-04-10T18:30:49Z",
"published": "2024-04-10T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3569"
},
{
"type": "WEB",
"url": "https://github.com/mintplex-labs/anything-llm/commit/efe9dfa5e3550d12abd34d06ab7f8fbcf2206cfa"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/619e13bd-b723-4727-9ccb-5099d698432e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H9WV-H3G7-2R2R
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-08-06 00:00Multiple vulnerabilities in the implementation of the Cisco Discovery Protocol and Link Layer Discovery Protocol (LLDP) for Cisco Video Surveillance 7000 Series IP Cameras could allow an unauthenticated, adjacent attacker to cause a memory leak, which could lead to a denial of service (DoS) condition on an affected device. These vulnerabilities are due to incorrect processing of certain Cisco Discovery Protocol and LLDP packets at ingress time. An attacker could exploit these vulnerabilities by sending crafted Cisco Discovery Protocol or LLDP packets to an affected device. A successful exploit could allow the attacker to cause the affected device to continuously consume memory, which could cause the device to crash and reload, resulting in a DoS condition. Note: Cisco Discovery Protocol and LLDP are Layer 2 protocols. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent).
{
"affected": [],
"aliases": [
"CVE-2021-1564"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-04T17:15:00Z",
"severity": "MODERATE"
},
"details": "Multiple vulnerabilities in the implementation of the Cisco Discovery Protocol and Link Layer Discovery Protocol (LLDP) for Cisco Video Surveillance 7000 Series IP Cameras could allow an unauthenticated, adjacent attacker to cause a memory leak, which could lead to a denial of service (DoS) condition on an affected device. These vulnerabilities are due to incorrect processing of certain Cisco Discovery Protocol and LLDP packets at ingress time. An attacker could exploit these vulnerabilities by sending crafted Cisco Discovery Protocol or LLDP packets to an affected device. A successful exploit could allow the attacker to cause the affected device to continuously consume memory, which could cause the device to crash and reload, resulting in a DoS condition. Note: Cisco Discovery Protocol and LLDP are Layer 2 protocols. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent).",
"id": "GHSA-h9wv-h3g7-2r2r",
"modified": "2022-08-06T00:00:48Z",
"published": "2022-05-24T19:04:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1564"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ipcamera-lldpcdp-mem-yTQDmjRO"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HC3G-RGGM-P6X9
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2023-08-16 18:30A vulnerability in the WebVPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause increased CPU utilization on an affected device. The vulnerability is due to excessive processing load for a specific WebVPN HTTP page request. An attacker could exploit this vulnerability by sending multiple WebVPN HTTP page load requests for a specific URL. A successful exploit could allow the attacker to increase CPU load on the device, resulting in a denial of service (DoS) condition, which could cause traffic to be delayed through the device.
{
"affected": [],
"aliases": [
"CVE-2019-12698"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-02T19:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the WebVPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause increased CPU utilization on an affected device. The vulnerability is due to excessive processing load for a specific WebVPN HTTP page request. An attacker could exploit this vulnerability by sending multiple WebVPN HTTP page load requests for a specific URL. A successful exploit could allow the attacker to increase CPU load on the device, resulting in a denial of service (DoS) condition, which could cause traffic to be delayed through the device.",
"id": "GHSA-hc3g-rggm-p6x9",
"modified": "2023-08-16T18:30:18Z",
"published": "2022-05-24T16:57:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12698"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20191002-asa-ftd-dos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HC4F-JC7G-W997
Vulnerability from github – Published: 2024-07-09 15:30 – Updated: 2026-06-26 12:30A vulnerability was found in OpenJPEG similar to CVE-2019-6988. This flaw allows an attacker to bypass existing protections and cause an application crash through a maliciously crafted file.
{
"affected": [],
"aliases": [
"CVE-2023-39328"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T14:15:03Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in OpenJPEG similar to CVE-2019-6988. This flaw allows an attacker to bypass existing protections and cause an application crash through a maliciously crafted file.",
"id": "GHSA-hc4f-jc7g-w997",
"modified": "2026-06-26T12:30:28Z",
"published": "2024-07-09T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39328"
},
{
"type": "WEB",
"url": "https://github.com/uclouvain/openjpeg/issues/1476"
},
{
"type": "WEB",
"url": "https://github.com/uclouvain/openjpeg/pull/1470"
},
{
"type": "WEB",
"url": "https://github.com/uclouvain/openjpeg/pull/1471"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-39328"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2219236"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HC6J-MMWG-VMWW
Vulnerability from github – Published: 2022-10-15 12:01 – Updated: 2022-10-18 19:00In sensor driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service in kernel.
{
"affected": [],
"aliases": [
"CVE-2022-39124"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-14T19:15:00Z",
"severity": "MODERATE"
},
"details": "In sensor driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service in kernel.",
"id": "GHSA-hc6j-mmwg-vmww",
"modified": "2022-10-18T19:00:30Z",
"published": "2022-10-15T12:01:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39124"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1575654905820020738"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HC9W-4P87-J549
Vulnerability from github – Published: 2018-11-07 20:46 – Updated: 2023-02-04 00:15Version of cached-path-relative before 1.0.2 are vulnerable to prototype pollution.
Recommendation
Update to version 1.0.2 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "cached-path-relative"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-16472"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:39:57Z",
"nvd_published_at": "2018-11-06T19:29:00Z",
"severity": "HIGH"
},
"details": "Version of `cached-path-relative` before 1.0.2 are vulnerable to prototype pollution.\n\n\n## Recommendation\n\nUpdate to version 1.0.2 or later.",
"id": "GHSA-hc9w-4p87-j549",
"modified": "2023-02-04T00:15:03Z",
"published": "2018-11-07T20:46:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16472"
},
{
"type": "WEB",
"url": "https://github.com/ashaffer/cached-path-relative/issues/3"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/390847"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-hc9w-4p87-j549"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/security-wg/blob/master/vuln/npm/480.json"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00006.html"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/739"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Prototype Pollution in cached-path-relative"
}
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.