Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

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

5568 vulnerabilities reference this CWE, most recent first.

GHSA-J7JJ-549C-J492

Vulnerability from github – Published: 2026-07-10 18:32 – Updated: 2026-07-13 21:31
VLAI
Details

An unauthenticated attacker can repeatedly call Grafana's OAuth login route with unique values, causing unbounded memory growth that can eventually exhaust memory and crash the Grafana instance (denial of service).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-8609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-10T16:16:39Z",
    "severity": "MODERATE"
  },
  "details": "An unauthenticated attacker can repeatedly call Grafana\u0027s OAuth login route with unique values, causing unbounded memory growth that can eventually exhaust memory and crash the Grafana instance (denial of service).",
  "id": "GHSA-j7jj-549c-j492",
  "modified": "2026-07-13T21:31:16Z",
  "published": "2026-07-10T18:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8609"
    },
    {
      "type": "WEB",
      "url": "https://grafana.com/security/security-advisories/cve-2026-8609"
    }
  ],
  "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"
    }
  ]
}

GHSA-J7JW-28JM-WHR6

Vulnerability from github – Published: 2025-02-21 21:43 – Updated: 2025-02-21 21:43
VLAI
Summary
lakeFS allows an authenticated user to cause a crash by exhausting server memory
Details

Impact

An authenticated user can crash lakeFS by exhausting server memory. This is an authenticated denial-of-service issue.

Patches

This problem has been patched and exists in versions 1.49.1 and below

Workarounds

On S3 backends, configure

# ...
blockstore:
  s3:
    disable_pre_signed_multipart: true

or set environment variable LAKEFS_BLOCKSTORE_S3_DISABLE_PRE_SIGNED_MULTIPART to true.

References

Are there any links users can visit to find out more?

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/treeverse/lakefs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.50.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27100"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-21T21:43:16Z",
    "nvd_published_at": "2025-02-21T00:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn authenticated user can crash lakeFS by exhausting server memory.  This is an authenticated denial-of-service issue.\n\n### Patches\nThis problem has been patched and exists in versions 1.49.1 and below\n\n### Workarounds\n\nOn S3 backends, configure\n```yaml\n# ...\nblockstore:\n  s3:\n    disable_pre_signed_multipart: true\n```\nor set environment variable `LAKEFS_BLOCKSTORE_S3_DISABLE_PRE_SIGNED_MULTIPART` to `true`.\n\n### References\n_Are there any links users can visit to find out more?_",
  "id": "GHSA-j7jw-28jm-whr6",
  "modified": "2025-02-21T21:43:16Z",
  "published": "2025-02-21T21:43:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/treeverse/lakeFS/security/advisories/GHSA-j7jw-28jm-whr6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27100"
    },
    {
      "type": "WEB",
      "url": "https://github.com/treeverse/lakeFS/commit/3a625752acdf3f8e137bec20451e71d0f9fa82f2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/treeverse/lakeFS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lakeFS allows an authenticated user to cause a crash by exhausting server memory"
}

GHSA-J7MW-RCXC-J56C

Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-06-22 18:34
VLAI
Details

IBM WebSphere Application Server 9.0, and 8.5 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.6 are vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-9320"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-22T16:16:43Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Application Server 9.0, and 8.5 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.6 are vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.",
  "id": "GHSA-j7mw-rcxc-j56c",
  "modified": "2026-06-22T18:34:16Z",
  "published": "2026-06-22T18:34:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9320"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7276579"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J7QP-MFXF-8XJW

Vulnerability from github – Published: 2022-12-07 23:13 – Updated: 2023-02-14 21:25
VLAI
Summary
libp2p DoS vulnerability from lack of resource management
Details

Impact

Versions older than v0.18.0 of go-libp2p are vulnerable to targeted resource exhaustion attacks. These attacks target libp2p’s connection, stream, peer, and memory management. An attacker can cause the allocation of large amounts of memory, ultimately leading to the process getting killed by the host’s operating system. While a connection manager tasked with keeping the number of connections within manageable limits has been part of go-libp2p, this component was designed to handle the regular churn of peers, not a targeted resource exhaustion attack.

