Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5629 vulnerabilities reference this CWE, most recent first.

GHSA-885G-R558-QX2M

Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2022-05-13 01:09
VLAI
Details

By specially crafting HTTP/2 requests, workers would be allocated 60 seconds longer than necessary, leading to worker exhaustion and a denial of service. Fixed in Apache HTTP Server 2.4.34 (Affected 2.4.18-2.4.30,2.4.33).

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-1333"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-18T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "By specially crafting HTTP/2 requests, workers would be allocated 60 seconds longer than necessary, leading to worker exhaustion and a denial of service. Fixed in Apache HTTP Server 2.4.34 (Affected 2.4.18-2.4.30,2.4.33).",
  "id": "GHSA-885g-r558-qx2m",
  "modified": "2022-05-13T01:09:39Z",
  "published": "2022-05-13T01:09:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1333"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/tns-2019-09"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3783-1"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03909en_us"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180926-0007"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re473305a65b4db888e3556e4dae10c2a04ee89dcff2e26ecdbd860a9@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd2fb621142e7fa187cfe12d7137bf66e7234abcbbcd800074c84a538@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r76142b8c5119df2178be7c2dba88fde552eedeec37ea993dfce68d1d@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r15f9aa4427581a1aecb4063f1b4b983511ae1c9935e2a0a6876dad3c@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r06f0d87ebb6d59ed8379633f36f72f5b1f79cadfda72ede0830b42cf@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/84a3714f0878781f6ed84473d1a503d2cc382277e100450209231830@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2018-1333"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0367"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0366"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:3558"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041402"
    }
  ],
  "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-887C-6389-89QH

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02
VLAI
Details

In JetBrains IntelliJ IDEA before 2021.1, DoS was possible because of unbounded resource allocation.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-30504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-11T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "In JetBrains IntelliJ IDEA before 2021.1, DoS was possible because of unbounded resource allocation.",
  "id": "GHSA-887c-6389-89qh",
  "modified": "2022-05-24T19:02:09Z",
  "published": "2022-05-24T19:02:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30504"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com/blog/2021/05/07/jetbrains-security-bulletin-q1-2021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-889J-63JV-QHR8

Vulnerability from github – Published: 2025-05-08 19:28 – Updated: 2025-05-08 19:28
VLAI
Summary
Eclipse Jetty HTTP/2 client can force the server to allocate a humongous byte buffer that may lead to OoM and subsequently the JVM to exit
Details

Original Report

In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting.

Impact

Remote peers can cause the JVM to crash or continuously report OOM.

Patches

12.0.17

Workarounds

No workarounds.

References

https://github.com/jetty/jetty.project/issues/12690

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.16"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.http2:jetty-http2-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-1948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-08T19:28:45Z",
    "nvd_published_at": "2025-05-08T18:15:41Z",
    "severity": "HIGH"
  },
  "details": "### Original Report\n\nIn Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting.\n\n### Impact\nRemote peers can cause the JVM to crash or continuously report OOM.\n\n### Patches\n12.0.17\n\n### Workarounds\nNo workarounds.\n\n### References\nhttps://github.com/jetty/jetty.project/issues/12690",
  "id": "GHSA-889j-63jv-qhr8",
  "modified": "2025-05-08T19:28:45Z",
  "published": "2025-05-08T19:28:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-889j-63jv-qhr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/issues/12690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/commit/c8c2515936ef968dc8a3cecd9e79d1e69291e4bb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jetty/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignement/-/issues/56"
    }
  ],
  "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": "Eclipse Jetty HTTP/2 client can force the server to allocate a humongous byte buffer that may lead to OoM and subsequently the JVM to exit"
}

GHSA-88FW-V6X4-3F58

Vulnerability from github – Published: 2026-07-31 16:44 – Updated: 2026-07-31 16:44
VLAI
Summary
Spring Data: Unbounded property-path cache keyed by externally-supplied path string
Details

src/main/java/org/springframework/data/mapping/context/PersistentPropertyPathFactory.java:175 · Unbounded Resource Allocation (Algorithmic DoS)

Impact

When a consuming module routes user-supplied dot-paths (sort parameters, projection paths, PATCH paths) through MappingContext.getPersistentPropertyPath(String, Class), each distinct string — including invalid ones — is cached forever. A remote attacker can send millions of requests with unique ?sort=aaaa<n> values and grow the heap until the service OOMs.

Description

