Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

The product does not properly control the allocation and maintenance of a limited resource.

6426 vulnerabilities reference this CWE, most recent first.

GHSA-J27P-HQ53-9WGC

Vulnerability from github – Published: 2026-02-18 00:51 – Updated: 2026-03-05 21:59
VLAI
Summary
OpenClaw affected by denial of service via unbounded URL-backed media fetch
Details

Summary

URL-backed media fetch handling allocated the entire response payload in memory (arrayBuffer) before enforcing maxBytes, allowing oversized responses to cause memory exhaustion.

Affected Versions

  • openclaw (npm): < 2026.2.14
  • clawdbot (npm): <= 2026.1.24-3

Patched Versions

  • openclaw (npm): 2026.2.14

Fix Commit

  • openclaw/openclaw main: 00a08908892d1743d1fc52e5cbd9499dd5da2fe0

Details

Affected component: - src/media/input-files.ts (fetchWithGuard)

When content-length is missing or incorrect, reading the body via response.arrayBuffer() buffers the full payload before a size check can run.

Proof of Concept

  1. Configure URL-based media input.
  2. Serve a response larger than maxBytes (chunked transfer / no content-length).
  3. Trigger the fetchWithGuard URL fetch path.

Example local server (large response):

node -e 'require("http").createServer((_,res)=>{res.writeHead(200,{"content-type":"application/octet-stream"});for(let i=0;i<1024;i++)res.write(Buffer.alloc(1024*64));res.end();}).listen(18888)'

Impact

Availability loss via memory pressure from attacker-controlled remote media responses.

Mitigation

Until a patched release is available, disable URL-backed media inputs (or restrict to a tight hostname allowlist) and use conservative maxBytes limits.

Credits

Reported by @vincentkoc.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T00:51:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nURL-backed media fetch handling allocated the entire response payload in memory (`arrayBuffer`) before enforcing `maxBytes`, allowing oversized responses to cause memory exhaustion.\n\n### Affected Versions\n- `openclaw` (npm): \u003c `2026.2.14`\n- `clawdbot` (npm): \u003c= `2026.1.24-3`\n\n### Patched Versions\n- `openclaw` (npm): `2026.2.14`\n\n### Fix Commit\n- `openclaw/openclaw` `main`: `00a08908892d1743d1fc52e5cbd9499dd5da2fe0`\n\n### Details\nAffected component:\n- `src/media/input-files.ts` (`fetchWithGuard`)\n\nWhen `content-length` is missing or incorrect, reading the body via `response.arrayBuffer()` buffers the full payload before a size check can run.\n\n### Proof of Concept\n1. Configure URL-based media input.\n2. Serve a response larger than `maxBytes` (chunked transfer / no `content-length`).\n3. Trigger the `fetchWithGuard` URL fetch path.\n\nExample local server (large response):\n```bash\nnode -e \u0027require(\"http\").createServer((_,res)=\u003e{res.writeHead(200,{\"content-type\":\"application/octet-stream\"});for(let i=0;i\u003c1024;i++)res.write(Buffer.alloc(1024*64));res.end();}).listen(18888)\u0027\n```\n\n### Impact\nAvailability loss via memory pressure from attacker-controlled remote media responses.\n\n### Mitigation\nUntil a patched release is available, disable URL-backed media inputs (or restrict to a tight hostname allowlist) and use conservative `maxBytes` limits.\n\n### Credits\nReported by @vincentkoc.",
  "id": "GHSA-j27p-hq53-9wgc",
  "modified": "2026-03-05T21:59:50Z",
  "published": "2026-02-18T00:51:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-j27p-hq53-9wgc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/00a08908892d1743d1fc52e5cbd9499dd5da2fe0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "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": "OpenClaw affected by denial of service via unbounded URL-backed media fetch"
}

GHSA-J2F2-FP4Q-V86P

Vulnerability from github – Published: 2023-11-15 00:31 – Updated: 2023-11-15 00:31
VLAI
Details

