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.

5435 vulnerabilities reference this CWE, most recent first.

GHSA-8XQ5-7XQ7-G2FM

Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2022-10-24 19:00
VLAI
Details

In all BIG-IP 13.1.x versions, when an iRule containing the HTTP::collect command is configured on a virtual server, undisclosed requests can cause Traffic Management Microkernel (TMM) to terminate.

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-2022-41833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-19T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "In all BIG-IP 13.1.x versions, when an iRule containing the HTTP::collect command is configured on a virtual server, undisclosed requests can cause Traffic Management Microkernel (TMM) to terminate.",
  "id": "GHSA-8xq5-7xq7-g2fm",
  "modified": "2022-10-24T19:00:22Z",
  "published": "2022-10-20T12:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41833"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K69940053"
    }
  ],
  "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-8XQ6-FRF7-63CG

Vulnerability from github – Published: 2023-10-25 21:30 – Updated: 2023-11-02 15:30
VLAI
Details

An inconsistent user interface issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14.1, watchOS 10.1, iOS 16.7.2 and iPadOS 16.7.2, iOS 17.1 and iPadOS 17.1. Hide My Email may be deactivated unexpectedly.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-40408"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-25T19:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An inconsistent user interface issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14.1, watchOS 10.1, iOS 16.7.2 and iPadOS 16.7.2, iOS 17.1 and iPadOS 17.1. Hide My Email may be deactivated unexpectedly.",
  "id": "GHSA-8xq6-frf7-63cg",
  "modified": "2023-11-02T15:30:23Z",
  "published": "2023-10-25T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40408"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213981"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213982"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213984"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213988"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213981"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213982"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213984"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213988"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Oct/19"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Oct/23"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Oct/24"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Oct/25"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8XX9-69P8-7JP3

Vulnerability from github – Published: 2026-05-27 00:11 – Updated: 2026-07-09 21:06
VLAI
Summary
LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body
Details

Summary

The renderLimit option — documented in docs/source/tutorials/dos.md as the mechanism that "mitigates this by limiting the time consumed by each render() call" — can be fully bypassed by a {% for %} (or {% tablerow %}) tag whose body is empty. The per-iteration time check is reached only when the body contains at least one template node, so a template like {%- for i in (1..N) -%}{%- endfor -%} iterates the full collection without ever consulting renderLimit. With a configured renderLimit of 50 ms, a single parseAndRenderSync call has been observed to consume 2.26 seconds (~45× over the limit) and scales linearly with N up to memoryLimit, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration.

Details

Render.renderTemplates is the single point at which renderLimit is consulted:

// src/render/render.ts
14:  public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator<any> {
15:    if (!emitter) {
16:      emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()
17:    }
18:    const errors = []
19:    for (const tpl of templates) {
20:      ctx.renderLimit.check(getPerformance().now())
21:      try {
22:        const html = yield tpl.render(ctx, emitter)
...
32:    }

The check at line 20 lives inside the for (const tpl of templates) body. When templates.length === 0, the loop body never executes, so the limiter is never consulted on that invocation.

The for tag re-enters renderTemplates once per collection item with no independent time check:

// src/tags/for.ts
70:    for (const item of collection) {
71:      scope[this.variable] = item
72:      ctx.continueCalled = ctx.breakCalled = false
73:      yield r.renderTemplates(this.templates, ctx, emitter)
74:      if (ctx.breakCalled) break
75:      scope.forloop.next()
76:    }

When {%- for i in (1..N) -%}{%- endfor -%} is parsed, this.templates is []. Each of the N calls to r.renderTemplates(this.templates, ctx, emitter) therefore performs zero renderLimit.check() calls and zero template work — it just spins the JS-level for loop and the generator boilerplate. With N = 30_000_000 this still costs ~2.26 s of CPU, and N = 100_000_000 costs ~9.6 s, fully bypassing whatever wall-clock budget the integrator configured.

The range expression itself is bounded only by memoryLimit:

// src/render/expression.ts:67-72
function * evalRangeToken (token: RangeToken, ctx: Context) {
  const low: number = yield evalToken(token.lhs, ctx)
  const high: number = yield evalToken(token.rhs, ctx)
  ctx.memoryLimit.use(high - low + 1)
  return range(+low, +high + 1)
}

So the maximum bypass is governed by the (separate) memoryLimit, not by renderLimit. Integrators following the docs/source/tutorials/dos.md guidance — which positions renderLimit as the time-based defense — get no time-based defense at all on this code path.

PoC

Reproduced against liquidjs@10.25.7 (HEAD 34877950):

# Empty for-body bypasses renderLimit (50 ms) and runs for ~2.26 s:
$ node -e "const { Liquid } = require('liquidjs');
  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });
  const t = Date.now();
  engine.parseAndRenderSync('{%- for i in (1..30000000) -%}{%- endfor -%}', {});
  console.log('Took', Date.now()-t, 'ms');"
