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.

6476 vulnerabilities reference this CWE, most recent first.

GHSA-3553-HFC6-7RH5

Vulnerability from github – Published: 2025-10-14 21:30 – Updated: 2025-10-14 21:30
VLAI
Details

NVIDIA Jetson Linux and IGX OS contain a vulnerability in NvMap, where improper tracking of memory allocations could allow a local attacker to cause memory overallocation. A successful exploitation of this vulnerability might lead to denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-33177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T20:15:33Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA Jetson Linux and IGX OS contain a vulnerability in NvMap, where improper tracking of memory allocations could allow a local attacker to cause memory overallocation. A successful exploitation of this vulnerability might lead to denial of service.",
  "id": "GHSA-3553-hfc6-7rh5",
  "modified": "2025-10-14T21:30:46Z",
  "published": "2025-10-14T21:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33177"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5716"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-358W-HQPF-Q255

Vulnerability from github – Published: 2026-05-12 21:31 – Updated: 2026-05-12 21:31
VLAI
Details

Adobe Commerce versions 2.4.9-beta1, 2.4.8-p4, 2.4.7-p9, 2.4.6-p14, 2.4.5-p16, 2.4.4-p17 and earlier are affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.

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-34648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T20:16:35Z",
    "severity": "HIGH"
  },
  "details": "Adobe Commerce versions 2.4.9-beta1, 2.4.8-p4, 2.4.7-p9, 2.4.6-p14, 2.4.5-p16, 2.4.4-p17 and earlier are affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-358w-hqpf-q255",
  "modified": "2026-05-12T21:31:33Z",
  "published": "2026-05-12T21:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34648"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb26-49.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-35G8-35P8-C8FW

Vulnerability from github – Published: 2026-09-30 23:40 – Updated: 2026-09-30 23:40
VLAI
Summary
Russh: Unbounded memory exhaustion via CHANNEL_OPEN flood during a client-stalled rekey
Details

Summary

A russh server can be driven to unbounded heap growth (process OOM / kill) by a peer that speaks only standard SSH messages, in the default configuration.

The peer starts a key re-exchange (sends SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, leaving the server's kex state machine in SessionKexState::InProgress indefinitely. While a rekey is in progress the server's three message-drain paths are all gated off (if !self.kex.active()), but the network-read path stays active, so every SSH_MSG_CHANNEL_OPEN the peer sends is processed inline and appends one reply to an unbounded internal queue (priority_receiver, an UnboundedReceiver) that is not dequeued until the rekey completes. Because the peer decides whether the rekey ever completes, the queue — and the server's memory — grows without bound.

This is reproducible end-to-end against a real russh server over a real encrypted transport; see "Proof of concept". A one-line negative control (same flood, no rekey) keeps memory flat, isolating the rekey window as the sole trigger.

Impact

  • Availability / DoS. Server RSS climbs at roughly 3.3 KB per CHANNEL_OPEN, driven entirely by the peer, until the process is OOM-killed. In the reproduction one connection pushed the server from ~4 MB to 2.57 GB (and past 4.8 GB against the stock echoserver example) and it was still climbing when the flood was stopped.
  • Reached with standard messages, no special configuration. Any handler is affected, including one that rejects every channel (the reply enqueued on rejection is exactly what accumulates). There is no per-connection cap on in-flight channel opens or on the queue, and the queue's sender has no backpressure.
  • The peer keeps the connection alive simply by continuing to send, so the inactivity timer never fires.

Affected component

  • russh/src/server/session.rs — Session::run tokio::select! loop. The network-read arm is ungated; the three drain paths are gated on !self.kex.active().
  • russh/src/server/mod.rs — reply() routes a non-kex message received during a rekey straight to server_read_encrypted (inline processing).
  • russh/src/lib_inner.rs — ChannelOpenHandleInner's accept/reject/Drop all send a reply on an UnboundedSender.

Verified on v0.63.1 (commit d3ae702), which is the latest release. The gating logic predates it.

Details

Session::run (russh/src/server/session.rs:631) drives a tokio::select! (:713). Three of its message-drain sites are gated on !self.kex.active():

  • the pre-select! batch drain of priority_receiver/receiver (session.rs:680),
  • the priority_receiver.recv() arm (session.rs:762),
  • the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver drain at :777).

The fourth arm, r = &mut reading (session.rs:714), is ungated: it reads and processes one incoming packet every loop iteration regardless of rekey state, calling reply() (server/mod.rs:1128).