In the original version of the attack, the malicious node would continue opening new streams on a stream multiplexer that doesn’t provide sufficient back pressure (yamux or mplex). It is easy to defend against this one attack, but there are countless variations of this attack: * Opening streams and causing a non-trivial memory allocation (e.g., for multistream or protobuf parsing) * Creating a lot of sybil nodes and opening new connections across nodes

Patches (What to do as a go-libp2p consumer:)

  1. Update your go-libp2p dependency to go-libp2p v0.18.0 or greater (current version as of publish date is v0.24.0.)

    • Note: It's recommend that you update to v0.21.0 onwards as you’ll get some useful functionality that will help in production environments like better metrics around resource usage, Grafana dashboards around resource usage, allow list support, and default autoscaling limits. Please see the v0.21.0 release notes for more info.)
  2. Determine appropriate limits for your application - go-libp2p sets up a resource manager with the default limits if none are provided. For default definitions please see limits_defaults.go. These limits are also set to automatically scale, this is done using the AutoScale method of the ScalingLimitConfig. We recommend you tune your limits as described here.

  3. Configure your node to be attack resilient. See how to respond to an attack and identify misbehaving peers here. Then setup automatic blocking with fail2ban using canonical libp2p log lines: guide on how to do so here.

Examples

  • Lotus’ integration can be found in https://github.com/filecoin-project/lotus/blob/master/node/modules/lp2p/rcmgr.go. Lotus reads user-configured resource limits from a limits.json file into the root directory. This allows users to share their resource manager configuration independent of any other configurations.
  • Kubo’s (formerly go-ipfs) integration can be found in https://github.com/ipfs/go-ipfs/blob/master/core/node/libp2p/rcmgr.go. Kubo reads the limits from the IPFS config file.

Note: go-libp2p still implements the connection manager mentioned above. The connection manager is a component independent of the resource manager, which aims to keep the number of libp2p connections between a low and a high watermark. When modifying connection limits, it’s advantageous to keep the configuration of these components consistent, i.e., when setting a limit of N concurrent connections in the resource manager, the high watermark should be at most (and ideally slightly less) than N.

Workarounds

Although there are no workarounds within go-libp2p, some range of attacks can be mitigated using OS tools (like manually blocking malicious peers using iptables or ufw ) or making use of a load balancer in front of libp2p nodes.

However these require direct action & responsibility on your part and are no substitutes for upgrading go-libp2p. Therefore, we highly recommend upgrading your go-libp2p version for the way it enables tighter scoped limits and provides visibility into and easier reasoning about go-libp2p resource utilization.

References

Please see our DoS Mitigation page for more information on how to incorporate mitigation strategies, monitor your application, and respond to attacks: https://docs.libp2p.io/reference/dos-mitigation/.

Please see the related disclosure for rust-libp2p: https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-jvgw-gccv-q5p8 and js-libp2p: https://github.com/libp2p/js-libp2p/security/advisories/GHSA-f44q-634c-jvwv

For more information