Took 2255 ms

# Same template with a single-character body is correctly bounded:
$ node -e "const { Liquid } = require('liquidjs');
  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });
  try { engine.parseAndRenderSync('{%- for i in (1..30000000) -%}.{%- endfor -%}', {}); }
  catch(e) { console.log('correctly threw:', e.message); }"
correctly threw: template render limit exceeded, line:1, col:1

Scaling N: - N = 30_000_000 → 2255 ms (≈ 45× over the 50 ms limit) - N = 100_000_000 → 9581 ms (≈ 191× over the 50 ms limit)

Time grows linearly with N, capped only by memoryLimit (default Infinity, so the only cap by default is process memory).

Impact

Any liquidjs integrator who follows the upstream DoS guidance and sets a finite renderLimit to bound per-render CPU — typical for SaaS / multi-tenant environments where end users author templates (themes, email templates, snippets) — does not get the bound they configured. A single template submission can keep an event-loop thread busy for seconds, which on a Node.js server is sufficient to stall all in-flight requests on that worker. With a large enough range and a permissive memoryLimit, the wedge time is attacker-controlled. No data is exposed and no integrity is harmed; impact is availability only.

Recommended Fix

Move the renderLimit check to a location that runs unconditionally per renderTemplates invocation, so a zero-template body still triggers it; alternatively (or additionally) have iteration tags that invoke renderTemplates per element check the limiter themselves once per iteration.

// src/render/render.ts — check at function entry, before the templates loop
public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator<any> {
  if (!emitter) {
    emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()
  }
  ctx.renderLimit.check(getPerformance().now())   // <-- runs even when templates is empty
  const errors = []
  for (const tpl of templates) {
    ctx.renderLimit.check(getPerformance().now())
    ...
  }
  ...
}

And/or, defensively, in the iteration tags themselves so the guard cost is paid once per element rather than only at re-entry:

// src/tags/for.ts (around line 70)
for (const item of collection) {
  ctx.renderLimit.check(getPerformance().now())   // <-- per-iteration time check
  scope[this.variable] = item
  ctx.continueCalled = ctx.breakCalled = false
  yield r.renderTemplates(this.templates, ctx, emitter)
  if (ctx.breakCalled) break
  scope.forloop.next()
}

// src/tags/tablerow.ts (around line 54) — analogous addition
for (let idx = 0; idx < collection.length; idx++, tablerowloop.next()) {
  ctx.renderLimit.check(getPerformance().now())
  ...
}