During a rekey, session.common.encrypted.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN this reaches the channel-open handling, which hands the application a ChannelOpenHandle.

Whether the handler accepts or (the trait default) rejects, the handle's accept / reject / Drop all send a Msg::ChannelOpenReply on an UnboundedSender (russh/src/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN processed during the rekey window appends one reply (carrying a PendingChannelOpen = channel params + mpsc ChannelRef + ids, a few KB retained in practice) to a queue that is never dequeued.

Two facts make this unbounded and remote:

  1. The server enters InProgress the moment it receives the peer's KEXINIT (server/mod.rs:1153-1158, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. The peer decides whether to ever send that, so the window is attacker-held.
  2. There is no per-connection cap on channels or on the priority queue, and the sender is unbounded (no backpressure).

Root cause

The intended design was to buffer packets received during a rekey and replay them afterwards: the fields pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (they are dead — confirmed by grep across russh/src/). Instead of being buffered, channel messages received during a rekey are processed inline, and their replies pile up in the unbounded priority_receiver. The missing piece is a bound on — or bounded deferral of — channel processing while kex.active().

Proof of concept

Everything runs inside a container; nothing touches the host.

Lab. poc/Dockerfile builds russh-lab:head from Eugeny/russh @ d3ae702 (v0.63.1), default features (rust 1.91). A raw-SSH-client PoC (poc/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

  1. sends SSH_MSG_KEXINIT (server enters kex.active()),
  2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
  3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (which rejects by dropping the handle), so the measured growth is purely the undrained priority queue, not accepted-channel state.

poc/run.sh runs the attack leg and an identical negative control with no rekey. Fresh run inside the lab, N = 800,000 opens (results/rerun-2026-08-29.log):

=== ATTACK (rekey stall) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=4208KB   (flat throughout)
  • ATTACK: RSS 4,208 KB → 2,566,256 KB (~2.57 GB) and retained after the flood ends — ~3.3 KB per CHANNEL_OPEN, attacker-driven. (An earlier canonical run reached 2.7 GB at 800k opens, and past 4.8 GB against the stock echoserver example at 1.5 M opens — see results/canonical-run.log.)
  • CONTROL: RSS flat at 4,208 KB. Without the rekey window the replies are drained normally; TCP backpressure (the client never reads the failure replies) even throttles the flood.

The control isolates the rekey window as the sole trigger. Both legs exercise the real server entry point (Session::run → reply → server_read_encrypted) over a real encrypted transport.

Reproduce: C=russh-lab N=800000 ./poc/run.sh (see poc/POC-README.md).

Remediation

The priority queue carries locally generated channel-open replies, which are non-kex messages the server must not send during a rekey anyway (RFC 4253 §7.1). So the fix is to bound how much channel work is done during a rekey, not to drain the queue mid-rekey. Any of:

  • (recommended, minimal) cap the number of non-kex messages processed while a rekey is in progress and disconnect a peer that exceeds it. A stalled/abusive rekey is then torn down after a small constant instead of growing memory without bound. See patch/rekey-message-cap.patch (a ~10-line change local to Session::run, validated in the lab — the attack leg is disconnected after the cap and RSS stays flat; a normal rekey, which completes in one round trip, is unaffected).
  • bound / deferred-buffer channel messages during a rekey using the existing (currently dead) pending_reads/pending_len machinery, with a hard cap.
  • bound the number of in-flight channel opens per connection and reject beyond it.

OpenSSH does not service new channels mid-kex; matching that intent closes the whole family.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.63.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "russh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.63.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102821"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T23:40:43Z",
    "nvd_published_at": "2026-09-29T19:17:23Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA russh **server** can be driven to unbounded heap growth (process OOM / kill) by\na peer that speaks only standard SSH messages, in the **default configuration**.\n\nThe peer starts a key re-exchange (sends `SSH_MSG_KEXINIT`) but never sends the\nfollow-up `SSH_MSG_KEX_ECDH_INIT`, leaving the server\u0027s kex state machine in\n`SessionKexState::InProgress` **indefinitely**. While a rekey is in progress the\nserver\u0027s three message-drain paths are all gated off (`if !self.kex.active()`),\nbut the network-read path stays active, so every `SSH_MSG_CHANNEL_OPEN` the peer\nsends is processed inline and appends one reply to an **unbounded** internal\nqueue (`priority_receiver`, an `UnboundedReceiver`) that is not dequeued until\nthe rekey completes. Because the peer decides whether the rekey ever completes,\nthe queue \u2014 and the server\u0027s memory \u2014 grows without bound.\n\nThis is reproducible end-to-end against a real russh server over a real\nencrypted transport; see \"Proof of concept\". A one-line negative control (same\nflood, no rekey) keeps memory flat, isolating the rekey window as the sole\ntrigger.\n\n## Impact\n\n- **Availability / DoS.** Server RSS climbs at roughly 3.3 KB per\n  `CHANNEL_OPEN`, driven entirely by the peer, until the process is OOM-killed.\n  In the reproduction one connection pushed the server from ~4 MB to **2.57 GB**\n  (and past **4.8 GB** against the stock `echoserver` example) and it was still\n  climbing when the flood was stopped.\n- **Reached with standard messages, no special configuration.** Any handler is\n  affected, including one that rejects every channel (the reply enqueued on\n  rejection is exactly what accumulates). There is no per-connection cap on\n  in-flight channel opens or on the queue, and the queue\u0027s sender has no\n  backpressure.\n- The peer keeps the connection alive simply by continuing to send, so the\n  inactivity timer never fires.\n\n## Affected component\n\n- `russh/src/server/session.rs` \u2014 `Session::run` `tokio::select!` loop. The\n  network-read arm is ungated; the three drain paths are gated on\n  `!self.kex.active()`.\n- `russh/src/server/mod.rs` \u2014 `reply()` routes a non-kex message received during\n  a rekey straight to `server_read_encrypted` (inline processing).\n- `russh/src/lib_inner.rs` \u2014 `ChannelOpenHandleInner`\u0027s `accept`/`reject`/`Drop`\n  all `send` a reply on an `UnboundedSender`.\n\nVerified on **v0.63.1** (commit `d3ae702`), which is the latest release. The\ngating logic predates it.\n\n## Details\n\n`Session::run` (`russh/src/server/session.rs:631`) drives a `tokio::select!`\n(`:713`). Three of its message-drain sites are gated on `!self.kex.active()`:\n\n- the pre-`select!` batch drain of `priority_receiver`/`receiver`\n  (`session.rs:680`),\n- the `priority_receiver.recv()` arm (`session.rs:762`),\n- the `receiver.recv()` arm (`session.rs:770`, which also holds the only other\n  `priority_receiver` drain at `:777`).\n\nThe fourth arm, `r = \u0026mut reading` (`session.rs:714`), is **ungated**: it reads\nand processes one incoming packet every loop iteration regardless of rekey\nstate, calling `reply()` (`server/mod.rs:1128`).\n\nDuring a **rekey**, `session.common.encrypted.is_some()`, so the strict-kex\nmessage-ordering guard (`server/mod.rs:1143`, which is additionally gated on\n`encrypted.is_none()`) does **not** apply. A non-kex message therefore falls\nthrough `reply()` to `session.server_read_encrypted(handler, pkt)`\n(`server/mod.rs:1232`) and is handled inline. For `SSH_MSG_CHANNEL_OPEN` this\nreaches the channel-open handling, which hands the application a\n`ChannelOpenHandle`.\n\nWhether the handler accepts or (the trait default) rejects, the handle\u0027s\n`accept` / `reject` / `Drop` all `send` a `Msg::ChannelOpenReply` on an\n`UnboundedSender` (`russh/src/lib_inner.rs:560-603`; `Drop` sends\n`AdministrativelyProhibited` at `:594-603`). That sender feeds\n`priority_receiver`, declared `UnboundedReceiver\u003cMsg\u003e` (`session.rs:23`) and\ncreated with `tokio::sync::mpsc::unbounded_channel()` (`session.rs:1522`). Its\nonly drain sites are the three arms gated off during the rekey. So each\n`CHANNEL_OPEN` processed during the rekey window appends one reply (carrying a\n`PendingChannelOpen` = channel params + mpsc `ChannelRef` + ids, a few KB\nretained in practice) to a queue that is never dequeued.\n\nTwo facts make this unbounded and remote:\n\n1. The server enters `InProgress` the moment it receives the peer\u0027s `KEXINIT`\n   (`server/mod.rs:1153-1158`, `begin_rekey`) and only leaves it upon receiving\n   the peer\u0027s `KEX_ECDH_INIT`. **The peer decides** whether to ever send that,\n   so the window is attacker-held.\n2. There is no per-connection cap on channels or on the priority queue, and the\n   sender is unbounded (no backpressure).\n\n### Root cause\n\nThe intended design was to *buffer* packets received during a rekey and replay\nthem afterwards: the fields `pending_reads: Vec\u003cVec\u003cu8\u003e\u003e` and `pending_len: u32`\n(`session.rs:26-27`) exist and are **drained** at kex completion\n(`server/mod.rs:1194-1198`). But nothing ever **pushes** to `pending_reads` or\nincrements `pending_len` (they are dead \u2014 confirmed by grep across\n`russh/src/`). Instead of being buffered, channel messages received during a\nrekey are processed inline, and their replies pile up in the unbounded\n`priority_receiver`. The missing piece is a bound on \u2014 or bounded deferral of \u2014\nchannel processing while `kex.active()`.\n\n## Proof of concept\n\nEverything runs inside a container; nothing touches the host.\n\n**Lab.** `poc/Dockerfile` builds `russh-lab:head` from Eugeny/russh @ `d3ae702`\n(v0.63.1), default features (rust 1.91). A raw-SSH-client PoC\n(`poc/poc_rekey_dos.rs`) implements curve25519-sha256 / ssh-ed25519 /\naes256-ctr / hmac-sha2-256 by hand, completes the handshake and a `publickey`\nauth, then:\n\n1. sends `SSH_MSG_KEXINIT` (server enters `kex.active()`),\n2. **never** sends `KEX_ECDH_INIT` (rekey stalls, attacker-held),\n3. floods `SSH_MSG_CHANNEL_OPEN`.\n\nA minimal server (`poc/poc_server.rs`) uses the **trait-default**\n`channel_open_session` (which rejects by dropping the handle), so the measured\ngrowth is purely the undrained priority queue, not accepted-channel state.\n\n`poc/run.sh` runs the attack leg and an identical **negative control** with no\nrekey. Fresh run inside the lab, `N = 800,000` opens\n(`results/rerun-2026-08-29.log`):\n\n```\n=== ATTACK (rekey stall) === (poc_server baseline_RSS=4208KB, N=800000)\n  t=2s  server_RSS=667760KB\n  t=4s  server_RSS=1599600KB\n  t=6s  server_RSS=2556016KB\n  t=8s  server_RSS=2566256KB   (flood done; memory retained)\n=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)\n  t=2s..t=12s  server_RSS=4208KB   (flat throughout)\n```\n\n- **ATTACK**: RSS `4,208 KB \u2192 2,566,256 KB` (~2.57 GB) and retained after the\n  flood ends \u2014 ~3.3 KB per `CHANNEL_OPEN`, attacker-driven. (An earlier canonical\n  run reached 2.7 GB at 800k opens, and past 4.8 GB against the stock\n  `echoserver` example at 1.5 M opens \u2014 see `results/canonical-run.log`.)\n- **CONTROL**: RSS flat at `4,208 KB`. Without the rekey window the replies are\n  drained normally; TCP backpressure (the client never reads the failure\n  replies) even throttles the flood.\n\nThe control isolates the rekey window as the sole trigger. Both legs exercise\nthe real server entry point (`Session::run` \u2192 `reply` \u2192 `server_read_encrypted`)\nover a real encrypted transport.\n\nReproduce: `C=russh-lab N=800000 ./poc/run.sh` (see `poc/POC-README.md`).\n\n## Remediation\n\nThe priority queue carries locally generated channel-open replies, which are\nnon-kex messages the server **must not send** during a rekey anyway (RFC 4253\n\u00a77.1). So the fix is to bound how much channel work is done during a rekey, not\nto drain the queue mid-rekey. Any of:\n\n- **(recommended, minimal)** cap the number of non-kex messages processed while a\n  rekey is in progress and disconnect a peer that exceeds it. A stalled/abusive\n  rekey is then torn down after a small constant instead of growing memory\n  without bound. See `patch/rekey-message-cap.patch` (a ~10-line change local to\n  `Session::run`, validated in the lab \u2014 the attack leg is disconnected after the\n  cap and RSS stays flat; a normal rekey, which completes in one round trip, is\n  unaffected).\n- bound / deferred-buffer channel messages during a rekey using the existing\n  (currently dead) `pending_reads`/`pending_len` machinery, with a hard cap.\n- bound the number of in-flight channel opens per connection and reject beyond it.\n\nOpenSSH does not service new channels mid-kex; matching that intent closes the\nwhole family.",
  "id": "GHSA-35g8-35p8-c8fw",
  "modified": "2026-09-30T23:40:43Z",
  "published": "2026-09-30T23:40:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/security/advisories/GHSA-35g8-35p8-c8fw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102821"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/commit/a282af361ac99bc76b80876d1aae128e89dbf66b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Eugeny/russh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/releases/tag/v0.63.2"
    }
  ],
  "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": "Russh: Unbounded memory exhaustion via CHANNEL_OPEN flood during a client-stalled rekey"
}

