Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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

6465 vulnerabilities reference this CWE, most recent first.

GHSA-VJ49-J7RC-H54F

Vulnerability from github – Published: 2023-08-25 21:30 – Updated: 2023-09-01 17:35
VLAI
Summary
Esoteric YamlBeans XML Entity Expansion vulnerability
Details

An issue was discovered in Esoteric YamlBeans through 1.15. A crafted YAML document is able perform am XML Entity Expansion attack against YamlBeans YamlReader. By exploiting the Anchor feature in YAML, it is possible to generate a small YAML document that, when read, is expanded to a large size, causing CPU and memory consumption, such as a Java Out-of-Memory exception.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.esotericsoftware.yamlbeans:yamlbeans"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-24620"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-611"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-25T22:04:01Z",
    "nvd_published_at": "2023-08-25T20:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Esoteric YamlBeans through 1.15. A crafted YAML document is able perform am XML Entity Expansion attack against YamlBeans YamlReader. By exploiting the Anchor feature in YAML, it is possible to generate a small YAML document that, when read, is expanded to a large size, causing CPU and memory consumption, such as a Java Out-of-Memory exception.",
  "id": "GHSA-vj49-j7rc-h54f",
  "modified": "2023-09-01T17:35:22Z",
  "published": "2023-08-25T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24620"
    },
    {
      "type": "WEB",
      "url": "https://contrastsecurity.com"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Contrast-Security-OSS/yamlbeans/blob/main/SECURITY.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/EsotericSoftware"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EsotericSoftware/yamlbeans"
    }
  ],
  "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"
    }
  ],
  "summary": "Esoteric YamlBeans XML Entity Expansion vulnerability"
}

GHSA-VJCV-9J33-WJ62

Vulnerability from github – Published: 2026-09-17 15:32 – Updated: 2026-10-05 22:34
Withdrawn 2026-10-05 VLAI
Summary
Duplicate Advisory: vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-r4fx-v8hh-22mv. This link is maintained to preserve external references.

Original Description

vm2 before 3.11.7 (affected versions <= 3.11.6) does not enforce the VM({ timeout }) option on code executed outside the synchronous VM#run() call. The timeout only wraps the single call to _runScript() via doWithTimeout() in lib/vm.js, and FinalizationRegistry and WeakRef are exposed to sandboxed code unmodified (they are not among the hardened globals in lib/setup-sandbox.js). Sandboxed code can register a FinalizationRegistry cleanup callback against an object and then drop the only strong reference to it; vm.run() returns within the configured timeout, but when the V8 garbage collector later reclaims the object it invokes the sandboxed cleanup callback outside any vm2 timeout accounting. A busy loop in that callback blocks the host event loop for an unbounded period, resulting in denial of service. The time of invocation depends on the garbage collector (e.g. under memory pressure or with --expose-gc).

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.11.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:34:58Z",
    "nvd_published_at": "2026-09-17T14:17:59Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-r4fx-v8hh-22mv. This link is maintained to preserve external references.\n\n## Original Description\nvm2 before 3.11.7 (affected versions \u003c= 3.11.6) does not enforce the VM({ timeout }) option on code executed outside the synchronous VM#run() call. The timeout only wraps the single call to _runScript() via doWithTimeout() in lib/vm.js, and FinalizationRegistry and WeakRef are exposed to sandboxed code unmodified (they are not among the hardened globals in lib/setup-sandbox.js). Sandboxed code can register a FinalizationRegistry cleanup callback against an object and then drop the only strong reference to it; vm.run() returns within the configured timeout, but when the V8 garbage collector later reclaims the object it invokes the sandboxed cleanup callback outside any vm2 timeout accounting. A busy loop in that callback blocks the host event loop for an unbounded period, resulting in denial of service. The time of invocation depends on the garbage collector (e.g. under memory pressure or with --expose-gc).",
  "id": "GHSA-vjcv-9j33-wj62",
  "modified": "2026-10-05T22:34:58Z",
  "published": "2026-09-17T15:32:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-r4fx-v8hh-22mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92942"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-timeout-bypass-via-finalizationregistry"
    }
  ],
  "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"
    },
    {
      "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:N/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"
    }
  ],
  "summary": "Duplicate Advisory: vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)",
  "withdrawn": "2026-10-05T22:34:58Z"
}