If you have any questions or comments about this advisory email us at security@libp2p.io

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/libp2p/go-libp2p"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23492"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-07T23:13:02Z",
    "nvd_published_at": "2022-12-08T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nVersions older than `v0.18.0` of go-libp2p are vulnerable to targeted resource exhaustion attacks. These attacks target libp2p\u2019s connection, stream, peer, and memory management. An attacker can cause the allocation of large amounts of memory, ultimately leading to the process getting killed by the host\u2019s operating system. While a connection manager tasked with keeping the number of connections within manageable limits has been part of go-libp2p, this component was designed to handle the regular churn of peers, not a targeted resource exhaustion attack.\n\nIn the original version of the attack, the malicious node would continue opening new streams on a stream multiplexer that doesn\u2019t provide sufficient back pressure (yamux or mplex). It is easy to defend against this one attack, but there are countless variations of this attack:\n* Opening streams and causing a non-trivial memory allocation (e.g., for multistream or protobuf parsing)\n* Creating a lot of sybil nodes and opening new connections across nodes\n\n### Patches (What to do as a go-libp2p consumer:)\n1. Update your go-libp2p dependency to go-libp2p v0.18.0 or greater (current version as of publish date is [v0.24.0](https://github.com/libp2p/go-libp2p/releases/tag/v0.24.0).)\n    - Note: **It\u0027s recommend that you update to `v0.21.0` onwards** as you\u2019ll get some useful functionality that will help in production environments like better metrics around resource usage, Grafana dashboards around resource usage, allow list support, and default autoscaling limits. [Please see the v0.21.0 release notes for more info.](https://github.com/libp2p/go-libp2p/releases/tag/v0.21.0))\n\n2. Determine appropriate limits for your application - go-libp2p sets up a resource manager with the default limits if none are provided. For default definitions please see [limits_defaults.go](https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/limit_defaults.go). These limits are also set to automatically scale, this is done using the [AutoScale method of the ScalingLimitConfig](https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/README.md#scaling-limits). We recommend you [tune your limits as described here](https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/README.md#how-to-tune-your-limits).\n\n3. Configure your node to be attack resilient. See [how to respond to an attack and identify misbehaving peers here](https://docs.libp2p.io/concepts/security/dos-mitigation/#responding-to-an-attack). Then setup automatic blocking with fail2ban using canonical libp2p log lines: [guide on how to do so here](https://docs.libp2p.io/concepts/security/dos-mitigation/#how-to-automate-blocking-with-fail2ban).\n\n#### Examples\n* Lotus\u2019 integration can be found in https://github.com/filecoin-project/lotus/blob/master/node/modules/lp2p/rcmgr.go. Lotus reads user-configured resource limits from a limits.json file into the root directory. This allows users to share their resource manager configuration independent of any other configurations.\n* Kubo\u2019s (formerly go-ipfs) integration can be found in https://github.com/ipfs/go-ipfs/blob/master/core/node/libp2p/rcmgr.go. Kubo reads the limits from the IPFS config file.\n\n**Note:** go-libp2p still implements the [connection manager](https://github.com/libp2p/go-libp2p/tree/master/p2p/net/connmgr) mentioned above. The connection manager is a component independent of the resource manager, which aims to keep the number of libp2p connections between a low and a high watermark. When modifying connection limits, it\u2019s advantageous to keep the configuration of these components consistent, i.e., when setting a limit of N concurrent connections in the resource manager, the high watermark should be at most (and ideally slightly less) than N.\n\n### Workarounds\nAlthough there are no workarounds within go-libp2p, some range of attacks can be mitigated using OS tools (like manually blocking malicious peers using `iptables` or `ufw` ) or making use of a load balancer in front of libp2p nodes.\n\nHowever these require direct action \u0026 responsibility on your part and are no substitutes for upgrading go-libp2p. Therefore, we highly recommend upgrading your go-libp2p version for the way it enables tighter scoped limits and provides visibility into and easier reasoning about go-libp2p resource utilization.\n\n### References\nPlease see our DoS Mitigation page for more information on how to incorporate mitigation strategies, monitor your application, and respond to attacks: https://docs.libp2p.io/reference/dos-mitigation/. \n\nPlease see the related disclosure for rust-libp2p: https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-jvgw-gccv-q5p8 and js-libp2p: https://github.com/libp2p/js-libp2p/security/advisories/GHSA-f44q-634c-jvwv\n\n#### For more information\n\nIf you have any questions or comments about this advisory email us at [security@libp2p.io](mailto:security@libp2p.io)",
  "id": "GHSA-j7qp-mfxf-8xjw",
  "modified": "2023-02-14T21:25:56Z",
  "published": "2022-12-07T23:13:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/go-libp2p/security/advisories/GHSA-j7qp-mfxf-8xjw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/security/advisories/GHSA-f44q-634c-jvwv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-jvgw-gccv-q5p8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23492"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/go-libp2p/commit/15d7dfbf54264ead8e6f49ca658d79c90635e2de"
    },
    {
      "type": "WEB",
      "url": "https://docs.libp2p.io/reference/dos-mitigation"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/go-libp2p"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2022-1148"
    }
  ],
  "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": "libp2p DoS vulnerability from lack of resource management"
}

GHSA-J7X9-7J54-2V3H