The same hardening should be applied anywhere a tag drives an attacker-influenced loop count over a (potentially empty) templates array.

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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "liquidjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "10.25.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T00:11:46Z",
    "nvd_published_at": "2026-06-17T23:17:03Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `renderLimit` option \u2014 documented in `docs/source/tutorials/dos.md` as the mechanism that \"mitigates this by limiting the time consumed by each render() call\" \u2014 can be fully bypassed by a `{% for %}` (or `{% tablerow %}`) tag whose body is empty. The per-iteration time check is reached only when the body contains at least one template node, so a template like `{%- for i in (1..N) -%}{%- endfor -%}` iterates the full collection without ever consulting `renderLimit`. With a configured `renderLimit` of 50 ms, a single `parseAndRenderSync` call has been observed to consume **2.26 seconds** (~45\u00d7 over the limit) and scales linearly with `N` up to `memoryLimit`, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration.\n\n## Details\n\n`Render.renderTemplates` is the single point at which `renderLimit` is consulted:\n\n```ts\n// src/render/render.ts\n14:  public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator\u003cany\u003e {\n15:    if (!emitter) {\n16:      emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()\n17:    }\n18:    const errors = []\n19:    for (const tpl of templates) {\n20:      ctx.renderLimit.check(getPerformance().now())\n21:      try {\n22:        const html = yield tpl.render(ctx, emitter)\n...\n32:    }\n```\n\nThe check at line 20 lives **inside** the `for (const tpl of templates)` body. When `templates.length === 0`, the loop body never executes, so the limiter is never consulted on that invocation.\n\nThe `for` tag re-enters `renderTemplates` once per collection item with no independent time check:\n\n```ts\n// src/tags/for.ts\n70:    for (const item of collection) {\n71:      scope[this.variable] = item\n72:      ctx.continueCalled = ctx.breakCalled = false\n73:      yield r.renderTemplates(this.templates, ctx, emitter)\n74:      if (ctx.breakCalled) break\n75:      scope.forloop.next()\n76:    }\n```\n\nWhen `{%- for i in (1..N) -%}{%- endfor -%}` is parsed, `this.templates` is `[]`. Each of the `N` calls to `r.renderTemplates(this.templates, ctx, emitter)` therefore performs zero `renderLimit.check()` calls and zero template work \u2014 it just spins the JS-level `for` loop and the generator boilerplate. With `N = 30_000_000` this still costs ~2.26 s of CPU, and `N = 100_000_000` costs ~9.6 s, fully bypassing whatever wall-clock budget the integrator configured.\n\nThe range expression itself is bounded only by `memoryLimit`:\n\n```ts\n// src/render/expression.ts:67-72\nfunction * evalRangeToken (token: RangeToken, ctx: Context) {\n  const low: number = yield evalToken(token.lhs, ctx)\n  const high: number = yield evalToken(token.rhs, ctx)\n  ctx.memoryLimit.use(high - low + 1)\n  return range(+low, +high + 1)\n}\n```\n\nSo the maximum bypass is governed by the (separate) `memoryLimit`, not by `renderLimit`. Integrators following the `docs/source/tutorials/dos.md` guidance \u2014 which positions `renderLimit` as the time-based defense \u2014 get no time-based defense at all on this code path.\n\n## PoC\n\nReproduced against `liquidjs@10.25.7` (HEAD `34877950`):\n\n```bash\n# Empty for-body bypasses renderLimit (50 ms) and runs for ~2.26 s:\n$ node -e \"const { Liquid } = require(\u0027liquidjs\u0027);\n  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });\n  const t = Date.now();\n  engine.parseAndRenderSync(\u0027{%- for i in (1..30000000) -%}{%- endfor -%}\u0027, {});\n  console.log(\u0027Took\u0027, Date.now()-t, \u0027ms\u0027);\"\nTook 2255 ms\n\n# Same template with a single-character body is correctly bounded:\n$ node -e \"const { Liquid } = require(\u0027liquidjs\u0027);\n  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });\n  try { engine.parseAndRenderSync(\u0027{%- for i in (1..30000000) -%}.{%- endfor -%}\u0027, {}); }\n  catch(e) { console.log(\u0027correctly threw:\u0027, e.message); }\"\ncorrectly threw: template render limit exceeded, line:1, col:1\n```\n\nScaling `N`:\n- `N = 30_000_000` \u2192 2255 ms (\u2248 45\u00d7 over the 50 ms limit)\n- `N = 100_000_000` \u2192 9581 ms (\u2248 191\u00d7 over the 50 ms limit)\n\nTime grows linearly with `N`, capped only by `memoryLimit` (default `Infinity`, so the only cap by default is process memory).\n\n## Impact\n\nAny liquidjs integrator who follows the upstream DoS guidance and sets a finite `renderLimit` to bound per-render CPU \u2014 typical for SaaS / multi-tenant environments where end users author templates (themes, email templates, snippets) \u2014 does not get the bound they configured. A single template submission can keep an event-loop thread busy for seconds, which on a Node.js server is sufficient to stall all in-flight requests on that worker. With a large enough range and a permissive `memoryLimit`, the wedge time is attacker-controlled. No data is exposed and no integrity is harmed; impact is availability only.\n\n## Recommended Fix\n\nMove the `renderLimit` check to a location that runs unconditionally per `renderTemplates` invocation, so a zero-template body still triggers it; alternatively (or additionally) have iteration tags that invoke `renderTemplates` per element check the limiter themselves once per iteration.\n\n```ts\n// src/render/render.ts \u2014 check at function entry, before the templates loop\npublic * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator\u003cany\u003e {\n  if (!emitter) {\n    emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()\n  }\n  ctx.renderLimit.check(getPerformance().now())   // \u003c-- runs even when templates is empty\n  const errors = []\n  for (const tpl of templates) {\n    ctx.renderLimit.check(getPerformance().now())\n    ...\n  }\n  ...\n}\n```\n\nAnd/or, defensively, in the iteration tags themselves so the guard cost is paid once per element rather than only at re-entry:\n\n```ts\n// src/tags/for.ts (around line 70)\nfor (const item of collection) {\n  ctx.renderLimit.check(getPerformance().now())   // \u003c-- per-iteration time check\n  scope[this.variable] = item\n  ctx.continueCalled = ctx.breakCalled = false\n  yield r.renderTemplates(this.templates, ctx, emitter)\n  if (ctx.breakCalled) break\n  scope.forloop.next()\n}\n\n// src/tags/tablerow.ts (around line 54) \u2014 analogous addition\nfor (let idx = 0; idx \u003c collection.length; idx++, tablerowloop.next()) {\n  ctx.renderLimit.check(getPerformance().now())\n  ...\n}\n```\n\nThe same hardening should be applied anywhere a tag drives an attacker-influenced loop count over a (potentially empty) `templates` array.",
  "id": "GHSA-8xx9-69p8-7jp3",
  "modified": "2026-07-09T21:06:14Z",
  "published": "2026-05-27T00:11:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44645"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/commit/5b9c3469085e01c79e2d0af28e2a13f730e1793d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harttle/liquidjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/releases/tag/v10.26.0"
    }
  ],
  "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": "LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body"
}