GHSA-VJHX-2CQW-3Q6Q

Vulnerability from github – Published: 2026-08-19 19:16 – Updated: 2026-08-19 19:16
VLAI
Summary
Uprobe gadgets: unprivileged container's ld.so.cache causes high CPU utilization and container startup DoS
Details

Summary

An unprivileged container can block all other containers from starting on the same host by placing a crafted /etc/ld.so.cache file in its filesystem. When Inspektor Gadget attaches any uprobe-based gadget, it parses this file in the container startup path. A malicious cache causes ~53 seconds of CPU burn, during which Docker cannot start any other container. No special capabilities are required.

Severity

To be assessed — Availability impact, no confidentiality or integrity impact.

Affected Versions

All versions of Inspektor Gadget that support uprobe-based gadgets (trace_malloc, trace_open, trace_ssl, trace_grpc, etc.).

Description

When Inspektor Gadget attaches uprobe-based gadgets to containers, it resolves library paths by parsing the container's /etc/ld.so.cache file (pkg/uprobetracer/ldcache_parser.go). This file is fully controlled by the container.

The parser has three vulnerabilities:

  1. Quadratic string building (pkg/uprobetracer/bytes.go:36-44): The readStringFromBytes function concatenates one byte at a time (res += string(data[i])), which is O(n²) in Go due to string immutability. With a 16MB cache file containing large regions without null terminators, this causes massive CPU and memory churn.

  2. Insufficient entry count validation (pkg/uprobetracer/ldcache_parser.go:120): The EntryCount field is read directly from the untrusted file. While a per-entry bounds check prevents out-of-bounds access, the loop still iterates up to (fileSize - headerSize) / entrySize ≈ 700,000 times, calling readStringFromBytes on each iteration.

  3. Integer overflow in format detection (pkg/uprobetracer/ldcache_parser.go:174): The cache1Len computation uses uint32 arithmetic (ldCache1Size + cache1.EntryCount*ldCache1EntrySize). With a crafted EntryCount, this overflows and produces a small value, causing the parser to misidentify the cache format.

Combined, these cause ~53 seconds of CPU burn per container attachment when a crafted 16MB /etc/ld.so.cache is present.

Impact

  • Container runtime DoS: IG uses fanotify hooks (pkg/container-hook) to pause container startup until uprobe attachment completes. While IG is blocked processing the malicious cache, this pause is held, and Docker serializes container starts — meaning no other container can start on the host until IG finishes. This effectively causes a denial of service on the entire container runtime, not just on IG itself.
  • Container startup delay: When any uprobe-based gadget is running (trace_malloc, trace_ssl, etc.), starting a container with a crafted ld.so.cache delays startup by ~1 minute.
  • Monitoring degradation: The IG daemon is blocked processing the malicious cache, potentially missing events from other containers.
  • Amplification: Multiple containers with crafted caches can be started simultaneously to amplify the effect.
  • No special privileges required: Any container can include a crafted /etc/ld.so.cache in its image, mount one via a volume, or overwrite it at runtime before IG starts a uprobe gadget. In this last case, IG inspects all already-running containers when the gadget starts — this still burns CPU but does not block other containers from starting (since the fanotify pause only applies to new container starts).

Root Cause Analysis

In pkg/uprobetracer/ldcache_parser.go, the function readCacheFormat2 is called with the full file content:

for i := uint32(0); i < ldCache.EntryCount; i++ {
    entryOffset := ldEntriesOffset + i*ldCache2EntrySize
    if uint32(len(data)) <= entryOffset+ldCache2EntrySize {
        return nil  // bounds check stops iteration
    }
    // ... reads entry ...
    key := readStringFromBytes(data, keyOffset)    // O(n²) per call
    value := readStringFromBytes(data, valueOffset) // O(n²) per call
}