GHSA-35GF-M9JX-8QMX

Vulnerability from github – Published: 2026-09-15 18:32 – Updated: 2026-09-15 18:32
VLAI
Details

Crawl4AI before 0.9.3 contains an uncontrolled resource consumption vulnerability in PDFContentScrapingStrategy that allows untrusted clients to cause denial of service. Attackers can select the PDF scraping strategy in POST requests to download large remote PDFs without size or page limits, exhausting disk, CPU, and bandwidth on shared workers.

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": [],
  "aliases": [
    "CVE-2026-91941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T16:17:46Z",
    "severity": "HIGH"
  },
  "details": "Crawl4AI before 0.9.3 contains an uncontrolled resource consumption vulnerability in PDFContentScrapingStrategy that allows untrusted clients to cause denial of service. Attackers can select the PDF scraping strategy in POST requests to download large remote PDFs without size or page limits, exhausting disk, CPU, and bandwidth on shared workers.",
  "id": "GHSA-35gf-m9jx-8qmx",
  "modified": "2026-09-15T18:32:28Z",
  "published": "2026-09-15T18:32:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai/security/advisories/GHSA-v2rm-hvrj-2x9q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91941"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/crawl4ai-before-0.9.3-denial-of-service-via-pdfcontentscrapingstrategy"
    }
  ],
  "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"
    }
  ]
}