GHSA-9259-5376-VJCJ

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2025-01-14 21:31
VLAI
Details

Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

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-2019-9515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-13T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.",
  "id": "GHSA-9259-5376-vjcj",
  "modified": "2025-01-14T21:31:39Z",
  "published": "2022-05-24T16:53:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9515"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/392108390cef48af647a2e47b7fd5380e050e35ae8d1aa2030254c04@%3Cusers.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ad3d01e767199c1aed8033bb6b3f5bf98c011c7c536f07a5d34b3c19%40%3Cannounce.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ad3d01e767199c1aed8033bb6b3f5bf98c011c7c536f07a5d34b3c19@%3Cannounce.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/bde52309316ae798186d783a5e29f4ad1527f61c9219a289d0eee0a7%40%3Cdev.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/bde52309316ae798186d783a5e29f4ad1527f61c9219a289d0eee0a7@%3Cdev.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4ZQGHE3WTYLYAYJEIDJVF2FIGQTAYPMC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CMNFX5MNYRWWIMO4BTKYQCGUDMHO3AXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4ZQGHE3WTYLYAYJEIDJVF2FIGQTAYPMC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CMNFX5MNYRWWIMO4BTKYQCGUDMHO3AXP"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Aug/24"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Aug/43"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Sep/18"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190823-0005"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K50233772"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K50233772?utm_source=f5support\u0026amp%3Butm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K50233772?utm_source=f5support\u0026amp;utm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4308-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4508"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4520"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/security/advisory/Synology_SA_19_33"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2766"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2796"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2861"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2925"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2939"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2955"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3892"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4018"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4019"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4020"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4021"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4040"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4041"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4042"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4045"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4352"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0727"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/605641"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10296"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/392108390cef48af647a2e47b7fd5380e050e35ae8d1aa2030254c04%40%3Cusers.trafficserver.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00031.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Aug/16"
    }
  ],
  "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-925F-CXG2-4483

Vulnerability from github – Published: 2024-03-26 00:32 – Updated: 2024-08-05 18:31
VLAI
Details