The per-entry bounds check correctly prevents out-of-bounds access, but: - The loop iterates ~700K times (limited by file size, not EntryCount) - Each readStringFromBytes call uses quadratic string concatenation

In pkg/uprobetracer/bytes.go:

func readStringFromBytes(data []byte, startPos uint32) string {
    res := ""
    for i := startPos; i < uint32(len(data)); i++ {
        if data[i] == 0 {
            return res
        }
        res += string(data[i])  // O(n²) — allocates new string each iteration
    }
    return ""
}

Note on Slice Bounds Checks

The code also performs slice accesses without proper bounds checks (e.g., data[:len(cache2Header)] when data may be shorter than 20 bytes, and ldCacheFile[:len(cache1Header)] when the file may be shorter than 11 bytes).

In practice, a malicious container cannot currently trigger a panic from these missing checks. This is because Go's io.ReadAll (used to read the file) always returns slices with cap >= 512 due to its initial buffer allocation (make([]byte, 0, 512) in Go's standard library). In Go, s[:n] only panics when n > cap(s), not when n > len(s). Since both header lengths (11 and 20) are well below 512, the slice expressions succeed — they simply read zero bytes beyond len, which don't match any valid header magic.

However, this relies on an undocumented implementation detail of io.ReadAll which could change in future Go versions. The bounds checks are still necessary for correctness and defense in depth.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/inspektor-gadget/inspektor-gadget"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.27.0"
            },
            {
              "fixed": "0.53.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T19:16:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAn unprivileged container can block all other containers from starting on the\nsame host by placing a crafted `/etc/ld.so.cache` file in its filesystem. When\nInspektor Gadget attaches any uprobe-based gadget, it parses this file in the\ncontainer startup path. A malicious cache causes ~53 seconds of CPU burn,\nduring which Docker cannot start any other container. No special capabilities\nare required.\n\n## Severity\n\nTo be assessed \u2014 Availability impact, no confidentiality or integrity impact.\n\n## Affected Versions\n\nAll versions of Inspektor Gadget that support uprobe-based gadgets (trace_malloc, trace_open, trace_ssl, trace_grpc, etc.).\n\n## Description\n\nWhen Inspektor Gadget attaches uprobe-based gadgets to containers, it resolves library paths by parsing the container\u0027s `/etc/ld.so.cache` file (`pkg/uprobetracer/ldcache_parser.go`). This file is fully controlled by the container.\n\nThe parser has three vulnerabilities:\n\n1. **Quadratic string building** (`pkg/uprobetracer/bytes.go:36-44`): The `readStringFromBytes` function concatenates one byte at a time (`res += string(data[i])`), which is O(n\u00b2) in Go due to string immutability. With a 16MB cache file containing large regions without null terminators, this causes massive CPU and memory churn.\n\n2. **Insufficient entry count validation** (`pkg/uprobetracer/ldcache_parser.go:120`): The `EntryCount` field is read directly from the untrusted file. While a per-entry bounds check prevents out-of-bounds access, the loop still iterates up to `(fileSize - headerSize) / entrySize \u2248 700,000` times, calling `readStringFromBytes` on each iteration.\n\n3. **Integer overflow in format detection** (`pkg/uprobetracer/ldcache_parser.go:174`): The `cache1Len` computation uses uint32 arithmetic (`ldCache1Size + cache1.EntryCount*ldCache1EntrySize`). With a crafted `EntryCount`, this overflows and produces a small value, causing the parser to misidentify the cache format.\n\nCombined, these cause ~53 seconds of CPU burn per container attachment when a crafted 16MB `/etc/ld.so.cache` is present.\n\n## Impact\n\n- **Container runtime DoS**: IG uses fanotify hooks (`pkg/container-hook`) to pause container startup until uprobe attachment completes. While IG is blocked processing the malicious cache, this pause is held, and Docker serializes container starts \u2014 meaning no other container can start on the host until IG finishes. This effectively causes a denial of service on the entire container runtime, not just on IG itself.\n- **Container startup delay**: When any uprobe-based gadget is running (trace_malloc, trace_ssl, etc.), starting a container with a crafted ld.so.cache delays startup by ~1 minute.\n- **Monitoring degradation**: The IG daemon is blocked processing the malicious cache, potentially missing events from other containers.\n- **Amplification**: Multiple containers with crafted caches can be started simultaneously to amplify the effect.\n- **No special privileges required**: Any container can include a crafted `/etc/ld.so.cache` in its image, mount one via a volume, or overwrite it at runtime before IG starts a uprobe gadget. In this last case, IG inspects all already-running containers when the gadget starts \u2014 this still burns CPU but does not block other containers from starting (since the fanotify pause only applies to new container starts).\n\n## Root Cause Analysis\n\nIn `pkg/uprobetracer/ldcache_parser.go`, the function `readCacheFormat2` is called with the full file content:\n\n```go\nfor i := uint32(0); i \u003c ldCache.EntryCount; i++ {\n    entryOffset := ldEntriesOffset + i*ldCache2EntrySize\n    if uint32(len(data)) \u003c= entryOffset+ldCache2EntrySize {\n        return nil  // bounds check stops iteration\n    }\n    // ... reads entry ...\n    key := readStringFromBytes(data, keyOffset)    // O(n\u00b2) per call\n    value := readStringFromBytes(data, valueOffset) // O(n\u00b2) per call\n}\n```\n\nThe per-entry bounds check correctly prevents out-of-bounds access, but:\n- The loop iterates ~700K times (limited by file size, not EntryCount)\n- Each `readStringFromBytes` call uses quadratic string concatenation\n\nIn `pkg/uprobetracer/bytes.go`:\n\n```go\nfunc readStringFromBytes(data []byte, startPos uint32) string {\n    res := \"\"\n    for i := startPos; i \u003c uint32(len(data)); i++ {\n        if data[i] == 0 {\n            return res\n        }\n        res += string(data[i])  // O(n\u00b2) \u2014 allocates new string each iteration\n    }\n    return \"\"\n}\n```\n\n## Note on Slice Bounds Checks\n\nThe code also performs slice accesses without proper bounds checks (e.g.,\n`data[:len(cache2Header)]` when `data` may be shorter than 20 bytes, and\n`ldCacheFile[:len(cache1Header)]` when the file may be shorter than 11 bytes).\n\nIn practice, a malicious container **cannot currently trigger a panic** from these\nmissing checks. This is because Go\u0027s `io.ReadAll` (used to read the file) always\nreturns slices with `cap \u003e= 512` due to its initial buffer allocation\n(`make([]byte, 0, 512)` in Go\u0027s standard library). In Go, `s[:n]` only panics\nwhen `n \u003e cap(s)`, not when `n \u003e len(s)`. Since both header lengths (11 and 20)\nare well below 512, the slice expressions succeed \u2014 they simply read zero bytes\nbeyond `len`, which don\u0027t match any valid header magic.\n\nHowever, this relies on an **undocumented implementation detail** of `io.ReadAll`\nwhich could change in future Go versions. The bounds checks are still necessary\nfor correctness and defense in depth.",
  "id": "GHSA-vjhx-2cqw-3q6q",
  "modified": "2026-08-19T19:16:35Z",
  "published": "2026-08-19T19:16:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/inspektor-gadget/inspektor-gadget/security/advisories/GHSA-vjhx-2cqw-3q6q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/inspektor-gadget/inspektor-gadget"
    },
    {
      "type": "WEB",
      "url": "https://github.com/inspektor-gadget/inspektor-gadget/releases/tag/v0.53.1"
    }
  ],
  "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:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Uprobe gadgets: unprivileged container\u0027s ld.so.cache causes high CPU utilization and container startup DoS"
}