PersistentPropertyPathFactory.propertyPaths (line 53) is a ConcurrentHashMap<TypeAndPath, PathResolution> populated by getPotentiallyCachedPath() (line 174-177) via computeIfAbsent. The key is (TypeInformation, rawPathString). Crucially, unresolvable paths are also cached (as PathResolution.unresolved, line 204) so that the same InvalidPersistentPropertyPath can be re-thrown — meaning every distinct garbage string an attacker sends creates a permanent entry. There is no eviction. This is reachable from AbstractMappingContext.getPersistentPropertyPath(String, Class) (AbstractMappingContext.java:345), which Spring Data REST and several store query mappers call with HTTP-request-derived sort/filter property names.

By contrast, the sibling SimplePropertyPath.cache was already hardened to use ConcurrentReferenceHashMap (soft refs); this cache was not given the same treatment.

Exploit scenario

Against a Spring Data REST endpoint, an attacker scripts GET /things?sort=<random-40-char-string> in a loop. Each request fails fast with InvalidPersistentPropertyPath, but each distinct random string leaves behind a TypeAndPath key, a PathResolution object holding the split segments list, and the source string in the map. After ~10M requests the JVM OOMs.

Preconditions

  • A downstream component (Spring Data REST, a store-specific QueryMapper, or application code) passes externally-supplied strings to MappingContext.getPersistentPropertyPath(String, ...)
  • No upstream rate-limiting or path-string validation

How to fix

A cache whose key can be derived from external input must be bounded. Replace propertyPaths (line 53) with a ConcurrentLruCache<TypeAndPath, PathResolution> of fixed capacity, or ConcurrentReferenceHashMap (matching the sibling SimplePropertyPath.cache). Additionally, do not cache PathResolution.unresolved results at all (line 204 in createPersistentPropertyPath) — re-computing a failed lookup is cheap, and caching negative results for arbitrary attacker strings is what makes this exploitable.

Adversarial verification

Verdict: TRUE_POSITIVE (confidence: 7/10) — unbounded hard-ref ConcurrentHashMap keyed by raw path string, caches unresolved entries (line 204), reachable via public MappingContext.getPersistentPropertyPath(String, ...); sibling PropertyPath cache was already converted to soft-refs but this one was missed. -3 confidence because the HTTP-input wiring lives in downstream modules (Spring Data REST / store mappers), not verifiable in this repo.

Code at the line — CONFIRMED - Line 53: private final Map<TypeAndPath, PathResolution> propertyPaths = new ConcurrentHashMap<>(); — plain CHM, hard refs, no eviction, no size bound. - Line 175: propertyPaths.computeIfAbsent(TypeAndPath.of(type, propertyPath), ...) — every distinct (type, string) pair is inserted. - Line 204: return PathResolution.unresolved(parts, segment, type, currentPath); — returned from inside computeIfAbsent's mapping function, so unresolvable paths are cached. The PathResolution retains the full attacker string (source = StringUtils.collectionToDelimitedString(parts, "."), line 452).

Callers within spring-data-commons - AbstractMappingContext.getPersistentPropertyPath(String, Class<?>) (line 345) and (String, TypeInformation<?>) (line 350) → persistentPropertyPathFactory.from(type, propertyPath) → straight into the unbounded cache. No validation, no PropertyPath.from gate. - This is the public MappingContext interface (MappingContext.java:174,186), documented to throw InvalidPersistentPropertyPath on bad input — i.e., the contract explicitly anticipates being called with possibly-invalid strings. - No in-repo caller routes HTTP input directly into the String overload. The Sort.Order.property → getPersistentPropertyPath(String, ...) bridge lives in store modules (Spring Data MongoDB QueryMapper, Spring Data REST sort translator). That wiring is out-of-repo as the finding states.

Protections — NONE on this cache Contrast: SimplePropertyPath.java:52 (the PropertyPath.from cache) uses ConcurrentReferenceHashMap (soft refs, GC-evictable). Spring already hardened the sibling cache against exactly this pattern. PersistentPropertyPathFactory.propertyPaths was not given the same treatment.

