CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6394 vulnerabilities reference this CWE, most recent first.
GHSA-GQ56-J6HH-XR2P
Vulnerability from github – Published: 2022-05-06 00:00 – Updated: 2022-05-13 00:00On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when a Real Time Streaming Protocol (RTSP) profile is configured on a virtual server, undisclosed traffic can cause an increase in Traffic Management Microkernel (TMM) resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated
{
"affected": [],
"aliases": [
"CVE-2022-28691"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-05T17:15:00Z",
"severity": "HIGH"
},
"details": "On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when a Real Time Streaming Protocol (RTSP) profile is configured on a virtual server, undisclosed traffic can cause an increase in Traffic Management Microkernel (TMM) resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
"id": "GHSA-gq56-j6hh-xr2p",
"modified": "2022-05-13T00:00:55Z",
"published": "2022-05-06T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28691"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K37155600"
}
],
"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-GQ97-QJ3M-VHJH
Vulnerability from github – Published: 2024-03-22 21:30 – Updated: 2024-03-22 21:30Uncontrolled resource consumption for some Intel(R) SPS firmware before version SPS_E5_06.01.04.002.0 may allow a privileged user to potentially enable denial of service via network access.
{
"affected": [],
"aliases": [
"CVE-2023-29153"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-14T14:15:49Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption for some Intel(R) SPS firmware before version SPS_E5_06.01.04.002.0 may allow a privileged user to potentially enable denial of service via network access.",
"id": "GHSA-gq97-qj3m-vhjh",
"modified": "2024-03-22T21:30:56Z",
"published": "2024-03-22T21:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29153"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240322-0005"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01003.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GQ9C-WMRM-5HVR
Vulnerability from github – Published: 2026-09-17 20:32 – Updated: 2026-09-17 20:32Summary
A malformed Smart Health Card (SHC) JWT with zip: "DEF" and an empty or truncated DEFLATE payload causes SHCParser.inflate() to loop forever. This allows an attacker who can submit SHC content for validation to pin a JVM worker thread indefinitely, causing denial of service.
Details
The vulnerable code is in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java.
decodeJWT() inflates the JWT payload when the header contains "zip":"DEF":
// SHCParser.java:300-302
if ("DEF".equals(res.header.asString("zip"))) {
payloadJson = inflate(payloadJson);
}
inflate() loops only on !inflater.finished() and does not check inflater.needsInput(), inflater.needsDictionary(), or zero-progress output:
// SHCParser.java:455-468
while (!inflater.finished()) {
final int count = inflater.inflate(buffer);
outputStream.write(buffer, 0, count);
}
For empty or truncated raw DEFLATE input, Inflater.inflate() returns 0, finished() remains false, and needsInput() becomes true, producing an infinite tight loop. The same unsafe loop pattern also exists in decompress() at SHCParser.java:410-423.
The validator reaches this path during SHC validation and during file-format detection for SHC-looking input (ResourceChecker.java:115-118).
PoC
Compile the project, then run a minimal local harness that calls:
SHCParser.inflate(new byte[0]);
This never returns. Local verification:
timeout 3s java -cp ... VerifyDoSFindings shcHang
echo $?
# 124 = timeout killed the hung process
A JWT PoC uses:
- header: Base64URL(
{"zip":"DEF"}) - payload: empty or truncated raw DEFLATE bytes
- signature: arbitrary
Submit the resulting token as SHC content, for example via a .shc file or content beginning with shc:/ that reaches the validator's SHC detection path.
Impact
This is a denial-of-service vulnerability. A single malformed SHC validation request can consume a worker thread indefinitely. In services that validate uploaded SHC content, a small number of concurrent malformed requests can exhaust all validation workers.
Credits
- Thai Son Dinh from VinSOC Labs (R&D)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.9.11"
},
"package": {
"ecosystem": "Maven",
"name": "ca.uhn.hapi.fhir:org.hl7.fhir.r5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.9.11"
},
"package": {
"ecosystem": "Maven",
"name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.9.11"
},
"package": {
"ecosystem": "Maven",
"name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-81876"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T20:32:21Z",
"nvd_published_at": "2026-09-16T19:17:44Z",
"severity": "HIGH"
},
"details": "### Summary\nA malformed Smart Health Card (SHC) JWT with `zip: \"DEF\"` and an empty or truncated DEFLATE payload causes `SHCParser.inflate()` to loop forever. This allows an attacker who can submit SHC content for validation to pin a JVM worker thread indefinitely, causing denial of service.\n\n### Details\nThe vulnerable code is in `org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java`.\n\n`decodeJWT()` inflates the JWT payload when the header contains `\"zip\":\"DEF\"`:\n\n```java\n// SHCParser.java:300-302\nif (\"DEF\".equals(res.header.asString(\"zip\"))) {\n payloadJson = inflate(payloadJson);\n}\n```\n\n`inflate()` loops only on `!inflater.finished()` and does not check `inflater.needsInput()`, `inflater.needsDictionary()`, or zero-progress output:\n\n```java\n// SHCParser.java:455-468\nwhile (!inflater.finished()) {\n final int count = inflater.inflate(buffer);\n outputStream.write(buffer, 0, count);\n}\n```\n\nFor empty or truncated raw DEFLATE input, `Inflater.inflate()` returns `0`, `finished()` remains `false`, and `needsInput()` becomes `true`, producing an infinite tight loop. The same unsafe loop pattern also exists in `decompress()` at `SHCParser.java:410-423`.\n\nThe validator reaches this path during SHC validation and during file-format detection for SHC-looking input (`ResourceChecker.java:115-118`).\n\n### PoC\nCompile the project, then run a minimal local harness that calls:\n\n```java\nSHCParser.inflate(new byte[0]);\n```\n\nThis never returns. Local verification:\n\n```bash\ntimeout 3s java -cp ... VerifyDoSFindings shcHang\necho $?\n# 124 = timeout killed the hung process\n```\n\nA JWT PoC uses:\n\n- header: Base64URL(`{\"zip\":\"DEF\"}`)\n- payload: empty or truncated raw DEFLATE bytes\n- signature: arbitrary\n\nSubmit the resulting token as SHC content, for example via a `.shc` file or content beginning with `shc:/` that reaches the validator\u0027s SHC detection path.\n\n### Impact\nThis is a denial-of-service vulnerability. A single malformed SHC validation request can consume a worker thread indefinitely. In services that validate uploaded SHC content, a small number of concurrent malformed requests can exhaust all validation workers.\n\n### Credits\n- Thai Son Dinh from VinSOC Labs (R\u0026D)",
"id": "GHSA-gq9c-wmrm-5hvr",
"modified": "2026-09-17T20:32:21Z",
"published": "2026-09-17T20:32:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-gq9c-wmrm-5hvr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81876"
},
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/pull/2493"
},
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/commit/d804558bd77372b1629e55a5b901cad3f5134cdc"
},
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/commit/edd5d8c139e669e39270785f08be7b63aefef24c"
},
{
"type": "PACKAGE",
"url": "https://github.com/hapifhir/org.hl7.fhir.core"
}
],
"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": "HAPI FHIR: SHCParser DEFLATE infinite loop causes denial of service"
}
GHSA-GQ9P-F254-H286
Vulnerability from github – Published: 2026-09-15 20:01 – Updated: 2026-09-15 20:01Summary
An unauthenticated peer can make Ember's HTTP/2 read loop hold 16 MiB of a single frame in memory on a connection where Ember advertised a 16 KiB limit. The declared length is readable from the frame's first 9 bytes, but it is not compared against SETTINGS_MAX_FRAME_SIZE until the whole payload has been read into a contiguous buffer. That is 1024x amplification per connection, bounded by the protocol's 24-bit length field rather than by any setting, and at the default maxConnections of 1024 it puts about 16 GiB of heap in reach.
Details
H2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:
val length = (bv(2) & 0xff) | ((bv(1) & 0xff) << 8) | ((bv(0) & 0xff) << 16)
if (bv.length >= 9 + length) {
readNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as "need more" and concatenates further socket reads into one accumulator until it is satisfied.
The only check of an inbound frame against the connection's own SETTINGS_MAX_FRAME_SIZE is in processFrame at H2Connection.scala:534, which cannot run until the frame is assembled. So the value that condemns the frame sits in the accumulator from byte 9 onward and is never consulted. A peer that declares 16777215 and dribbles the payload without finishing gets the same buffering with no reaction at all, since an incomplete frame never reaches processFrame.
RFC 9113 4.2 requires treating an oversized frame as a connection error and explicitly permits responding without reading the rest of the payload.
Impact
Uncontrolled resource consumption leading to unauthenticated remote denial of service by memory exhaustion.
- ember-server built .withHttp2: any peer able to open an HTTP/2 connection can trigger it. No authentication and no valid request, since the frame is rejected before it is associated with a stream, and the incomplete variant is never rejected.
- ember-client built .withHttp2 against a hostile origin: readLoop is shared, so the client side is symmetric. Reasoned from the shared code path, not reproduced.
- Not affected: HTTP/2 off, which is the default on both builders.
The overshoot is not configurable. It comes from the protocol's length field, not from Ember's limit, so tuning SETTINGS_MAX_FRAME_SIZE down does not reduce exposure, and withIdleTimeout does not apply because the read loop is making steady progress. Workarounds: leave HTTP/2 off, or terminate it at a proxy that enforces frame size and speak HTTP/1.1 to Ember.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.12"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-M47"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-M1"
},
{
"fixed": "1.0.0-M48"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-M47"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_3"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-M1"
},
{
"fixed": "1.0.0-M48"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88975"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T20:01:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAn unauthenticated peer can make Ember\u0027s HTTP/2 read loop hold 16 MiB of a single frame in memory on a connection where Ember advertised a 16 KiB limit. The declared length is readable from the frame\u0027s first 9 bytes, but it is not compared against SETTINGS_MAX_FRAME_SIZE until the whole payload has been read into a contiguous buffer. That is 1024x amplification per connection, bounded by the protocol\u0027s 24-bit length field rather than by any setting, and at the default maxConnections of 1024 it puts about 16 GiB of heap in reach.\n\n### Details\nH2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:\n\n```\nval length = (bv(2) \u0026 0xff) | ((bv(1) \u0026 0xff) \u003c\u003c 8) | ((bv(0) \u0026 0xff) \u003c\u003c 16)\nif (bv.length \u003e= 9 + length) {\n```\n\nreadNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as \"need more\" and concatenates further socket reads into one accumulator until it is satisfied.\n\nThe only check of an inbound frame against the connection\u0027s own SETTINGS_MAX_FRAME_SIZE is in processFrame at H2Connection.scala:534, which cannot run until the frame is assembled. So the value that condemns the frame sits in the accumulator from byte 9 onward and is never consulted. A peer that declares 16777215 and dribbles the payload without finishing gets the same buffering with no reaction at all, since an incomplete frame never reaches processFrame.\n\nRFC 9113 4.2 requires treating an oversized frame as a connection error and explicitly permits responding without reading the rest of the payload.\n\n### Impact\nUncontrolled resource consumption leading to unauthenticated remote denial of service by memory exhaustion.\n\n- ember-server built .withHttp2: any peer able to open an HTTP/2 connection can trigger it. No authentication and no valid request, since the frame is rejected before it is associated with a stream, and the incomplete variant is never rejected.\n- ember-client built .withHttp2 against a hostile origin: readLoop is shared, so the client side is symmetric. Reasoned from the shared code path, not reproduced.\n- Not affected: HTTP/2 off, which is the default on both builders.\n\nThe overshoot is not configurable. It comes from the protocol\u0027s length field, not from Ember\u0027s limit, so tuning SETTINGS_MAX_FRAME_SIZE down does not reduce exposure, and withIdleTimeout does not apply because the read loop is making steady progress. Workarounds: leave HTTP/2 off, or terminate it at a proxy that enforces frame size and speak HTTP/1.1 to Ember.",
"id": "GHSA-gq9p-f254-h286",
"modified": "2026-09-15T20:01:22Z",
"published": "2026-09-15T20:01:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/security/advisories/GHSA-gq9p-f254-h286"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/commit/87cf334fa3f608ef7d3eb359e71e037ba3336d29"
},
{
"type": "PACKAGE",
"url": "https://github.com/http4s/http4s"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/releases/tag/v0.23.37"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/releases/tag/v1.0.0-M48"
}
],
"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": "Http4s: Ember HTTP/2 buffers a frame\u0027s declared payload before checking SETTINGS_MAX_FRAME_SIZE"
}
GHSA-GQC7-GJGF-XVMG
Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-21251"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T18:15:42Z",
"severity": "HIGH"
},
"details": "Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability",
"id": "GHSA-gqc7-gjgf-xvmg",
"modified": "2025-01-14T18:32:03Z",
"published": "2025-01-14T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21251"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21251"
}
],
"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-GQC9-9F54-XC45
Vulnerability from github – Published: 2022-06-07 00:00 – Updated: 2022-06-14 00:00An issue has been discovered in GitLab CE/EE affecting all versions starting from 14.3 before 14.9.5, all versions starting from 14.10 before 14.10.4, all versions starting from 15.0 before 15.0.1. It may be possible for malicious group maintainers to add new members to a project within their group, through the REST API, even after their group owner enabled a setting to prevent members from being added to projects within that group.
{
"affected": [],
"aliases": [
"CVE-2022-1783"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-06T17:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 14.3 before 14.9.5, all versions starting from 14.10 before 14.10.4, all versions starting from 15.0 before 15.0.1. It may be possible for malicious group maintainers to add new members to a project within their group, through the REST API, even after their group owner enabled a setting to prevent members from being added to projects within that group.",
"id": "GHSA-gqc9-9f54-xc45",
"modified": "2022-06-14T00:00:28Z",
"published": "2022-06-07T00:00:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1783"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1472109"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1783.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/353121"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQHX-WXJR-RPHX
Vulnerability from github – Published: 2023-06-26 21:30 – Updated: 2024-09-16 15:32An unauthenticated denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.
{
"affected": [],
"aliases": [
"CVE-2023-2992"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-26T20:15:09Z",
"severity": "HIGH"
},
"details": "An unauthenticated \u00a0denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.",
"id": "GHSA-gqhx-wxjr-rphx",
"modified": "2024-09-16T15:32:44Z",
"published": "2023-06-26T21:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2992"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-127357"
}
],
"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-GQQ3-J944-F364
Vulnerability from github – Published: 2023-01-15 06:30 – Updated: 2025-04-07 18:30Mercedes-Benz XENTRY Retail Data Storage 7.8.1 allows remote attackers to cause a denial of service (device restart) via an unauthenticated API request. The attacker must be on the same network as the device.
{
"affected": [],
"aliases": [
"CVE-2023-23590"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-15T05:15:00Z",
"severity": "HIGH"
},
"details": "Mercedes-Benz XENTRY Retail Data Storage 7.8.1 allows remote attackers to cause a denial of service (device restart) via an unauthenticated API request. The attacker must be on the same network as the device.",
"id": "GHSA-gqq3-j944-f364",
"modified": "2025-04-07T18:30:33Z",
"published": "2023-01-15T06:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23590"
},
{
"type": "WEB",
"url": "https://b2bconnect.mercedes-benz.com/gb/workshop-solutions/diagnosis/retail-data-storage"
},
{
"type": "WEB",
"url": "https://medium.com/%40windsormoreira/xentry-retail-data-storage-v7-8-1-denial-of-service-cve-2023-23590-60b65f5fa358"
},
{
"type": "WEB",
"url": "https://medium.com/@windsormoreira/xentry-retail-data-storage-v7-8-1-denial-of-service-cve-2023-23590-60b65f5fa358"
}
],
"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-GQQP-9725-VWP7
Vulnerability from github – Published: 2026-01-07 18:30 – Updated: 2026-01-07 18:30An attacker with access to the system's internal network can cause a denial of service on the system by making two concurrent connections through the Telnet service.
{
"affected": [],
"aliases": [
"CVE-2026-22542"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-07T16:15:51Z",
"severity": "CRITICAL"
},
"details": "An attacker with access to the system\u0027s internal network can cause a denial of service on the system by making two concurrent connections through the Telnet service.",
"id": "GHSA-gqqp-9725-vwp7",
"modified": "2026-01-07T18:30:25Z",
"published": "2026-01-07T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22542"
},
{
"type": "WEB",
"url": "https://cds.thalesgroup.com/en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/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-GQR3-XC87-48W2
Vulnerability from github – Published: 2026-09-24 03:30 – Updated: 2026-09-24 03:30A weakness has been identified in kvcache-ai mooncake up to 0.3.12/0.3.14-rc1. Impacted is the function MasterService::GetReplicaListByRegex of the component Regular Expression Handler. Executing a manipulation can lead to allocation of resources. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-96764"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-24T01:16:59Z",
"severity": "LOW"
},
"details": "A weakness has been identified in kvcache-ai mooncake up to 0.3.12/0.3.14-rc1. Impacted is the function MasterService::GetReplicaListByRegex of the component Regular Expression Handler. Executing a manipulation can lead to allocation of resources. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-gqr3-xc87-48w2",
"modified": "2026-09-24T03:30:26Z",
"published": "2026-09-24T03:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96764"
},
{
"type": "WEB",
"url": "https://gist.github.com/yyymk/4699cc95ab9a559ee15a0fb798bd6c5d"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-96764"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/904607"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/409019"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/409019/cti"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/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"
}
]
}
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.