GHSA-VJPV-X8P9-7P85

Vulnerability from github – Published: 2024-07-10 06:33 – Updated: 2024-07-10 21:28
VLAI
Summary
images vulnerable to Denial of Service
Details

All versions of the package images are vulnerable to Denial of Service (DoS) due to providing unexpected input types to several different functions. This makes it possible to reach an assert macro, leading to a process crash.

Note: By providing some specific integer values (like 0) to the size function, it is possible to obtain a Segmentation fault error, leading to the process crash.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "images"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-241",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-10T21:28:42Z",
    "nvd_published_at": "2024-07-10T05:15:11Z",
    "severity": "HIGH"
  },
  "details": "All versions of the package images are vulnerable to Denial of Service (DoS) due to providing unexpected input types to several different functions. This makes it possible to reach an assert macro, leading to a process crash.\n\n**Note:**\nBy providing some specific integer values (like 0) to the size function, it is possible to obtain a Segmentation fault error, leading to the process crash.",
  "id": "GHSA-vjpv-x8p9-7p85",
  "modified": "2024-07-10T21:28:42Z",
  "published": "2024-07-10T06:33:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21523"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/dellalibera/8b4ea6b4db84cba212e6e6e39a6933d1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zhangyuanwei/node-images"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zhangyuanwei/node-images/blob/691d49f4e620b4eec9f1c47b1735841d9d8b55f6/src/Image.cc"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-IMAGES-6421826"
    }
  ],
  "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"
    },
    {
      "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:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "images vulnerable to Denial of Service"
}