Unauthenticated Denial-of-Service (DoS) vulnerabilities exist in the BLE daemon service accessed via the PAPI protocol. Successful exploitation of these vulnerabilities result in the ability to interrupt the normal operation of the affected access point.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-45622"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T23:15:10Z",
    "severity": "HIGH"
  },
  "details": "Unauthenticated Denial-of-Service (DoS) vulnerabilities exist in the BLE daemon service accessed via the PAPI protocol. Successful exploitation of these vulnerabilities result in the ability to interrupt the normal operation of the affected access point.\n\n",
  "id": "GHSA-j2f2-fp4q-v86p",
  "modified": "2023-11-15T00:31:08Z",
  "published": "2023-11-15T00:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45622"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2023-017.txt"
    }
  ],
  "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-J2FC-V5XJ-H5GR

Vulnerability from github – Published: 2026-06-03 18:33 – Updated: 2026-06-03 21:30
VLAI
Details

Mercusys AC12G (EU) V1 router with firmware AC12G(EU)_V1_200909 is vulnerable to a HTTP denial of service via a low number of crafted incomplete HTTP requests, causing a persistent crash that requires physical power cycling to recover.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-36605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-03T18:16:21Z",
    "severity": "MODERATE"
  },
  "details": "Mercusys AC12G (EU) V1 router with firmware AC12G(EU)_V1_200909 is vulnerable to a HTTP denial of service via a low number of crafted incomplete HTTP requests, causing a persistent crash that requires physical power cycling to recover.",
  "id": "GHSA-j2fc-v5xj-h5gr",
  "modified": "2026-06-03T21:30:29Z",
  "published": "2026-06-03T18:33:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-36605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tymbark7372/MERCUSYS-AC12G/blob/master/advisories/CVE-2026-36605.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J2MV-RMHW-VQ9M

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

The setup_arg_pages function in fs/exec.c in the Linux kernel before 2.6.36, when CONFIG_STACK_GROWSDOWN is used, does not properly restrict the stack memory consumption of the (1) arguments and (2) environment for a 32-bit application on a 64-bit platform, which allows local users to cause a denial of service (system crash) via a crafted exec system call, a related issue to CVE-2010-2240.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2010-3858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-11-30T21:38:00Z",
    "severity": "MODERATE"
  },
  "details": "The setup_arg_pages function in fs/exec.c in the Linux kernel before 2.6.36, when CONFIG_STACK_GROWSDOWN is used, does not properly restrict the stack memory consumption of the (1) arguments and (2) environment for a 32-bit application on a 64-bit platform, which allows local users to cause a denial of service (system crash) via a crafted exec system call, a related issue to CVE-2010-2240.",
  "id": "GHSA-j2mv-rmhw-vq9m",
  "modified": "2022-05-13T01:23:34Z",
  "published": "2022-05-13T01:23:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-3858"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=645222"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=1b528181b2ffa14721fb28ad1bd539fe1732c583"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1b528181b2ffa14721fb28ad1bd539fe1732c583"
    },
    {
      "type": "WEB",
      "url": "http://grsecurity.net/~spender/64bit_dos.c"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42758"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42789"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/46397"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2010/dsa-2126"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/15619"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.36"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2010:257"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2010/10/21/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2010/10/22/4"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2010-0958.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-0004.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/520102/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/44301"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1041-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2011-0012.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2011/0024"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2011/0070"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J2X4-HPHX-H7RG

Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-05-24 22:28
VLAI
Details

Trend Micro Antivirus for Mac 2021 (Consumer) is vulnerable to a memory exhaustion vulnerability that could lead to disabling all the scanning functionality within the application.

Please note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability – i.e. the attacker must already have access to the target system (either legitimately or via another exploit).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25227"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-04T20:15:00Z",
    "severity": "LOW"
  },
  "details": "Trend Micro Antivirus for Mac 2021 (Consumer) is vulnerable to a memory exhaustion vulnerability that could lead to disabling all the scanning functionality within the application.\n\nPlease note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability \u2013 i.e. the attacker must already have access to the target system (either legitimately or via another exploit).",
  "id": "GHSA-j2x4-hphx-h7rg",
  "modified": "2022-05-24T22:28:43Z",
  "published": "2022-05-24T22:28:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25227"
    },
    {
      "type": "WEB",
      "url": "https://helpcenter.trendmicro.com/en-us/article/TMKA-10191"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-102"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J32J-2HXV-RQF7

Vulnerability from github – Published: 2022-06-18 00:00 – Updated: 2023-10-19 18:45
VLAI
Summary
pg-native and libpq vulnerable to uncontrolled resource consumption
Details

pg-native before 3.0.1 and libpq before 1.8.10 are vulnerable to Denial of Service (DoS) when the addons attempt to cast the second argument to an array and fail. This happens for every non-array argument passed. Note: pg-native is a mere binding to npm's libpq library, which in turn has the addons and bindings to the actual C libpq library. This means that problems found in pg-native may transitively impact npm's libpq.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "libpq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "pg-native"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-25852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-704"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-20T22:28:59Z",
    "nvd_published_at": "2022-06-17T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "pg-native before 3.0.1 and libpq before 1.8.10 are vulnerable to Denial of Service (DoS) when the addons attempt to cast the second argument to an array and fail. This happens for every non-array argument passed. **Note:** pg-native is a mere binding to npm\u0027s libpq library, which in turn has the addons and bindings to the actual C libpq library. This means that problems found in pg-native may transitively impact npm\u0027s libpq.",
  "id": "GHSA-j32j-2hxv-rqf7",
  "modified": "2023-10-19T18:45:44Z",
  "published": "2022-06-18T00:00:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25852"
    },
    {
      "type": "WEB",
      "url": "https://github.com/brianc/node-libpq/issues/84"
    },
    {
      "type": "WEB",
      "url": "https://github.com/brianc/node-libpq/pull/86"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-LIBPQ-2392366"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-PGNATIVE-2392365"
    }
  ],
  "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": "pg-native and libpq vulnerable to uncontrolled resource consumption"
}