A vulnerability exists in the affected product that allows a malicious user to restart the Rockwell Automation PanelView™ Plus 7 terminal remotely without security protections. If the vulnerability is exploited, it could lead to the loss of view or control of the PanelView™ product.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-21914"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-25T22:37:19Z",
    "severity": "MODERATE"
  },
  "details": "\nA vulnerability exists in the affected product that allows a malicious user to restart the Rockwell Automation PanelView\u2122 Plus 7 terminal remotely without security protections. If the vulnerability is exploited, it could lead to the loss of view or control of the PanelView\u2122 product.\n\n",
  "id": "GHSA-925f-cxg2-4483",
  "modified": "2024-08-05T18:31:42Z",
  "published": "2024-03-26T00:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21914"
    },
    {
      "type": "WEB",
      "url": "https://www.rockwellautomation.com/en-us/support/advisory.SD1663.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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-92HJ-6R7M-GQHH

Vulnerability from github – Published: 2024-01-03 00:30 – Updated: 2024-01-09 18:30
VLAI
Details

An issue in YASM 1.3.0.86.g9def allows a remote attacker to cause a denial of service via the yasm_section_bcs_first function in the libyasm/section.c component.

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": [],
  "aliases": [
    "CVE-2023-49557"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-03T00:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue in YASM 1.3.0.86.g9def allows a remote attacker to cause a denial of service via the yasm_section_bcs_first function in the libyasm/section.c component.",
  "id": "GHSA-92hj-6r7m-gqhh",
  "modified": "2024-01-09T18:30:27Z",
  "published": "2024-01-03T00:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49557"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yasm/yasm/issues/253"
    }
  ],
  "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-92J7-34X9-F3JW

Vulnerability from github – Published: 2022-04-29 03:01 – Updated: 2023-09-18 23:29
VLAI
Summary
Apache James Denial of Service
Details

Spooler in Apache Foundation James before 2.2.0 allows local users to cause a denial of service (memory consumption) by triggering various error conditions in the retrieve function, which prevents a lock from being released and causes a memory leak.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.james:james-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2004-2650"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-18T23:29:49Z",
    "nvd_published_at": "2004-12-31T05:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Spooler in Apache Foundation James before 2.2.0 allows local users to cause a denial of service (memory consumption) by triggering various error conditions in the retrieve function, which prevents a lock from being released and causes a memory leak.",
  "id": "GHSA-92j7-34x9-f3jw",
  "modified": "2023-09-18T23:29:49Z",
  "published": "2022-04-29T03:01:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-2650"
    },
    {
      "type": "WEB",
      "url": "http://issues.apache.org/jira/browse/JAMES-268"
    },
    {
      "type": "WEB",
      "url": "http://james.apache.org/changelog.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/15765"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Apache James Denial of Service"
}

GHSA-92RG-2WCJ-32JV

Vulnerability from github – Published: 2025-07-09 18:30 – Updated: 2025-07-09 21:31
VLAI
Details

Zimbra Collaboration Suite (ZCS) before 9.0.0 Patch 46, 10.0.x before 10.0.15, and 10.1.x before 10.1.9 is vulnerable to a denial of service condition due to improper handling of excessive, comma-separated path segments in both the Webmail interface and the Admin Console. An unauthenticated remote attacker can send specially crafted GET requests that trigger redundant processing and inflated responses. This leads to uncontrolled resource consumption, resulting in denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-53645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-09T17:15:31Z",
    "severity": "HIGH"
  },
  "details": "Zimbra Collaboration Suite (ZCS) before 9.0.0 Patch 46, 10.0.x before 10.0.15, and 10.1.x before 10.1.9 is vulnerable to a denial of service condition due to improper handling of excessive, comma-separated path segments in both the Webmail interface and the Admin Console. An unauthenticated remote attacker can send specially crafted GET requests that trigger redundant processing and inflated responses. This leads to uncontrolled resource consumption, resulting in denial of service.",
  "id": "GHSA-92rg-2wcj-32jv",
  "modified": "2025-07-09T21:31:17Z",
  "published": "2025-07-09T18:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53645"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Security_Center"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Releases/10.0.15#Security_Fixes"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Releases/10.1.9#Security_Fixes"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Releases/9.0.0/P46#Security_Fixes"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Responsible_Disclosure_Policy"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-92RQ-C8CF-PRRQ

Vulnerability from github – Published: 2025-03-12 20:16 – Updated: 2025-11-03 21:33
VLAI
Summary
Ruby SAML allows remote Denial of Service (DoS) with compressed SAML responses
Details

Summary