GHSA-VJR3-852X-R77Q

Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31
VLAI
Details

Vulnerability in the Siebel CRM Cloud Applications product of Oracle Siebel CRM (component: Siebel Cloud Manager). Supported versions that are affected are 22.3-26.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Siebel CRM Cloud Applications. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Siebel CRM Cloud Applications. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-47018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:17:07Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Siebel CRM Cloud Applications product of Oracle Siebel CRM (component: Siebel Cloud Manager).  Supported versions that are affected are 22.3-26.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Siebel CRM Cloud Applications.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Siebel CRM Cloud Applications. CVSS 3.1 Base Score 7.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-vjr3-852x-r77q",
  "modified": "2026-07-22T00:31:15Z",
  "published": "2026-07-22T00:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47018"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.html"
    }
  ],
  "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-VJXC-FRW4-JMH5

Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2022-11-07 22:04
VLAI
Summary
Undertow vulnerable to Uncontrolled Resource Consumption
Details

A vulnerability was found in the Undertow HTTP server in versions before 2.0.29 when listening on HTTPS. An attacker can target the HTTPS port to carry out a Denial Of Service (DOS) to make the service unavailable on SSL.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.undertow:undertow-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.29.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-14888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-07T22:04:19Z",
    "nvd_published_at": "2020-01-23T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in the Undertow HTTP server in versions before 2.0.29 when listening on HTTPS. An attacker can target the HTTPS port to carry out a Denial Of Service (DOS) to make the service unavailable on SSL.",
  "id": "GHSA-vjxc-frw4-jmh5",
  "modified": "2022-11-07T22:04:19Z",
  "published": "2022-05-24T17:07:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14888"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0729"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14888"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220211-0001"
    }
  ],
  "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": "Undertow vulnerable to Uncontrolled Resource Consumption"
}

GHSA-VM2Q-68W5-CVC5

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30
VLAI
Details

