CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6465 vulnerabilities reference this CWE, most recent first.
GHSA-8HJH-2XHJ-MX62
Vulnerability from github – Published: 2026-06-08 03:47 – Updated: 2026-06-08 03:47A flaw has been found in kokke tiny-regex-c up to f2632c6d9ed25272987471cdb8b70395c2460bdb. This vulnerability affects the function matchstar of the file re.c of the component Pattern Handler. This manipulation causes inefficient regular expression complexity. The attack is restricted to local execution. The exploit has been published and may be used. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2026-11478"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T03:16:19Z",
"severity": "LOW"
},
"details": "A flaw has been found in kokke tiny-regex-c up to f2632c6d9ed25272987471cdb8b70395c2460bdb. This vulnerability affects the function matchstar of the file re.c of the component Pattern Handler. This manipulation causes inefficient regular expression complexity. The attack is restricted to local execution. The exploit has been published and may be used. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-8hjh-2xhj-mx62",
"modified": "2026-06-08T03:47:24Z",
"published": "2026-06-08T03:47:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11478"
},
{
"type": "WEB",
"url": "https://github.com/kokke/tiny-regex-c/issues/100"
},
{
"type": "WEB",
"url": "https://github.com/kokke/tiny-regex-c"
},
{
"type": "WEB",
"url": "https://github.com/user-attachments/files/28046213/tiny-regex-c-redos-poc.zip"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-11478"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/833966"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/369098"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/369098/cti"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-8HJV-92Q9-G4XJ
Vulnerability from github – Published: 2026-05-06 20:00 – Updated: 2026-07-10 00:09Summary
TimeConverterRegistrar caches DateTimeFormatter instances in an unbounded ConcurrentHashMap<String, DateTimeFormatter> whose key is derived from the @Format annotation pattern concatenated with the locale from the HTTP Accept-Language header. Because Locale.forLanguageTag() accepts arbitrary BCP 47 private-use extensions (en-x-a001, en-x-a002, …), an unauthenticated attacker can generate an unlimited number of unique cache keys by sending requests with novel locale tags, growing the cache until heap memory is exhausted and the JVM crashes. This is structurally identical to the recently patched GHSA-2hcp-gjrf-7fhc (DefaultHtmlErrorResponseBodyProvider), but TimeConverterRegistrar.formattersCache was not covered by that fix.
Details
The vulnerable cache is declared in context/src/main/java/io/micronaut/runtime/converters/time/TimeConverterRegistrar.java at line 123:
// TimeConverterRegistrar.java:123
private final Map<String, DateTimeFormatter> formattersCache = new ConcurrentHashMap<>();
The getFormatter method at line 434 inserts into this map with no eviction or size limit:
// TimeConverterRegistrar.java:434-443
private DateTimeFormatter getFormatter(String pattern, ConversionContext context) {
var key = pattern + context.getLocale(); // locale from Accept-Language header
var cachedFormatter = formattersCache.get(key);
if (cachedFormatter != null) {
return cachedFormatter;
}
var formatter = DateTimeFormatter.ofPattern(pattern, context.getLocale());
formattersCache.put(key, formatter); // NO SIZE CHECK — unbounded growth
return formatter;
}
The attacker-controlled locale flows into the cache key through this call chain:
- HTTP header parsed —
HttpHeaders.findAcceptLanguage()athttp/src/main/java/io/micronaut/http/HttpHeaders.java:766-771callsLocale.forLanguageTag(part)directly on the rawAccept-Languagevalue:
// HttpHeaders.java:766-771
default Optional<Locale> findAcceptLanguage() {
return findFirst(HttpHeaders.ACCEPT_LANGUAGE)
.map(text -> {
String part = HttpHeadersUtil.splitAcceptHeader(text);
return part == null ? Locale.getDefault() : Locale.forLanguageTag(part);
});
}
- Locale planted in ConversionContext —
AbstractRouteMatch.newContext()atrouter/src/main/java/io/micronaut/web/router/AbstractRouteMatch.java:373-378passes the request locale into the conversion context for every route argument binding:
// AbstractRouteMatch.java:373-378
private <E> ArgumentConversionContext<E> newContext(Argument<E> argument, HttpRequest<?> request) {
return ConversionContext.of(
argument,
request.getLocale().orElse(null), // ← attacker-controlled via Accept-Language
request.getCharacterEncoding()
);
}
- Unbounded cache insert — When any temporal argument annotated with
@Formatis bound,TimeConverterRegistrar.getFormatter(pattern, context)is called and inserts a newDateTimeFormatterfor each uniquepattern + localekey.
This path is triggered for any route endpoint with a @Format-annotated temporal parameter. This is an officially documented and commonly used Micronaut pattern, demonstrated in the framework's own test suite:
// test-suite/.../BindingController.java:105 (official Micronaut example)
@Get("/dateFormat")
public String dateFormat(@Format("dd/MM/yyyy hh:mm:ss a z") @Header ZonedDateTime date) {
return date.toString();
}
TimeConverterRegistrar is an @Internal core bean registered unconditionally in every Micronaut application — it is not optional or user-configured. By contrast, the DefaultHtmlErrorResponseBodyProvider cache patched in GHSA-2hcp-gjrf-7fhc now uses a ConcurrentLinkedHashMap bounded at 100 entries; TimeConverterRegistrar.formattersCache remains an unbounded plain ConcurrentHashMap.
PoC
Against any Micronaut application exposing an endpoint with a @Format-annotated temporal parameter:
# Flood the formattersCache with unique locale-derived keys
for i in $(seq 1 200000); do
curl -s -o /dev/null \
-H "Accept-Language: en-x-$(printf '%06d' $i)" \
-H "date: 01/01/2024 12:00:00 AM UTC" \
"http://localhost:8080/dateFormat" &
# Throttle to avoid socket exhaustion
[ $((i % 500)) -eq 0 ] && wait
done
wait
# Server will throw OutOfMemoryError after enough unique locale entries accumulate
Each request with a novel en-x-XXXXXX private-use tag inserts a new DateTimeFormatter entry into the unbounded map. Each DateTimeFormatter (with locale metadata) occupies roughly 2–10 KB on the heap. At 100,000 unique entries, the map alone can consume ~500 MB; at 500,000 entries the JVM typically crashes with OutOfMemoryError: Java heap space.
Impact
- An unauthenticated attacker can crash any Micronaut server that exposes at least one endpoint with a
@Format-annotated temporal type parameter — a documented, first-class framework feature. - Memory grows linearly with the number of unique
Accept-Languagevalues sent. The BCP 47 private-use namespace (en-x-ANYTHING) provides millions of distinct valid locale strings. - No credentials, special permissions, or exploitation of application logic are required — only the ability to send HTTP requests with custom headers.
TimeConverterRegistraris active in all Micronaut HTTP server applications by default; no special configuration is needed to be vulnerable.
Recommended Fix
Apply the same fix pattern used for GHSA-2hcp-gjrf-7fhc: replace the unbounded ConcurrentHashMap with a bounded ConcurrentLinkedHashMap:
// In TimeConverterRegistrar.java — replace line 123
import io.micronaut.core.util.clhm.ConcurrentLinkedHashMap;
private static final int MAX_FORMATTERS_CACHE_SIZE = 100;
private final Map<String, DateTimeFormatter> formattersCache =
new ConcurrentLinkedHashMap.Builder<String, DateTimeFormatter>()
.maximumWeightedCapacity(MAX_FORMATTERS_CACHE_SIZE)
.build();
Alternatively, since @Format pattern values come from static annotations (a bounded, compile-time set), the locale should be excluded from the cache key and applied at use-time instead:
// In getFormatter() — cache only by pattern, apply locale at use-time
private DateTimeFormatter getFormatter(String pattern, ConversionContext context) {
DateTimeFormatter base = formattersCache.computeIfAbsent(
pattern, p -> DateTimeFormatter.ofPattern(p)
);
Locale locale = context.getLocale();
return locale != null ? base.withLocale(locale) : base;
}
This second approach bounds the cache by the number of distinct @Format patterns in the application, which is always small and finite, fully eliminating the attack surface.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.micronaut:micronaut-context"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.10.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.micronaut:micronaut-context"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.0"
},
{
"fixed": "3.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.micronaut:micronaut-context"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.8.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44241"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T20:00:22Z",
"nvd_published_at": "2026-05-12T22:16:35Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`TimeConverterRegistrar` caches `DateTimeFormatter` instances in an unbounded `ConcurrentHashMap\u003cString, DateTimeFormatter\u003e` whose key is derived from the `@Format` annotation pattern concatenated with the locale from the HTTP `Accept-Language` header. Because `Locale.forLanguageTag()` accepts arbitrary BCP 47 private-use extensions (`en-x-a001`, `en-x-a002`, \u2026), an unauthenticated attacker can generate an unlimited number of unique cache keys by sending requests with novel locale tags, growing the cache until heap memory is exhausted and the JVM crashes. This is structurally identical to the recently patched GHSA-2hcp-gjrf-7fhc (`DefaultHtmlErrorResponseBodyProvider`), but `TimeConverterRegistrar.formattersCache` was not covered by that fix.\n\n## Details\n\nThe vulnerable cache is declared in `context/src/main/java/io/micronaut/runtime/converters/time/TimeConverterRegistrar.java` at line 123:\n\n```java\n// TimeConverterRegistrar.java:123\nprivate final Map\u003cString, DateTimeFormatter\u003e formattersCache = new ConcurrentHashMap\u003c\u003e();\n```\n\nThe `getFormatter` method at line 434 inserts into this map with no eviction or size limit:\n\n```java\n// TimeConverterRegistrar.java:434-443\nprivate DateTimeFormatter getFormatter(String pattern, ConversionContext context) {\n var key = pattern + context.getLocale(); // locale from Accept-Language header\n var cachedFormatter = formattersCache.get(key);\n if (cachedFormatter != null) {\n return cachedFormatter;\n }\n var formatter = DateTimeFormatter.ofPattern(pattern, context.getLocale());\n formattersCache.put(key, formatter); // NO SIZE CHECK \u2014 unbounded growth\n return formatter;\n}\n```\n\nThe attacker-controlled locale flows into the cache key through this call chain:\n\n1. **HTTP header parsed** \u2014 `HttpHeaders.findAcceptLanguage()` at `http/src/main/java/io/micronaut/http/HttpHeaders.java:766-771` calls `Locale.forLanguageTag(part)` directly on the raw `Accept-Language` value:\n\n```java\n// HttpHeaders.java:766-771\ndefault Optional\u003cLocale\u003e findAcceptLanguage() {\n return findFirst(HttpHeaders.ACCEPT_LANGUAGE)\n .map(text -\u003e {\n String part = HttpHeadersUtil.splitAcceptHeader(text);\n return part == null ? Locale.getDefault() : Locale.forLanguageTag(part);\n });\n}\n```\n\n2. **Locale planted in ConversionContext** \u2014 `AbstractRouteMatch.newContext()` at `router/src/main/java/io/micronaut/web/router/AbstractRouteMatch.java:373-378` passes the request locale into the conversion context for every route argument binding:\n\n```java\n// AbstractRouteMatch.java:373-378\nprivate \u003cE\u003e ArgumentConversionContext\u003cE\u003e newContext(Argument\u003cE\u003e argument, HttpRequest\u003c?\u003e request) {\n return ConversionContext.of(\n argument,\n request.getLocale().orElse(null), // \u2190 attacker-controlled via Accept-Language\n request.getCharacterEncoding()\n );\n}\n```\n\n3. **Unbounded cache insert** \u2014 When any temporal argument annotated with `@Format` is bound, `TimeConverterRegistrar.getFormatter(pattern, context)` is called and inserts a new `DateTimeFormatter` for each unique `pattern + locale` key.\n\nThis path is triggered for any route endpoint with a `@Format`-annotated temporal parameter. This is an officially documented and commonly used Micronaut pattern, demonstrated in the framework\u0027s own test suite:\n\n```java\n// test-suite/.../BindingController.java:105 (official Micronaut example)\n@Get(\"/dateFormat\")\npublic String dateFormat(@Format(\"dd/MM/yyyy hh:mm:ss a z\") @Header ZonedDateTime date) {\n return date.toString();\n}\n```\n\n`TimeConverterRegistrar` is an `@Internal` core bean registered unconditionally in every Micronaut application \u2014 it is not optional or user-configured. By contrast, the `DefaultHtmlErrorResponseBodyProvider` cache patched in GHSA-2hcp-gjrf-7fhc now uses a `ConcurrentLinkedHashMap` bounded at 100 entries; `TimeConverterRegistrar.formattersCache` remains an unbounded plain `ConcurrentHashMap`.\n\n## PoC\n\nAgainst any Micronaut application exposing an endpoint with a `@Format`-annotated temporal parameter:\n\n```bash\n# Flood the formattersCache with unique locale-derived keys\nfor i in $(seq 1 200000); do\n curl -s -o /dev/null \\\n -H \"Accept-Language: en-x-$(printf \u0027%06d\u0027 $i)\" \\\n -H \"date: 01/01/2024 12:00:00 AM UTC\" \\\n \"http://localhost:8080/dateFormat\" \u0026\n # Throttle to avoid socket exhaustion\n [ $((i % 500)) -eq 0 ] \u0026\u0026 wait\ndone\nwait\n# Server will throw OutOfMemoryError after enough unique locale entries accumulate\n```\n\nEach request with a novel `en-x-XXXXXX` private-use tag inserts a new `DateTimeFormatter` entry into the unbounded map. Each `DateTimeFormatter` (with locale metadata) occupies roughly 2\u201310 KB on the heap. At 100,000 unique entries, the map alone can consume ~500 MB; at 500,000 entries the JVM typically crashes with `OutOfMemoryError: Java heap space`.\n\n## Impact\n\n- An unauthenticated attacker can crash any Micronaut server that exposes at least one endpoint with a `@Format`-annotated temporal type parameter \u2014 a documented, first-class framework feature.\n- Memory grows linearly with the number of unique `Accept-Language` values sent. The BCP 47 private-use namespace (`en-x-ANYTHING`) provides millions of distinct valid locale strings.\n- No credentials, special permissions, or exploitation of application logic are required \u2014 only the ability to send HTTP requests with custom headers.\n- `TimeConverterRegistrar` is active in all Micronaut HTTP server applications by default; no special configuration is needed to be vulnerable.\n\n## Recommended Fix\n\nApply the same fix pattern used for GHSA-2hcp-gjrf-7fhc: replace the unbounded `ConcurrentHashMap` with a bounded `ConcurrentLinkedHashMap`:\n\n```java\n// In TimeConverterRegistrar.java \u2014 replace line 123\nimport io.micronaut.core.util.clhm.ConcurrentLinkedHashMap;\n\nprivate static final int MAX_FORMATTERS_CACHE_SIZE = 100;\n\nprivate final Map\u003cString, DateTimeFormatter\u003e formattersCache =\n new ConcurrentLinkedHashMap.Builder\u003cString, DateTimeFormatter\u003e()\n .maximumWeightedCapacity(MAX_FORMATTERS_CACHE_SIZE)\n .build();\n```\n\nAlternatively, since `@Format` pattern values come from static annotations (a bounded, compile-time set), the locale should be excluded from the cache key and applied at use-time instead:\n\n```java\n// In getFormatter() \u2014 cache only by pattern, apply locale at use-time\nprivate DateTimeFormatter getFormatter(String pattern, ConversionContext context) {\n DateTimeFormatter base = formattersCache.computeIfAbsent(\n pattern, p -\u003e DateTimeFormatter.ofPattern(p)\n );\n Locale locale = context.getLocale();\n return locale != null ? base.withLocale(locale) : base;\n}\n```\n\nThis second approach bounds the cache by the number of distinct `@Format` patterns in the application, which is always small and finite, fully eliminating the attack surface.",
"id": "GHSA-8hjv-92q9-g4xj",
"modified": "2026-07-10T00:09:19Z",
"published": "2026-05-06T20:00:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/security/advisories/GHSA-8hjv-92q9-g4xj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44241"
},
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/commit/48f05ae8dc4157816fe0050c5cf730be7d44f8b3"
},
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/commit/c2048ab740c2efdfe227813f203176e0ef93f892"
},
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/commit/c6ca8782de7338732e887d090f38c9e941bcb284"
},
{
"type": "PACKAGE",
"url": "https://github.com/micronaut-projects/micronaut-core"
},
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/releases/tag/v3.10.6"
},
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/releases/tag/v3.8.14"
},
{
"type": "WEB",
"url": "https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.10.22"
}
],
"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": "Micronaut has unbounded `formattersCache` in `TimeConverterRegistrar` that Allows Memory Exhaustion via `Accept-Language` Header"
}
GHSA-8HPX-Q4CX-GFXW
Vulnerability from github – Published: 2025-01-29 00:31 – Updated: 2025-01-29 15:31An issue in Open5GS v.2.7.2 allows a remote attacker to cause a denial of service via the ogs_dbi_auth_info function in lib/dbi/subscription.c file.
{
"affected": [],
"aliases": [
"CVE-2024-57519"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-617",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-28T23:15:08Z",
"severity": "HIGH"
},
"details": "An issue in Open5GS v.2.7.2 allows a remote attacker to cause a denial of service via the ogs_dbi_auth_info function in lib/dbi/subscription.c file.",
"id": "GHSA-8hpx-q4cx-gfxw",
"modified": "2025-01-29T15:31:34Z",
"published": "2025-01-29T00:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57519"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/issues/3635"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/commit/08b9e7c55f72649ef25b5407e7e4d938f0f16531"
},
{
"type": "WEB",
"url": "https://github.com/f4rs1ght/vuln-research/tree/main/CVE-2024-57519"
}
],
"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-8HQF-XJWP-P67V
Vulnerability from github – Published: 2023-03-28 14:40 – Updated: 2023-03-28 23:08Impact
A range of quadratic parsing issues from cmark/cmark-gfm are also present in Comrak. These can be used to craft denial-of-service attacks on services that use Comrak to parse Markdown.
Patches
0.17.0 contains fixes to known quadratic parsing issues.
Workarounds
n/a
References
- https://github.com/commonmark/cmark/issues/255
- https://github.com/commonmark/cmark/issues/389
- https://github.com/commonmark/cmark/issues/373
- https://github.com/commonmark/cmark/issues/299
- https://github.com/commonmark/cmark/issues/388
- https://github.com/commonmark/cmark/issues/284
- https://github.com/commonmark/cmark/issues/218
- https://github.com/commonmark/cmark/pull/232
- https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L63-L65
- https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L87-L89
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "comrak"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-28626"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-28T14:40:29Z",
"nvd_published_at": "2023-03-28T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nA range of quadratic parsing issues from `cmark`/`cmark-gfm` are also present in Comrak. These can be used to craft denial-of-service attacks on services that use Comrak to parse Markdown.\n\n### Patches\n0.17.0 contains fixes to known quadratic parsing issues.\n\n### Workarounds\n\nn/a\n\n### References\n\n* https://github.com/commonmark/cmark/issues/255\n* https://github.com/commonmark/cmark/issues/389\n* https://github.com/commonmark/cmark/issues/373\n* https://github.com/commonmark/cmark/issues/299\n* https://github.com/commonmark/cmark/issues/388\n* https://github.com/commonmark/cmark/issues/284\n* https://github.com/commonmark/cmark/issues/218\n* https://github.com/commonmark/cmark/pull/232\n* https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L63-L65\n* https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L87-L89",
"id": "GHSA-8hqf-xjwp-p67v",
"modified": "2023-03-28T23:08:31Z",
"published": "2023-03-28T14:40:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kivikakk/comrak/security/advisories/GHSA-8hqf-xjwp-p67v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28626"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/389"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/388"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/373"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/299"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/284"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/255"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/issues/218"
},
{
"type": "WEB",
"url": "https://github.com/commonmark/cmark/pull/232"
},
{
"type": "WEB",
"url": "https://github.com/kivikakk/comrak/commit/ce795b7f471b01589f842dc09af38b025701178d"
},
{
"type": "WEB",
"url": "https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L63-L65"
},
{
"type": "WEB",
"url": "https://github.com/github/cmark-gfm/blob/c32ef78bae851cb83b7ad52d0fbff880acdcd44a/test/pathological_tests.py#L87-L89"
},
{
"type": "PACKAGE",
"url": "https://github.com/kivikakk/comrak"
},
{
"type": "WEB",
"url": "https://github.com/kivikakk/comrak/releases/tag/0.17.0"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OUYME2VA555X6567H7ORIJQFN4BVGT6N"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PTWZWCT7KCX2KTXTLPUYZ3EHOONG4X46"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VQ3UBC7LE4VPCMZBTADIBL353CH7CPVV"
}
],
"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": "Comrak vulnerable to quadratic runtime issues when parsing Markdown (GHSL-2023-047)"
}
GHSA-8HRX-GGWF-CJF9
Vulnerability from github – Published: 2026-09-15 21:32 – Updated: 2026-09-15 21:32Vulnerability in the Oracle Depot Repair product of Oracle E-Business Suite (component: Recall Management). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Depot Repair. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Depot Repair accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Depot Repair. CVSS 3.1 Base Score 7.1 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L).
{
"affected": [],
"aliases": [
"CVE-2026-83436"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T20:18:52Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Depot Repair product of Oracle E-Business Suite (component: Recall Management). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Depot Repair. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Depot Repair accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Depot Repair. CVSS 3.1 Base Score 7.1 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L).",
"id": "GHSA-8hrx-ggwf-cjf9",
"modified": "2026-09-15T21:32:39Z",
"published": "2026-09-15T21:32:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83436"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cspusep2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8HXH-R6F7-JF45
Vulnerability from github – Published: 2020-10-16 17:03 – Updated: 2021-10-04 21:26Impact
A server we connect to with http4s-async-http-client could theoretically respond with a large or malicious compressed stream and exhaust memory in the client JVM. It does not affect http4s servers, other client backends, or clients that speak only to trusted servers. This is related to a transitive dependency on netty-codec-4.1.45.Final, which is affected by CVE-2020-11612.
Patches
Upgrade to http4s-async-http-client >= 0.21.8. All 1.0 milestones are also safe.
Workarounds
Add an explicit runtime dependency on async-http-client's netty dependencies that evicts them to an unaffected version:
libraryDependencies ++= Seq(
"io.netty" % "netty-codec" % "4.1.53.Final" % Runtime,
"io.netty" % "netty-codec-socks" % "4.1.53.Final" % Runtime,
"io.netty" % "netty-handler-proxy" % "4.1.53.Final" % Runtime,
"io.netty" % "netty-common" % "4.1.53.Final" % Runtime,
"io.netty" % "netty-transport" % "4.1.53.Final" % Runtime,
"io.netty" % "netty-handler" % "4.1.53.Final" % Runtime,
"io.netty" % "netty-resolver-dns" % "4.1.53.Final" % Runtime
)
References
- https://app.snyk.io/vuln/SNYK-JAVA-IONETTY-564897
- https://github.com/http4s/http4s/issues/3681
For more information
If you have any questions or comments about this advisory: * Open an issue in http4s * Contact a maintainer privately per http4s' security policy
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.21.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-async-http-client_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.21.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.21.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-async-http-client_2.12"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.21.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-10-16T17:03:18Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nA server we connect to with http4s-async-http-client could theoretically respond with a large or malicious compressed stream and exhaust memory in the client JVM. It does not affect http4s servers, other client backends, or clients that speak only to trusted servers. This is related to a transitive dependency on netty-codec-4.1.45.Final, which is affected by [CVE-2020-11612](https://app.snyk.io/vuln/SNYK-JAVA-IONETTY-564897).\n\n### Patches\nUpgrade to http4s-async-http-client \u003e= 0.21.8. All 1.0 milestones are also safe.\n\n### Workarounds\nAdd an explicit runtime dependency on async-http-client\u0027s netty dependencies that evicts them to an unaffected version:\n\n```scala\nlibraryDependencies ++= Seq(\n \"io.netty\" % \"netty-codec\" % \"4.1.53.Final\" % Runtime,\n \"io.netty\" % \"netty-codec-socks\" % \"4.1.53.Final\" % Runtime,\n \"io.netty\" % \"netty-handler-proxy\" % \"4.1.53.Final\" % Runtime,\n \"io.netty\" % \"netty-common\" % \"4.1.53.Final\" % Runtime,\n \"io.netty\" % \"netty-transport\" % \"4.1.53.Final\" % Runtime,\n \"io.netty\" % \"netty-handler\" % \"4.1.53.Final\" % Runtime,\n \"io.netty\" % \"netty-resolver-dns\" % \"4.1.53.Final\" % Runtime\n)\n```\n\n### References\n* https://app.snyk.io/vuln/SNYK-JAVA-IONETTY-564897\n* https://github.com/http4s/http4s/issues/3681\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [http4s](https://github.com/http4s/http4s/issues/new)\n* Contact a maintainer privately per [http4s\u0027 security policy](https://github.com/http4s/http4s/blob/master/SECURITY.md#reporting-a-vulnerability)",
"id": "GHSA-8hxh-r6f7-jf45",
"modified": "2021-10-04T21:26:20Z",
"published": "2020-10-16T17:03:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/security/advisories/GHSA-8hxh-r6f7-jf45"
},
{
"type": "PACKAGE",
"url": "https://github.com/http4s/http4s"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Memory exhaustion in http4s-async-http-client with large or malicious compressed responses"
}
GHSA-8J3G-F24P-4MPW
Vulnerability from github – Published: 2026-07-15 22:05 – Updated: 2026-08-17 16:15Impact
If this library is used to implement a WebSocket server on top of a TCP server (rather than an HTTP server or framework) using the WebSocket::Driver.server() method, or, if it is used to complement a WebSocket client, then a peer can make a single connection consume an unbounded amount of memory by sending an HTTP request or response with a never-ending list of headers. This can lead to the receiving process running out of memory.
Patches
The issue has been patched in version 0.8.1, by limiting the total size of HTTP request/response lines and headers accepted by the parser to 32 kB. All users should upgrade to this version.
Workarounds
No known workarounds exist.
Acknowledgements
This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "websocket-driver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54465"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T22:05:39Z",
"nvd_published_at": "2026-07-17T20:17:26Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nIf this library is used to implement a WebSocket server on top of a TCP server (rather than an HTTP server or framework) using the `WebSocket::Driver.server()` method, or, if it is used to complement a WebSocket client, then a peer can make a single connection consume an unbounded amount of memory by sending an HTTP request or response with a never-ending list of headers. This can lead to the receiving process running out of memory.\n\n### Patches\n\nThe issue has been patched in version 0.8.1, by limiting the total size of HTTP request/response lines and headers accepted by the parser to 32 kB. All users should upgrade to this version.\n\n### Workarounds\n\nNo known workarounds exist.\n\n### Acknowledgements\n\nThis issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.",
"id": "GHSA-8j3g-f24p-4mpw",
"modified": "2026-08-17T16:15:30Z",
"published": "2026-07-15T22:05:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/faye/websocket-driver-ruby/security/advisories/GHSA-8j3g-f24p-4mpw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54465"
},
{
"type": "WEB",
"url": "https://github.com/faye/websocket-driver-ruby/commit/17b569f232896e71d458404ccf4854f80e987710"
},
{
"type": "PACKAGE",
"url": "https://github.com/faye/websocket-driver-ruby"
},
{
"type": "WEB",
"url": "https://github.com/faye/websocket-driver-ruby/releases/tag/0.8.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/websocket-driver/CVE-2026-54465.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54465"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "websocket-driver: Memory exhaustion in HTTP header parser"
}
GHSA-8J4C-6X6G-RQ3J
Vulnerability from github – Published: 2026-10-08 19:40 – Updated: 2026-10-08 19:40Summary
DsfParser.parseChunks skips an unrecognised chunk's payload with an un-awaited call:
this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); // lib/dsf/DsfParser.js:51 — no await
ChunkHeader.len is 12. A crafted .dsf chunk with id != 'fmt ' and size in 0..11 makes the
argument negative; strtok3 (≥ 10.3.5) throws RangeError on a negative ignore. Because the call
is fire-and-forget, the rejection is detached from the parseBuffer() promise chain → unhandled
rejection → Node's default (≥ 15) crashes the process — after parseBuffer() already
resolved, so a caller's try/catch catches nothing and is still taken down.
Residual of GHSA-v6c2-xwv6-8xf7: the ASF site was fixed in 11.12.3 (size validation) and strtok3
now throws on negative ignore; the DSF site was never validated, and its missing await
escalates that throw into an uncatchable crash.
Root cause (lib/dsf/DsfParser.js:34-56)
while (bytesRemaining >= ChunkHeader.len) { // ChunkHeader.len = 12
const chunkHeader = await this.tokenizer.readToken(ChunkHeader); // { id, size }
switch (chunkHeader.id) {
case 'fmt ': { ...; return; }
default: this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); break; // size<12 -> negative, no await
}
bytesRemaining -= chunkHeader.size;
}
strtok3 AbstractTokenizer.ignore (L78-79): if (length < 0) throw new RangeError('ignore length must be ≥ 0 bytes');
Steps to reproduce
repro/ — public API only, Node's default unhandled-rejection mode, try/catch around the parse:
npm install && node poc.mjs
Confirmed on 11.14.0:
[app] parseBuffer() RESOLVED — the caller saw no error to catch.
RangeError: ignore length must be ≥ 0 bytes
at DsfParser.parseChunks (.../lib/dsf/DsfParser.js:51)
<process exits non-zero — the "process survived" line never prints>
Impact
DoS: a single crafted .dsf (or any file with the DSD magic) crashes the Node process of any
app parsing untrusted audio with music-metadata (2.2M weekly downloads). The crash bypasses the
caller's error handling, so even apps that correctly try/catch per-file parsing are killed — one
malicious upload can take down a shared server/worker.
Remediation
Add await on line 51 (makes the RangeError a catchable parse error), and validate
chunkHeader.size >= ChunkHeader.len before the skip (as the ASF fix did; also guards the loop
counter). Audit other parsers for un-awaited tokenizer.ignore()/readToken().
Scope / honesty
Requires the DSF path (a DSD-magic file — normal auto-detection). Relies on Node's default
unhandled-rejection mode (throw, default since Node 15); the point is that the standard defensive
per-parse try/catch does not protect against it. Crash (availability), not disclosure/RCE.
Negatives confirmed alongside: ASF infinite loop fixed; negative-ignore infinite-loop class
closed at strtok3; unbounded allocation bounded by strtok3's read bound-check.
Credits
Issue also reported by @ryu7eroo
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.14.0"
},
"package": {
"ecosystem": "npm",
"name": "music-metadata"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107392"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T19:40:45Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n`DsfParser.parseChunks` skips an unrecognised chunk\u0027s payload with an **un-awaited** call:\n```js\nthis.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); // lib/dsf/DsfParser.js:51 \u2014 no await\n```\n`ChunkHeader.len` is 12. A crafted `.dsf` chunk with `id != \u0027fmt \u0027` and `size` in `0..11` makes the\nargument negative; strtok3 (\u2265 10.3.5) throws `RangeError` on a negative `ignore`. Because the call\nis fire-and-forget, the rejection is **detached from the `parseBuffer()` promise chain** \u2192 unhandled\nrejection \u2192 Node\u0027s default (\u2265 15) **crashes the process** \u2014 **after** `parseBuffer()` already\nresolved, so a caller\u0027s `try/catch` catches nothing and is still taken down.\n\nResidual of GHSA-v6c2-xwv6-8xf7: the ASF site was fixed in 11.12.3 (size validation) and strtok3\nnow throws on negative `ignore`; the DSF site was never validated, and its missing `await`\nescalates that throw into an **uncatchable** crash.\n\n## Root cause (`lib/dsf/DsfParser.js:34-56`)\n```js\nwhile (bytesRemaining \u003e= ChunkHeader.len) { // ChunkHeader.len = 12\n const chunkHeader = await this.tokenizer.readToken(ChunkHeader); // { id, size }\n switch (chunkHeader.id) {\n case \u0027fmt \u0027: { ...; return; }\n default: this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); break; // size\u003c12 -\u003e negative, no await\n }\n bytesRemaining -= chunkHeader.size;\n}\n```\nstrtok3 `AbstractTokenizer.ignore` (L78-79): `if (length \u003c 0) throw new RangeError(\u0027ignore length must be \u2265 0 bytes\u0027);`\n\n## Steps to reproduce\n`repro/` \u2014 public API only, Node\u0027s default unhandled-rejection mode, `try/catch` around the parse:\n```\nnpm install \u0026\u0026 node poc.mjs\n```\nConfirmed on 11.14.0:\n```\n[app] parseBuffer() RESOLVED \u2014 the caller saw no error to catch.\nRangeError: ignore length must be \u2265 0 bytes\n at DsfParser.parseChunks (.../lib/dsf/DsfParser.js:51)\n \u003cprocess exits non-zero \u2014 the \"process survived\" line never prints\u003e\n```\n\n## Impact\nDoS: a single crafted `.dsf` (or any file with the `DSD ` magic) crashes the Node process of any\napp parsing untrusted audio with music-metadata (2.2M weekly downloads). The crash bypasses the\ncaller\u0027s error handling, so even apps that correctly `try/catch` per-file parsing are killed \u2014 one\nmalicious upload can take down a shared server/worker.\n\n## Remediation\nAdd `await` on line 51 (makes the `RangeError` a catchable parse error), and validate\n`chunkHeader.size \u003e= ChunkHeader.len` before the skip (as the ASF fix did; also guards the loop\ncounter). Audit other parsers for un-awaited `tokenizer.ignore()`/`readToken()`.\n\n## Scope / honesty\nRequires the DSF path (a `DSD `-magic file \u2014 normal auto-detection). Relies on Node\u0027s default\nunhandled-rejection mode (`throw`, default since Node 15); the point is that the standard defensive\nper-parse `try/catch` does not protect against it. Crash (availability), not disclosure/RCE.\nNegatives confirmed alongside: ASF infinite loop fixed; negative-`ignore` infinite-loop class\nclosed at strtok3; unbounded allocation bounded by strtok3\u0027s read bound-check.\n\n## Credits\nIssue also reported by @ryu7eroo",
"id": "GHSA-8j4c-6x6g-rq3j",
"modified": "2026-10-08T19:40:45Z",
"published": "2026-10-08T19:40:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-8j4c-6x6g-rq3j"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/pull/2700"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/commit/e7fc27a96e789d41ece41fdac590fc7618274a41"
},
{
"type": "PACKAGE",
"url": "https://github.com/Borewit/music-metadata"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/releases/tag/v11.15.0"
}
],
"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"
}
],
"summary": "music-metadata: uncatchable process crash parsing a crafted `.dsf` (residual of GHSA-v6c2-xwv6-8xf7)"
}
GHSA-8J4W-5FW4-RM27
Vulnerability from github – Published: 2019-08-27 17:45 – Updated: 2021-08-17 22:18Versions of deeply prior to 1.0.1 are vulnerable to Prototype Pollution. The package fails to validate which Object properties it updates. This allows attackers to modify the prototype of Object, causing the addition or modification of an existing property on all objects.
Recommendation
Upgrade to version 3.1.0 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "deeply"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10750"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2019-08-27T17:28:49Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "Versions of `deeply` prior to 1.0.1 are vulnerable to Prototype Pollution. The package fails to validate which Object properties it updates. This allows attackers to modify the prototype of Object, causing the addition or modification of an existing property on all objects.\n\n\n\n\n## Recommendation\n\nUpgrade to version 3.1.0 or later.",
"id": "GHSA-8j4w-5fw4-rm27",
"modified": "2021-08-17T22:18:25Z",
"published": "2019-08-27T17:45:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10750"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-DEEPLY-451026"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/1030"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Prototype Pollution in deeply"
}
GHSA-8J5H-HQQM-4PFR
Vulnerability from github – Published: 2026-09-26 21:30 – Updated: 2026-09-26 21:30Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead denial of service via Excessive Allocation (CAPEC-130)
{
"affected": [],
"aliases": [
"CVE-2026-94398"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-26T21:16:56Z",
"severity": "MODERATE"
},
"details": "Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead denial of service via Excessive Allocation (CAPEC-130)",
"id": "GHSA-8j5h-hqqm-4pfr",
"modified": "2026-09-26T21:30:28Z",
"published": "2026-09-26T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94398"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-179/390683"
}
],
"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"
}
]
}
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.