Vulnerability from github – Published: 2026-02-02 12:31 – Updated: 2026-02-02 22:07
VLAI
Summary
Hugging Face Text Generation Inference vulnerable to Uncontrolled Resource Consumption
Details

A vulnerability in huggingface/text-generation-inference version 3.3.6 allows unauthenticated remote attackers to exploit unbounded external image fetching during input validation in VLM mode. The issue arises when the router scans inputs for Markdown image links and performs a blocking HTTP GET request, reading the entire response body into memory and cloning it before decoding. This behavior can lead to resource exhaustion, including network bandwidth saturation, memory inflation, and CPU overutilization. The vulnerability is triggered even if the request is later rejected for exceeding token limits. The default deployment configuration, which lacks memory usage limits and authentication, exacerbates the impact, potentially crashing the host machine. The issue is resolved in version 3.3.7.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "text-generation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-0599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-02T22:07:41Z",
    "nvd_published_at": "2026-02-02T11:16:17Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in huggingface/text-generation-inference version 3.3.6 allows unauthenticated remote attackers to exploit unbounded external image fetching during input validation in VLM mode. The issue arises when the router scans inputs for Markdown image links and performs a blocking HTTP GET request, reading the entire response body into memory and cloning it before decoding. This behavior can lead to resource exhaustion, including network bandwidth saturation, memory inflation, and CPU overutilization. The vulnerability is triggered even if the request is later rejected for exceeding token limits. The default deployment configuration, which lacks memory usage limits and authentication, exacerbates the impact, potentially crashing the host machine. The issue is resolved in version 3.3.7.",
  "id": "GHSA-j7x9-7j54-2v3h",
  "modified": "2026-02-02T22:07:41Z",
  "published": "2026-02-02T12:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0599"
    },
    {
      "type": "WEB",
      "url": "https://github.com/huggingface/text-generation-inference/commit/24ee40d143d8d046039f12f76940a85886cbe152"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/huggingface/text-generation-inference"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/1d3f2085-666c-4441-b265-22f6f7d8d9cd"
    }
  ],
  "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"
    }
  ],
  "summary": "Hugging Face Text Generation Inference vulnerable to Uncontrolled Resource Consumption"
}

GHSA-J8G9-RVG7-2X7W

Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2022-12-15 06:30
VLAI
Details

In NotificationChannel of NotificationChannel.java, there is a possible failure to persist permissions settings due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-241764340

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-13T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "In NotificationChannel of NotificationChannel.java, there is a possible failure to persist permissions settings due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-241764340",
  "id": "GHSA-j8g9-rvg7-2x7w",
  "modified": "2022-12-15T06:30:30Z",
  "published": "2022-12-13T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20479"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2022-12-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J8HF-P5V4-XPJ9

Vulnerability from github – Published: 2025-04-29 03:30 – Updated: 2025-04-29 15:31
VLAI
Details

The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may cause an unexpected app termination.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-29T03:15:34Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may cause an unexpected app termination.",
  "id": "GHSA-j8hf-p5v4-xpj9",
  "modified": "2025-04-29T15:31:51Z",
  "published": "2025-04-29T03:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31197"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122371"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122372"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122373"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122374"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122375"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122377"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122378"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J8JP-C763-RC6R

Vulnerability from github – Published: 2026-04-06 21:31 – Updated: 2026-04-07 15:30
VLAI
Details

An issue was discovered in NAS in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Incorrect Handling of a DL NAS Transport packet leads to a Denial of Service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-54324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-06T19:16:26Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in NAS in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Incorrect Handling of a DL NAS Transport packet leads to a Denial of Service.",
  "id": "GHSA-j8jp-c763-rc6r",
  "modified": "2026-04-07T15:30:46Z",
  "published": "2026-04-06T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54324"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates/cve-2025-54324"
    }
  ],
  "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-J8M5-M975-227F

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