On Juniper Networks EX4300 Series, receipt of a stream of specific IPv4 packets can cause Routing Engine (RE) high CPU load, which could lead to network protocol operation issue and traffic interruption. This specific packets can originate only from within the broadcast domain where the device is connected. This issue occurs when the packets enter to the IRB interface. Only IPv4 packets can trigger this issue. IPv6 packets cannot trigger this issue. This issue affects Juniper Networks Junos OS on EX4300 series: 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S11, 17.4R3-S2; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R3-S4; 18.3 versions prior to 18.3R2-S4, 18.3R3-S2; 18.4 versions prior to 18.4R2-S4, 18.4R3-S2; 19.1 versions prior to 19.1R2-S2, 19.1R3-S1; 19.2 versions prior to 19.2R1-S5, 19.2R2-S1, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2; 20.1 versions prior to 20.1R1-S3, 20.1R2.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-1670"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-16T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "On Juniper Networks EX4300 Series, receipt of a stream of specific IPv4 packets can cause Routing Engine (RE) high CPU load, which could lead to network protocol operation issue and traffic interruption. This specific packets can originate only from within the broadcast domain where the device is connected. This issue occurs when the packets enter to the IRB interface. Only IPv4 packets can trigger this issue. IPv6 packets cannot trigger this issue. This issue affects Juniper Networks Junos OS on EX4300 series: 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S11, 17.4R3-S2; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R3-S4; 18.3 versions prior to 18.3R2-S4, 18.3R3-S2; 18.4 versions prior to 18.4R2-S4, 18.4R3-S2; 19.1 versions prior to 19.1R2-S2, 19.1R3-S1; 19.2 versions prior to 19.2R1-S5, 19.2R2-S1, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2; 20.1 versions prior to 20.1R1-S3, 20.1R2.",
  "id": "GHSA-vm2q-68w5-cvc5",
  "modified": "2022-05-24T17:30:51Z",
  "published": "2022-05-24T17:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1670"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA11067\u0026actp=SUBSCRIPTION"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VM5R-597X-RGVG

Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-07-11 00:00
VLAI
Details

Mikrotik RouterOs before stable 6.47 suffers from an uncontrolled resource consumption in the sshd process. An authenticated remote attacker can cause a Denial of Service due to overloading the systems CPU.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-20230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-19T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Mikrotik RouterOs before stable 6.47 suffers from an uncontrolled resource consumption in the sshd process. An authenticated remote attacker can cause a Denial of Service due to overloading the systems CPU.",
  "id": "GHSA-vm5r-597x-rgvg",
  "modified": "2022-07-11T00:00:21Z",
  "published": "2022-05-24T19:08:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20230"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/400.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cq674350529/pocs_slides/blob/master/advisory/MikroTik/CVE-2020-20230/README.md"
    }
  ],
  "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"
    }
  ]
}

GHSA-VM9M-57JR-4PXH

Vulnerability from github – Published: 2024-02-29 12:31 – Updated: 2024-12-13 20:29
VLAI
Summary
Mattermost fails to limit the number of role names
Details

Mattermost versions 8.1.x before 8.1.9, 9.2.x before 9.2.5, 9.3.0, and 9.4.x before 9.4.2 fail to limit the number of role names requested from the API, allowing an authenticated attacker to cause the server to run out of memory and crash by issuing an unusually large HTTP request.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.4.0"
            },
            {
              "fixed": "9.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.3.0"
            },
            {
              "fixed": "9.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.2.0"
            },
            {
              "fixed": "9.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-29T22:49:32Z",
    "nvd_published_at": "2024-02-29T11:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 8.1.x before 8.1.9, 9.2.x before 9.2.5, 9.3.0, and 9.4.x before 9.4.2 fail to limit the number of role names requested from the API, allowing an authenticated attacker to cause the server to run out of memory and crash by issuing an unusually large HTTP request.\n\n",
  "id": "GHSA-vm9m-57jr-4pxh",
  "modified": "2024-12-13T20:29:02Z",
  "published": "2024-02-29T12:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1953"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-2594"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Mattermost fails to limit the number of role names"
}

GHSA-VMCH-3W2X-VHGQ

Vulnerability from github – Published: 2023-08-09 12:56 – Updated: 2025-10-22 19:21
VLAI
Summary
.NET Denial of Service Vulnerability
Details

Microsoft Security Advisory CVE-2023-38180: .NET Denial of Service Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core 2.1, .NET 6.0, and .NET 7.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A vulnerability exists in Kestrel where, on detecting a potentially malicious client, Kestrel will sometimes fail to disconnect it, resulting in denial of service.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/269

Mitigation factors