Stress-test Is this exclusion #3 (intended design)? The PathResolution javadoc (line 426-430) says caching unresolved paths is deliberate — to make repeated lookups of the same bad path cheap. But unbounded hard-ref caching of arbitrary attacker-chosen keys is not the intent; the sibling fix proves Spring considers this a bug class.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.0.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.data:spring-data-commons"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5.11"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.data:spring-data-commons"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.5.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.data:spring-data-commons"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.0"
            },
            {
              "last_affected": "3.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T16:44:15Z",
    "nvd_published_at": "2026-06-10T00:16:50Z",
    "severity": "HIGH"
  },
  "details": "`src/main/java/org/springframework/data/mapping/context/PersistentPropertyPathFactory.java:175` \u00b7 Unbounded Resource Allocation (Algorithmic DoS)\n\n### Impact\n\nWhen a consuming module routes user-supplied dot-paths (sort parameters, projection paths, PATCH paths) through `MappingContext.getPersistentPropertyPath(String, Class)`, each distinct string \u2014 including invalid ones \u2014 is cached forever. A remote attacker can send millions of requests with unique `?sort=aaaa\u003cn\u003e` values and grow the heap until the service OOMs.\n\n### Description\n\n`PersistentPropertyPathFactory.propertyPaths` (line 53) is a `ConcurrentHashMap\u003cTypeAndPath, PathResolution\u003e` populated by `getPotentiallyCachedPath()` (line 174-177) via `computeIfAbsent`. The key is `(TypeInformation, rawPathString)`. Crucially, unresolvable paths are also cached (as `PathResolution.unresolved`, line 204) so that the same `InvalidPersistentPropertyPath` can be re-thrown \u2014 meaning every distinct garbage string an attacker sends creates a permanent entry. There is no eviction. This is reachable from `AbstractMappingContext.getPersistentPropertyPath(String, Class)` (`AbstractMappingContext.java:345`), which Spring Data REST and several store query mappers call with HTTP-request-derived sort/filter property names.\n\nBy contrast, the sibling `SimplePropertyPath.cache` was already hardened to use `ConcurrentReferenceHashMap` (soft refs); this cache was not given the same treatment.\n\n### Exploit scenario\n\nAgainst a Spring Data REST endpoint, an attacker scripts `GET /things?sort=\u003crandom-40-char-string\u003e` in a loop. Each request fails fast with `InvalidPersistentPropertyPath`, but each distinct random string leaves behind a `TypeAndPath` key, a `PathResolution` object holding the split segments list, and the source string in the map. After ~10M requests the JVM OOMs.\n\n### Preconditions\n\n- A downstream component (Spring Data REST, a store-specific `QueryMapper`, or application code) passes externally-supplied strings to `MappingContext.getPersistentPropertyPath(String, ...)`\n- No upstream rate-limiting or path-string validation\n\n### How to fix\n\nA cache whose key can be derived from external input must be bounded. Replace `propertyPaths` (line 53) with a `ConcurrentLruCache\u003cTypeAndPath, PathResolution\u003e` of fixed capacity, or `ConcurrentReferenceHashMap` (matching the sibling `SimplePropertyPath.cache`). Additionally, do not cache `PathResolution.unresolved` results at all (line 204 in `createPersistentPropertyPath`) \u2014 re-computing a failed lookup is cheap, and caching negative results for arbitrary attacker strings is what makes this exploitable.\n\n### Adversarial verification\n\n**Verdict:** TRUE_POSITIVE (confidence: 7/10) \u2014 unbounded hard-ref `ConcurrentHashMap` keyed by raw path string, caches unresolved entries (line 204), reachable via public `MappingContext.getPersistentPropertyPath(String, ...)`; sibling `PropertyPath` cache was already converted to soft-refs but this one was missed. -3 confidence because the HTTP-input wiring lives in downstream modules (Spring Data REST / store mappers), not verifiable in this repo.\n\n**Code at the line \u2014 CONFIRMED**\n- Line 53: `private final Map\u003cTypeAndPath, PathResolution\u003e propertyPaths = new ConcurrentHashMap\u003c\u003e();` \u2014 plain CHM, hard refs, no eviction, no size bound.\n- Line 175: `propertyPaths.computeIfAbsent(TypeAndPath.of(type, propertyPath), ...)` \u2014 every distinct `(type, string)` pair is inserted.\n- Line 204: `return PathResolution.unresolved(parts, segment, type, currentPath);` \u2014 returned from inside `computeIfAbsent`\u0027s mapping function, so unresolvable paths are cached. The `PathResolution` retains the full attacker string (`source = StringUtils.collectionToDelimitedString(parts, \".\")`, line 452).\n\n**Callers within spring-data-commons**\n- `AbstractMappingContext.getPersistentPropertyPath(String, Class\u003c?\u003e)` (line 345) and `(String, TypeInformation\u003c?\u003e)` (line 350) \u2192 `persistentPropertyPathFactory.from(type, propertyPath)` \u2192 straight into the unbounded cache. No validation, no `PropertyPath.from` gate.\n- This is the public `MappingContext` interface (`MappingContext.java:174,186`), documented to throw `InvalidPersistentPropertyPath` on bad input \u2014 i.e., the contract explicitly anticipates being called with possibly-invalid strings.\n- No in-repo caller routes HTTP input directly into the `String` overload. The `Sort.Order.property` \u2192 `getPersistentPropertyPath(String, ...)` bridge lives in store modules (Spring Data MongoDB `QueryMapper`, Spring Data REST sort translator). That wiring is out-of-repo as the finding states.\n\n**Protections \u2014 NONE on this cache**\nContrast: `SimplePropertyPath.java:52` (the `PropertyPath.from` cache) uses `ConcurrentReferenceHashMap` (soft refs, GC-evictable). Spring already hardened the sibling cache against exactly this pattern. `PersistentPropertyPathFactory.propertyPaths` was not given the same treatment.\n\n**Stress-test**\nIs this exclusion #3 (intended design)? The `PathResolution` javadoc (line 426-430) says caching unresolved paths is deliberate \u2014 to make repeated lookups of the *same* bad path cheap. But unbounded hard-ref caching of *arbitrary attacker-chosen* keys is not the intent; the sibling fix proves Spring considers this a bug class.",
  "id": "GHSA-88fw-v6x4-3f58",
  "modified": "2026-07-31T16:44:15Z",
  "published": "2026-07-31T16:44:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/security-advisories/security/advisories/GHSA-88fw-v6x4-3f58"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41695"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-data-commons/commit/96e9475b963218bb702959524187342671f6b080"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-data-commons/commit/a4f893b66c18c70f2b22f29a2b55097b73c89941"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/security-advisories"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-data-commons/releases/tag/3.5.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-data-commons/releases/tag/4.0.6"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-41695"
    }
  ],
  "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": "Spring Data: Unbounded property-path cache keyed by externally-supplied path string"
}