GHSA-J32X-J8PJ-PG2H

Vulnerability from github – Published: 2021-04-13 15:20 – Updated: 2021-03-22 22:36
VLAI
Summary
Prototype Pollution in decal
Details

This affects all versions of package decal. The vulnerability is in the extend function.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "decal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-28450"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-400",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-22T22:36:42Z",
    "nvd_published_at": "2021-02-04T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "This affects all versions of package decal. The vulnerability is in the extend function.",
  "id": "GHSA-j32x-j8pj-pg2h",
  "modified": "2021-03-22T22:36:42Z",
  "published": "2021-04-13T15:20:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28450"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gigafied/decal.js/blob/master/src/utils/extend.js#L23-L56"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-DECAL-1051028"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/decal"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in decal"
}

GHSA-J364-372C-2JC7

Vulnerability from github – Published: 2026-01-20 15:33 – Updated: 2026-02-02 18:31
VLAI
Details

A security issue exists within ArmorStart® LT that can result in a denial-of-service condition. During execution of the Achilles EtherNet/IP Step Limits Storms tests, the device reboots unexpectedly, causing the Link State Monitor to go down for several seconds.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-9283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-20T14:16:13Z",
    "severity": "HIGH"
  },
  "details": "A security issue exists within ArmorStart\u00ae LT that can result in a denial-of-service condition. During execution of the Achilles EtherNet/IP Step Limits Storms tests, the device reboots unexpectedly, causing the Link State Monitor to go down for several seconds.",
  "id": "GHSA-j364-372c-2jc7",
  "modified": "2026-02-02T18:31:31Z",
  "published": "2026-01-20T15:33:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9283"
    },
    {
      "type": "WEB",
      "url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1768.html"
    }
  ],
  "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-J377-2X76-558H

Vulnerability from github – Published: 2021-12-10 17:25 – Updated: 2022-05-04 03:12
VLAI
Summary
Improper Input Validation in is-email
Details

is-email helps validate an email address. A ReDoS (regular expression denial of service) flaw was found in the Segment is-email package before 1.0.1 for Node.js. An attacker that is able to provide crafted input to the isEmail(input) function may cause an application to consume an excessive amount of CPU.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "is-email"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-36716"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-15T18:43:45Z",
    "nvd_published_at": "2021-07-14T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "is-email helps validate an email address. A ReDoS (regular expression denial of service) flaw was found in the Segment is-email package before 1.0.1 for Node.js. An attacker that is able to provide crafted input to the isEmail(input) function may cause an application to consume an excessive amount of CPU.",
  "id": "GHSA-j377-2x76-558h",
  "modified": "2022-05-04T03:12:57Z",
  "published": "2021-12-10T17:25:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36716"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/segmentio/is-email"
    },
    {
      "type": "WEB",
      "url": "https://github.com/segmentio/is-email/releases"
    },
    {
      "type": "WEB",
      "url": "https://segment.com/docs/release_notes/2021-07-13-cve-2021-36716"
    }
  ],
  "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": "Improper Input Validation in is-email"
}