GHSA-35GG-5CVH-W445

Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2025-10-22 00:31
VLAI
Details

Multiple vulnerabilities in the Distance Vector Multicast Routing Protocol (DVMRP) feature of Cisco IOS XR Software could allow an unauthenticated, remote attacker to either immediately crash the Internet Group Management Protocol (IGMP) process or make it consume available memory and eventually crash. The memory consumption may negatively impact other processes that are running on the device. These vulnerabilities are due to the incorrect handling of IGMP packets. An attacker could exploit these vulnerabilities by sending crafted IGMP traffic to an affected device. A successful exploit could allow the attacker to immediately crash the IGMP process or cause memory exhaustion, resulting in other processes becoming unstable. These processes may include, but are not limited to, interior and exterior routing protocols. Cisco will release software updates that address these vulnerabilities.

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-2020-3569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-23T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple vulnerabilities in the Distance Vector Multicast Routing Protocol (DVMRP) feature of Cisco IOS XR Software could allow an unauthenticated, remote attacker to either immediately crash the Internet Group Management Protocol (IGMP) process or make it consume available memory and eventually crash. The memory consumption may negatively impact other processes that are running on the device. These vulnerabilities are due to the incorrect handling of IGMP packets. An attacker could exploit these vulnerabilities by sending crafted IGMP traffic to an affected device. A successful exploit could allow the attacker to immediately crash the IGMP process or cause memory exhaustion, resulting in other processes becoming unstable. These processes may include, but are not limited to, interior and exterior routing protocols. Cisco will release software updates that address these vulnerabilities.",
  "id": "GHSA-35gg-5cvh-w445",
  "modified": "2025-10-22T00:31:58Z",
  "published": "2022-05-24T17:29:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3569"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-dvmrp-memexh-dSmpdvfz"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-3569"
    }
  ],
  "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-35GH-9RR7-FW4G