GHSA-88HF-WF7H-7W4M

Vulnerability from github – Published: 2026-04-28 23:23 – Updated: 2026-05-08 19:32
VLAI
Summary
OpenTelemetry's Zipkin remote endpoint cache could grow without bounds and increase memory pressure
Details

Summary

The Zipkin exporter remote endpoint cache accepted unbounded key growth derived from span attributes. In high-cardinality scenarios, this could increase process memory usage over time and degrade availability.

Details

  • Introduce a bounded, thread-safe LRU cache for remote endpoints.
  • Enforce fixed maximum size to prevent unbounded growth.

Impact

  • A process using Zipkin export for client/producer spans could experience avoidable memory growth under sustained unique remote endpoint values.

Resources

#7081

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.15.2"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Exporter.Zipkin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-28T23:23:28Z",
    "nvd_published_at": "2026-05-06T22:16:25Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Zipkin exporter remote endpoint cache accepted unbounded key growth derived from span attributes. In high-cardinality scenarios, this could increase process memory usage over time and degrade availability.\n\n### Details\n\n- Introduce a bounded, thread-safe LRU cache for remote endpoints.\n- Enforce fixed maximum size to prevent unbounded growth.\n\n### Impact\n\n- A process using Zipkin export for client/producer spans could experience avoidable memory growth under sustained unique remote endpoint values.\n\n### Resources\n\n[#7081](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7081)",
  "id": "GHSA-88hf-wf7h-7w4m",
  "modified": "2026-05-08T19:32:38Z",
  "published": "2026-04-28T23:23:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-88hf-wf7h-7w4m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41310"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/7081"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/commit/c724f4bd6fd88e9a599af1668bf7af9487155b62"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry\u0027s Zipkin remote endpoint cache could grow without bounds and increase memory pressure"
}

GHSA-88J9-XVHV-GWC6

Vulnerability from github – Published: 2023-12-07 21:31 – Updated: 2023-12-07 21:31
VLAI
Details

Under certain circumstances, invalid authentication credentials could be sent to the login endpoint of Johnson Controls Metasys NAE55, SNE, and SNC engines prior to version 12.0.4 and Facility Explorer F4-SNC engines prior to versions 11.0.6 and 12.0.4 to cause denial-of-service.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-4486"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-07T20:15:38Z",
    "severity": "HIGH"
  },
  "details": "Under certain circumstances, invalid authentication credentials could be sent to the login endpoint of Johnson Controls Metasys NAE55, SNE, and SNC engines prior to version 12.0.4 and Facility Explorer F4-SNC engines prior to versions 11.0.6 and 12.0.4 to cause denial-of-service.\n\n",
  "id": "GHSA-88j9-xvhv-gwc6",
  "modified": "2023-12-07T21:31:12Z",
  "published": "2023-12-07T21:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4486"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-341-03"
    },
    {
      "type": "WEB",
      "url": "https://www.johnsoncontrols.com/cyber-solutions/security-advisories"
    }
  ],
  "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-88MP-PM8G-WWCF