The Integration Builder Framework of SAP Process Integration versions - 7.10, 7.11, 7.20, 7.30, 7.31, 7.40, 7.50, does not sufficiently validate an XML document uploaded from local source. An attacker can craft a malicious XML which when uploaded and parsed by the application, could lead to Denial-of-service conditions due to consumption of a large amount of system memory, thus highly impacting system availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-27617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-11T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Integration Builder Framework of SAP Process Integration versions - 7.10, 7.11, 7.20, 7.30, 7.31, 7.40, 7.50, does not sufficiently validate an XML document uploaded from local source. An attacker can craft a malicious XML which when uploaded and parsed by the application, could lead to Denial-of-service conditions due to consumption of a large amount of system memory, thus highly impacting system availability.",
  "id": "GHSA-j8m5-m975-227f",
  "modified": "2022-06-29T00:00:49Z",
  "published": "2022-05-24T19:02:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27617"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3012021"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=576094655"
    }
  ],
  "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-J8PH-6FXJ-G533

Vulnerability from github – Published: 2026-07-02 20:30 – Updated: 2026-07-02 20:30
VLAI
Summary
Steeltoe.Discovery.Eureka: Unrecognized DataCenterInfo.Name poisons entire registry fetch
Details

Summary

DataCenterInfo.FromJson throws ArgumentException for any name value other than "MyOwn" or "Amazon", despite the Java Eureka specification defining a third valid value: "Netflix". The exception propagates through the entire registry deserialization chain and is swallowed by the periodic cache refresh task, leaving the local service registry permanently empty or stale.

Impact

Any registration with an unrecognized DataCenterInfo.name permanently disables service discovery for every Steeltoe Eureka client connected to the same registry. New clients start with an empty registry and running clients stop refreshing. The outage persists until the triggering registration is removed.

Because "Netflix" is valid in the Java Eureka specification, a Java or Spring service in the same mesh can trigger this unintentionally.

Affected configuration

  • Application uses the Steeltoe Eureka client (EurekaDiscoveryClient).
  • The registry contains at least one registration with a DataCenterInfo.name value other than "MyOwn" or "Amazon".

Mitigations

If an immediate upgrade is not possible, remove any registrations using unsupported DataCenterInfo.name values from the registry. In mixed Java/Spring and Steeltoe environments, audit for the Netflix data center type before deploying Steeltoe Eureka clients.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Steeltoe.Discovery.Eureka"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.3.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Steeltoe.Discovery.Eureka"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T20:30:03Z",
    "nvd_published_at": "2026-06-17T22:16:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`DataCenterInfo.FromJson` throws `ArgumentException` for any `name` value other than `\"MyOwn\"` or `\"Amazon\"`, despite the Java Eureka specification defining a third valid value: `\"Netflix\"`. The exception propagates through the entire registry deserialization chain and is swallowed by the periodic cache refresh task, leaving the local service registry permanently empty or stale.\n\n### Impact\n\nAny registration with an unrecognized `DataCenterInfo.name` permanently disables service discovery for every Steeltoe Eureka client connected to the same registry. New clients start with an empty registry and running clients stop refreshing. The outage persists until the triggering registration is removed.\n\nBecause `\"Netflix\"` is valid in the Java Eureka specification, a Java or Spring service in the same mesh can trigger this unintentionally.\n\n### Affected configuration\n\n- Application uses the Steeltoe Eureka client (`EurekaDiscoveryClient`).\n- The registry contains at least one registration with a `DataCenterInfo.name` value other than `\"MyOwn\"` or `\"Amazon\"`.\n\n### Mitigations\n\nIf an immediate upgrade is not possible, remove any registrations using unsupported `DataCenterInfo.name` values from the registry. In mixed Java/Spring and Steeltoe environments, audit for the `Netflix` data center type before deploying Steeltoe Eureka clients.",
  "id": "GHSA-j8ph-6fxj-g533",
  "modified": "2026-07-02T20:30:03Z",
  "published": "2026-07-02T20:30:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-j8ph-6fxj-g533"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50196"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SteeltoeOSS/Steeltoe/commit/b8ed8557bb595863e4f340051d16b26ba40a75f4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SteeltoeOSS/Steeltoe/commit/c34a7399e808d0d11dd977460e81df1f2722df28"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SteeltoeOSS/Steeltoe"
    }
  ],
  "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": "Steeltoe.Discovery.Eureka: Unrecognized DataCenterInfo.Name poisons entire registry fetch"
}

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.