Vulnerability from github – Published: 2023-10-30 18:30 – Updated: 2023-11-07 03:30
VLAI
Details

In Minikin, there is a possible way to trigger ANR by showing a malicious message due to resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

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-2023-21339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-30T17:15:49Z",
    "severity": "HIGH"
  },
  "details": "In Minikin, there is a possible way to trigger ANR by showing a malicious message due to resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-35gh-9rr7-fw4g",
  "modified": "2023-11-07T03:30:25Z",
  "published": "2023-10-30T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21339"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/android-14"
    }
  ],
  "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-35H7-WFJQ-J87H

Vulnerability from github – Published: 2026-09-15 18:32 – Updated: 2026-09-15 18:32
VLAI
Details

IBM Verify Identity Access could allow a remote attacker to cause a denial of service due to insufficient validation of incoming request resources.

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-11926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T18:17:12Z",
    "severity": "HIGH"
  },
  "details": "IBM Verify Identity Access could allow a remote attacker to cause a denial of service due to insufficient validation of incoming request resources.",
  "id": "GHSA-35h7-wfjq-j87h",
  "modified": "2026-09-15T18:32:34Z",
  "published": "2026-09-15T18:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11926"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7286188"
    }
  ],
  "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-35P3-6J45-PRWM

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 18:35
VLAI
Summary
Aim Uncontrolled Resource Consumption vulnerability
Details