ruby-saml is susceptible to remote Denial of Service (DoS) with compressed SAML responses.

Ruby-saml uses zlib to decompress SAML responses in case they're compressed. It is possible to bypass the message size check with a compressed assertion since the message size is checked before inflation and not after.

Impact

This issue may lead to remote Denial of Service (DoS).

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
7.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/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25293"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-12T20:16:50Z",
    "nvd_published_at": "2025-03-12T21:15:42Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nruby-saml is susceptible to remote Denial of Service (DoS) with compressed SAML responses.\n\nRuby-saml uses zlib to decompress SAML responses in case they\u0027re compressed. It is possible to bypass the message size check with a compressed assertion since the message size is checked before inflation and not after.\n\n### Impact\nThis issue may lead to remote Denial of Service (DoS).",
  "id": "GHSA-92rq-c8cf-prrq",
  "modified": "2025-11-03T21:33:11Z",
  "published": "2025-03-12T20:16:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-92rq-c8cf-prrq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/omniauth/omniauth-saml/security/advisories/GHSA-hw46-3hmr-x9xv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25293"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/acac9e9cc0b9a507882c614f25d41f8b47be349a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e2da4c6dae7dc01a4d9cd221395140a67e2b3eb1"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released"
    },
    {
      "type": "WEB",
      "url": "https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SAML-Toolkits/ruby-saml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/releases/tag/v1.12.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/releases/tag/v1.18.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ruby-saml/CVE-2025-25293.yml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250314-0008"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2024-355_ruby-saml"
    }
  ],
  "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:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ruby SAML allows remote Denial of Service (DoS) with compressed SAML responses"
}

GHSA-92VJ-G62V-JQHH

Vulnerability from github – Published: 2025-09-12 21:12 – Updated: 2025-09-12 21:12
VLAI
Summary
Hono has Body Limit Middleware Bypass
Details

Summary

A flaw in the bodyLimit middleware could allow bypassing the configured request body size limit when conflicting HTTP headers were present.

Details

The middleware previously prioritized the Content-Length header even when a Transfer-Encoding: chunked header was also included. According to the HTTP specification, Content-Length must be ignored in such cases. This discrepancy could allow oversized request bodies to bypass the configured limit.

Most standards-compliant runtimes and reverse proxies may reject such malformed requests with 400 Bad Request, so the practical impact depends on the runtime and deployment environment.

Impact

If body size limits are used as a safeguard against large or malicious requests, this flaw could allow attackers to send oversized request bodies. The primary risk is denial of service (DoS) due to excessive memory or CPU consumption when handling very large requests.

Resolution

The implementation has been updated to align with the HTTP specification, ensuring that Transfer-Encoding takes precedence over Content-Length. The issue is fixed in Hono v4.9.7, and all users should upgrade immediately.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hono"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.9.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-12T21:12:20Z",
    "nvd_published_at": "2025-09-12T14:15:41Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA flaw in the `bodyLimit` middleware could allow bypassing the configured request body size limit when conflicting HTTP headers were present.\n\n### Details\nThe middleware previously prioritized the `Content-Length` header even when a `Transfer-Encoding: chunked` header was also included. According to the HTTP specification, `Content-Length` must be ignored in such cases. This discrepancy could allow oversized request bodies to bypass the configured limit.\n\nMost standards-compliant runtimes and reverse proxies may reject such malformed requests with `400 Bad Request`, so the practical impact depends on the runtime and deployment environment.\n\n### Impact\nIf body size limits are used as a safeguard against large or malicious requests, this flaw could allow attackers to send oversized request bodies. The primary risk is denial of service (DoS) due to excessive memory or CPU consumption when handling very large requests.\n\n### Resolution\nThe implementation has been updated to align with the HTTP specification, ensuring that `Transfer-Encoding` takes precedence over `Content-Length`. The issue is fixed in Hono v4.9.7, and all users should upgrade immediately.",
  "id": "GHSA-92vj-g62v-jqhh",
  "modified": "2025-09-12T21:12:20Z",
  "published": "2025-09-12T21:12:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/security/advisories/GHSA-92vj-g62v-jqhh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59139"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/commit/605c70560b52f13af10379f79b76717042fafe8d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/honojs/hono"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Hono has Body Limit Middleware Bypass"
}
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