Vulnerability from github – Published: 2025-10-03 18:31 – Updated: 2025-10-03 21:30
VLAI
Details

A TCL Smart TV running a vulnerable UPnP/DLNA MediaRenderer implementation is affected by a remote, unauthenticated Denial of Service (DoS) condition. By sending a flood of malformed or oversized SetAVTransportURI SOAP requests to the UPnP control endpoint, an attacker can cause the device to become unresponsive. This denial persists as long as the attack continues and affects all forms of TV operation. Manual user control and even reboots do not restore functionality unless the flood stops.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-55972"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-03T16:16:17Z",
    "severity": "HIGH"
  },
  "details": "A TCL Smart TV running a vulnerable UPnP/DLNA MediaRenderer implementation is affected by a remote, unauthenticated Denial of Service (DoS) condition. By sending a flood of malformed or oversized SetAVTransportURI SOAP requests to the UPnP control endpoint, an attacker can cause the device to become unresponsive. This denial persists as long as the attack continues and affects all forms of TV operation. Manual user control and even reboots do not restore functionality unless the flood stops.",
  "id": "GHSA-88mp-pm8g-wwcf",
  "modified": "2025-10-03T21:30:56Z",
  "published": "2025-10-03T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55972"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Szym0n13k/CVE-2025-55972-Remote-Unauthenticated-Denial-of-Service-DoS-in-TCL-Smart-TV-UPnP-DLNA-AVTransport"
    },
    {
      "type": "WEB",
      "url": "https://www.youtube.com/watch?v=CRik5mp4SW4"
    }
  ],
  "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-88PW-P67X-2JRR

Vulnerability from github – Published: 2023-03-23 21:30 – Updated: 2023-03-27 18:30
VLAI
Details

Denial of Service in GitHub repository radareorg/radare2 prior to 5.8.6.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-1605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-23T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Denial of Service in GitHub repository radareorg/radare2 prior to 5.8.6.",
  "id": "GHSA-88pw-p67x-2jrr",
  "modified": "2023-03-27T18:30:26Z",
  "published": "2023-03-23T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/radareorg/radare2/commit/508a6307045441defd1bef0999a1f7052097613f"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/9dddcf5b-7dd4-46cc-abf9-172dce20bab2"
    }
  ],
  "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-88V5-63HW-WW87

Vulnerability from github – Published: 2025-09-04 21:31 – Updated: 2025-09-05 18:31
VLAI
Details

In setupAccessibilityServices of AccessibilityFragment.java , there is a possible way to hide an enabled accessibility service due to a logic error in the code. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-40664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T20:15:33Z",
    "severity": "MODERATE"
  },
  "details": "In setupAccessibilityServices of AccessibilityFragment.java , there is a possible way to hide an enabled accessibility service due to a logic error in the code. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-88v5-63hw-ww87",
  "modified": "2025-09-05T18:31:19Z",
  "published": "2025-09-04T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40664"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/wear/2025-05-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-892H-R6CR-53G4

Vulnerability from github – Published: 2023-09-08 18:30 – Updated: 2023-11-04 03:30
VLAI
Details

QUIC connections do not set an upper bound on the amount of data buffered when reading post-handshake messages, allowing a malicious QUIC connection to cause unbounded memory growth. With fix, connections now consistently reject messages larger than 65KiB in size.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-39322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-08T17:15:28Z",
    "severity": "HIGH"
  },
  "details": "QUIC connections do not set an upper bound on the amount of data buffered when reading post-handshake messages, allowing a malicious QUIC connection to cause unbounded memory growth. With fix, connections now consistently reject messages larger than 65KiB in size.",
  "id": "GHSA-892h-r6cr-53g4",
  "modified": "2023-11-04T03:30:18Z",
  "published": "2023-09-08T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39322"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/523039"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/62266"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-dev/c/2C5vbR-UNkI/m/L1hdrPhfBAAJ"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2023-2045"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202311-09"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231020-0004"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

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
Architecture and Design
  • 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
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

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.

← Back to the CWE list