A vulnerability in aimhubio/aim version 3.25.0 allows for a denial of service (DoS) attack. The issue arises when a large number of tracked metrics are retrieved simultaneously from the Aim web API, causing the web server to become unresponsive. The root cause is the lack of a limit on the number of metrics that can be requested per call, combined with the server's single-threaded nature, leading to excessive resource consumption and blocking of the server.

Severity
7.5 (High)
CVSS:3.0/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": "PyPI",
        "name": "aim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-12778"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T18:35:15Z",
    "nvd_published_at": "2025-03-20T10:15:30Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in aimhubio/aim version 3.25.0 allows for a denial of service (DoS) attack. The issue arises when a large number of tracked metrics are retrieved simultaneously from the Aim web API, causing the web server to become unresponsive. The root cause is the lack of a limit on the number of metrics that can be requested per call, combined with the server\u0027s single-threaded nature, leading to excessive resource consumption and blocking of the server.",
  "id": "GHSA-35p3-6j45-prwm",
  "modified": "2025-03-21T18:35:15Z",
  "published": "2025-03-20T12:32:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12778"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aimhubio/aim"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/892a9eee-0251-4e57-94a4-dad2e7f32715"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Aim Uncontrolled Resource Consumption vulnerability"
}

GHSA-35Q2-47Q7-3PC3

Vulnerability from github – Published: 2021-04-27 15:56 – Updated: 2022-08-11 00:21
VLAI
Summary
Node-Redis potential exponential regex in monitor mode
Details

Impact

When a client is in monitoring mode, the regex begin used to detected monitor messages could cause exponential backtracking on some strings. This issue could lead to a denial of service.

Patches

The problem was fixed in commit 2d11b6d and was released in version 3.1.1.

References

1569 (GHSL-2021-026)

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": "npm",
        "name": "redis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-23T18:11:39Z",
    "nvd_published_at": "2021-04-23T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nWhen a client is in monitoring mode, the regex begin used to detected monitor messages could cause exponential backtracking on some strings. This issue could lead to a denial of service.\n\n### Patches\nThe problem was fixed in commit [`2d11b6d`](https://github.com/NodeRedis/node-redis/commit/2d11b6dc9b9774464a91fb4b448bad8bf699629e) and was released in version `3.1.1`.\n\n### References\n#1569 (GHSL-2021-026)",
  "id": "GHSA-35q2-47q7-3pc3",
  "modified": "2022-08-11T00:21:37Z",
  "published": "2021-04-27T15:56:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/NodeRedis/node-redis/security/advisories/GHSA-35q2-47q7-3pc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29469"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NodeRedis/node-redis/commit/2d11b6dc9b9774464a91fb4b448bad8bf699629e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NodeRedis/node-redis/releases/tag/v3.1.1"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210611-0010"
    }
  ],
  "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": "Node-Redis potential exponential regex in monitor mode"
}

GHSA-35W2-Q5F9-8244

Vulnerability from github – Published: 2025-07-05 00:30 – Updated: 2025-07-05 00:30
VLAI
Details

A vulnerability has been found in IROAD Dashcam Q9 up to 20250624 and classified as problematic. Affected by this vulnerability is an unknown functionality of the component MFA Pairing Request Handler. The manipulation leads to allocation of resources. The attack needs to be done within the local network. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
4.3 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
5.3 (Medium)
CVSS:4.0/AV:A/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": [],
  "aliases": [
    "CVE-2025-7070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-04T22:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in IROAD Dashcam Q9 up to 20250624 and classified as problematic. Affected by this vulnerability is an unknown functionality of the component MFA Pairing Request Handler. The manipulation leads to allocation of resources. The attack needs to be done within the local network. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-35w2-q5f9-8244",
  "modified": "2025-07-05T00:30:23Z",
  "published": "2025-07-05T00:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7070"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geo-chen/IROAD-V?tab=readme-ov-file#finding-8---mfa-spam-to-induce-device-pairing-fatigue"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.314905"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.314905"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.603298"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/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"
    }
  ]
}
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