If your application is running behind a reverse proxy, or Web Application Firewall, which has its own mitigations against HTTP based attacks this issue may be mitigated by the proxy or WAF

Affected software

  • Any .NET 7.0 application running on .NET 7.0.8 or earlier.
  • Any .NET 6.0 application running on .NET 6.0.19 or earlier.

If your application uses the following package versions, ensure you update to the latest version of .NET.

.NET 7

Package name Affected version Patched version
Microsoft.AspNetCore.App.Runtime.win-arm64 >= 7.0.0, <= 7.0.9 7.0.10
Microsoft.AspNetCore.App.Runtime.win-x64 >= 7.0.0, <= 7.0.9 7.0.10
Microsoft.AspNetCore.App.Runtime.win-x86 >= 7.0.0, <= 7.0.9 7.0.10

.NET 6

Package name Affected version Patched version
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv >= 6.0.0, <= 6.0.20 6.0.21
Microsoft.AspNetCore.App.Runtime.win-arm64 >= 6.0.0, <= 6.0.20 6.0.21
Microsoft.AspNetCore.App.Runtime.win-x64 >= 6.0.0, <= 6.0.20 6.0.21
Microsoft.AspNetCore.App.Runtime.win-x86 >= 6.0.0, <= 6.0.20 6.0.21

ASP.NET Core 2.1

Package name Affected version Patched version
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv <= 2.1.39 2.1.40
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets <= 2.1.39 2.1.40

Advisory FAQ

How do I know if I am affected?

If you have a runtime or SDK with a version listed, or an affected package listed in affected software, you're exposed to the vulnerability.

How do I fix the issue?

  • To fix the issue please install the latest version of .NET 6.0 or .NET 7.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
  • If you are using one of the affected packages, please update to the patched version listed above.
  • If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the dotnet --info command. You will see output like the following;
.NET Core SDK (reflecting any global.json):

 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:

 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):

  Version: 6.0.5
  Commit:  8473146e7d

.NET Core SDKs installed:

  6.0.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:

  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
  • If you're using .NET 7.0, you should download and install Runtime 7.0.10 or SDK 7.0.110 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0.
  • If you're using .NET 6.0, you should download and install Runtime 6.0.21 or SDK 6.0.316 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0.

.NET 6.0 and and .NET 7.0 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.

Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Other Information

Reporting Security Issues

If you have found a potential security issue in .NET 6.0 or .NET 7.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2023-38180

Revisions

V1.0 (August 08, 2023): Advisory published.

Version 1.0