GHSA-J3G3-5QV5-52MJ

Vulnerability from github – Published: 2025-04-28 14:17 – Updated: 2025-11-21 22:18
VLAI
Summary
net-imap rubygem vulnerable to possible DoS by memory exhaustion
Details

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower max_response_size

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References

  • PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444
  • Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
  • Backport to 0.4: https://github.com/ruby/net-imap/pull/445
  • Backport to 0.3: https://github.com/ruby/net-imap/pull/446
  • Backport to 0.2: https://github.com/ruby/net-imap/pull/447
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.6"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.19"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.8"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-405",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-28T14:17:32Z",
    "nvd_published_at": "2025-04-28T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThere is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a \"literal\" byte count, which is automatically read by the client\u0027s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.\n\nThis should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).\n\n### Details\n\nThe IMAP protocol allows \"literal\" strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\\r\\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.\n\n### Fix\n#### Upgrade\nUsers should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`\u0027s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.\n\nTo set a global value for `max_response_size`, users must upgrade to `net-imap` ~\u003e 0.4.20, or \u003e 0.5.7.\n\n#### Configuration\n\nTo avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default `max_response_size` for `net-imap` 0.5.7 is _very high_ (512MiB), and the default `max_response_size` for `net-imap` ~\u003e 0.4.20, ~\u003e 0.3.9, and 0.2.5 is `nil` (unlimited).\n\nWhen connecting to untrusted servers or using insecure connections, a much lower `max_response_size` should be used.\n```ruby\n# Set the global max_response_size (only ~\u003e v0.4.20, \u003e 0.5.7)\nNet::IMAP.config.max_response_size = 256 \u003c\u003c 10 # 256 KiB\n\n# Set when creating the connection\nimap = Net::IMAP.new(hostname, ssl: true,\n                     max_response_size: 16 \u003c\u003c 10) # 16 KiB\n\n# Set after creating the connection\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\n# flush currently waiting read, to ensure the new setting is loaded\nimap.noop\n```\n\n_**Please Note:**_ `max_response_size` only limits the size _per response_.  It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash.  Users are responsible for adding response handlers to prune excessive unhandled responses.\n\n#### Compatibility with lower `max_response_size`\n\nA lower `max_response_size` may cause a few commands which legitimately return very large responses to raise an exception and close the connection.  The `max_response_size` could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible.  For example, to fetch message bodies:\n\n```ruby\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\nimap.noop # flush currently waiting read\n\n# fetch a message in 252KiB chunks\nsize = imap.uid_fetch(uid, \"RFC822.SIZE\").first.rfc822_size\nlimit = 252 \u003c\u003c 10\nmessage = ((0..size) % limit).each_with_object(\"\") {|offset, str|\n  str \u003c\u003c imap.uid_fetch(uid, \"BODY.PEEK[]\u003c#{offset}.#{limit}\u003e\").first.message(offset:)\n}\n\nimap.max_response_size = 16 \u003c\u003c 20 # 16 KiB\nimap.noop # flush currently waiting read\n```\n\n### References\n\n* PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444\n  * Specific commit: [0ae8576c1 - lib/net/imap/response_reader.rb](https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462)\n* Backport to 0.4: https://github.com/ruby/net-imap/pull/445\n* Backport to 0.3: https://github.com/ruby/net-imap/pull/446\n* Backport to 0.2: https://github.com/ruby/net-imap/pull/447",
  "id": "GHSA-j3g3-5qv5-52mj",
  "modified": "2025-11-21T22:18:03Z",
  "published": "2025-04-28T14:17:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-j3g3-5qv5-52mj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43857"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/442"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/447"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-43857.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap rubygem vulnerable to possible DoS by memory exhaustion"
}

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.