Last Updated 2023-08-08

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.9"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.9"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.win-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.9"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.win-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.20"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.20"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.20"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.win-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.20"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.win-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.39"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.39"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-38180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-09T12:56:43Z",
    "nvd_published_at": "2023-08-08T19:15:10Z",
    "severity": "HIGH"
  },
  "details": "# Microsoft Security Advisory CVE-2023-38180: .NET Denial of Service Vulnerability\n\n## \u003ca name=\"executive-summary\"\u003e\u003c/a\u003eExecutive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core 2.1, .NET 6.0, and .NET 7.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nA vulnerability exists in Kestrel where, on detecting a potentially malicious client, Kestrel will sometimes fail to disconnect it, resulting in denial of service.\n\n## Announcement\n\nAnnouncement for this issue can be found at  https://github.com/dotnet/announcements/issues/269\n\n### \u003ca name=\"mitigation-factors\"\u003e\u003c/a\u003eMitigation factors\n\nIf your application is running behind a reverse proxy, or Web Application Firewall, which has its own mitigations against HTTP based attacks this issue may be mitigated by the proxy or WAF\n\n## \u003ca name=\"affected-software\"\u003e\u003c/a\u003eAffected software\n\n* Any .NET 7.0 application running on .NET 7.0.8 or earlier.\n* Any .NET 6.0 application running on .NET 6.0.19 or earlier.\n\nIf your application uses the following package versions, ensure you update to the latest version of .NET.\n\n### \u003ca name=\".NET 7\"\u003e\u003c/a\u003e.NET 7\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64)      | \u003e= 7.0.0, \u003c= 7.0.9 | 7.0.10\n[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64)          | \u003e= 7.0.0, \u003c= 7.0.9 | 7.0.10\n[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86)          | \u003e= 7.0.0, \u003c= 7.0.9 | 7.0.10\n\n### \u003ca name=\".NET 6\"\u003e\u003c/a\u003e.NET 6\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv](https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv)      | \u003e= 6.0.0, \u003c= 6.0.20 | 6.0.21\n[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64)      | \u003e= 6.0.0, \u003c= 6.0.20 | 6.0.21\n[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64)          | \u003e= 6.0.0, \u003c= 6.0.20 | 6.0.21\n[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86)          | \u003e= 6.0.0, \u003c= 6.0.20 | 6.0.21\n\n### \u003ca name=\"ASP.NET Core 2.1\"\u003e\u003c/a\u003eASP.NET Core 2.1\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv](https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv)      | \u003c= 2.1.39 | 2.1.40\n[Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets](https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets) | \u003c= 2.1.39 | 2.1.40\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf you have a runtime or SDK with a version listed, or an affected package listed in [affected software](#affected-software), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n* To fix the issue please install the latest version of .NET 6.0 or .NET 7.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET  SDKs.\n* If you are using one of the affected packages, please update to the patched version listed above.\n* If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the `dotnet --info` command. You will see output like the following;\n\n```\n.NET Core SDK (reflecting any global.json):\n\n Version:   6.0.300\n Commit:    8473146e7d\n\nRuntime Environment:\n\n OS Name:     Windows\n OS Version:  10.0.18363\n OS Platform: Windows\n RID:         win10-x64\n Base Path:   C:\\Program Files\\dotnet\\sdk\\6.0.300\\\n\nHost (useful for support):\n\n  Version: 6.0.5\n  Commit:  8473146e7d\n\n.NET Core SDKs installed:\n\n  6.0.300 [C:\\Program Files\\dotnet\\sdk]\n\n.NET Core runtimes installed:\n\n  Microsoft.AspNetCore.App 6.0.5 [C:\\Program Files\\dotnet\\shared\\Microsoft.AspNetCore.App]\n  Microsoft.NETCore.App 6.0.5 [C:\\Program Files\\dotnet\\shared\\Microsoft.NETCore.App]\n  Microsoft.WindowsDesktop.App 6.0.5 [C:\\Program Files\\dotnet\\shared\\Microsoft.WindowsDesktop.App]\n\nTo install additional .NET Core runtimes or SDKs:\n  https://aka.ms/dotnet-download\n```\n\n* If you\u0027re using .NET 7.0, you should download and install Runtime 7.0.10 or SDK 7.0.110 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0.\n* If you\u0027re using .NET 6.0, you should download and install Runtime 6.0.21 or SDK 6.0.316 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0.\n\n.NET 6.0 and and .NET 7.0 updates are also available from Microsoft Update. To access this either type \"Check for updates\" in your Windows search, or open Settings, choose Update \u0026 Security and then click Check for Updates.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in .NET 6.0 or .NET 7.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core \u0026 .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at \u003chttps://aka.ms/corebounty\u003e.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2023-38180]( https://www.cve.org/CVERecord?id=CVE-2023-38180)\n\n### Revisions\n\nV1.0 (August 08, 2023): Advisory published.\n\n_Version 1.0_\n\n_Last Updated 2023-08-08_",
  "id": "GHSA-vmch-3w2x-vhgq",
  "modified": "2025-10-22T19:21:48Z",
  "published": "2023-08-09T12:56:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/security/advisories/GHSA-vmch-3w2x-vhgq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38180"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/issues/90170"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dotnet/runtime"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CL2L4WE5QRT7WEXANYXSKSU43APC5N2V"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NWVZFKTLNMNKPZ755EMRYIA6GHFOWGKY"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-38180"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-38180"
    }
  ],
  "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/E:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": ".NET Denial of Service Vulnerability"
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

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

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list