Common Weakness Enumeration

CWE-407

Allowed-with-Review

Inefficient Algorithmic Complexity

Abstraction: Class · Status: Incomplete

An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.

433 vulnerabilities reference this CWE, most recent first.

GHSA-RMHM-CWGP-268P

Vulnerability from github – Published: 2024-11-26 21:32 – Updated: 2024-11-26 21:32
VLAI
Details

A denial of service (DoS) condition was discovered in GitLab CE/EE affecting all versions from 13.2.4 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. By leveraging this vulnerability an attacker could create a DoS condition by sending crafted API calls. This was a regression of an earlier patch.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T19:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A denial of service (DoS) condition was discovered in GitLab CE/EE affecting all versions from 13.2.4 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. By leveraging this vulnerability an attacker could create a DoS condition by sending crafted API calls. This was a regression of an earlier patch.",
  "id": "GHSA-rmhm-cwgp-268p",
  "modified": "2024-11-26T21:32:24Z",
  "published": "2024-11-26T21:32:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11828"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2380264"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/443559"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RP3H-JF77-Q9P4

Vulnerability from github – Published: 2026-10-15 20:22 – Updated: 2026-10-15 20:22
VLAI
Summary
containerd: Unpack DoS via repeated opaque whiteouts
Details

Impact

A vulnerability exists in containerd's layer unpack handler where the processing of certain image layers causes superlinear time complexity. During the unpack operation, specific file configurations within the layer can trigger repeated directory traversals.

Consequently, pulling or importing a maliciously crafted image can result in increased unpack times and a moderate increase in CPU usage. This delays container startup, even if the compressed image layers are small. Additionally, in orchestrators like Kubernetes that apply concurrency limits to image pulls, these excessively long operations can reduce the available concurrency for other pulls, potentially delaying unrelated container deployments.

Patches

This bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.

Workarounds

There are no known workarounds for this issue. Users are advised to only pull and import trusted images from known registries until the patch can be applied.

Credits

The containerd project would like to thank Jakub Ciolek of AlphaSense for responsibly disclosing this issue in accordance with the containerd security policy.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-95838"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T20:22:05Z",
    "nvd_published_at": "2026-10-12T20:17:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA vulnerability exists in containerd\u0027s layer unpack handler where the processing of certain image layers causes superlinear time complexity. During the unpack operation, specific file configurations within the layer can trigger repeated directory traversals.\n\nConsequently, pulling or importing a maliciously crafted image can result in increased unpack times and a moderate increase in CPU usage. This delays container startup, even if the compressed image layers are small. Additionally, in orchestrators like Kubernetes that apply concurrency limits to image pulls, these excessively long operations can reduce the available concurrency for other pulls, potentially delaying unrelated container deployments.\n\n### Patches\n\nThis bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.\n\n### Workarounds\n\nThere are no known workarounds for this issue. Users are advised to only pull and import trusted images from known registries until the patch can be applied.\n\n### Credits\n\nThe containerd project would like to thank Jakub Ciolek of AlphaSense for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)",
  "id": "GHSA-rp3h-jf77-q9p4",
  "modified": "2026-10-15T20:22:05Z",
  "published": "2026-10-15T20:22:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/security/advisories/GHSA-rp3h-jf77-q9p4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95838"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/commit/e6ca378dcfa610d06589a3ac96aa992de866e4f0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containerd/containerd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "containerd: Unpack DoS via repeated opaque whiteouts"
}

GHSA-RQFJ-9WMV-VPGP

Vulnerability from github – Published: 2025-04-20 00:31 – Updated: 2025-04-20 00:31
VLAI
Details

mystrtod in mjson 1.2.7 requires more than a billion iterations during processing of certain digit strings such as 8891110122900e913013935755114.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-30421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-19T22:15:14Z",
    "severity": "LOW"
  },
  "details": "mystrtod in mjson 1.2.7 requires more than a billion iterations during processing of certain digit strings such as 8891110122900e913013935755114.",
  "id": "GHSA-rqfj-9wmv-vpgp",
  "modified": "2025-04-20T00:31:40Z",
  "published": "2025-04-20T00:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30421"
    },
    {
      "type": "WEB",
      "url": "https://github.com/boofish/json_bugs/blob/main/mjson"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cesanta/mjson/releases"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V245-V573-V5VM

Vulnerability from github – Published: 2026-07-21 19:06 – Updated: 2026-07-21 19:06
VLAI
Summary
linkify-it: Quadratic-complexity DoS via the `mailto:` validator scan-loop on attacker text
Details

Summary

linkify-it's schema-scan loop (.test() / .match(), the documented public API) invokes the mailto: schema validator at every mailto: occurrence in the input text. For each occurrence the validator does text.slice(pos) (an O(n) copy) and runs an email regex whose local-part class src_email_name greedily scans the entire remaining tail (O(n)) before failing. With N mailto: occurrences that is N × O(n) = O(n²). Because linkify-it runs on arbitrary user text (markdown-it feeds it whole documents when linkify:true), an unauthenticated attacker can block the single-threaded event loop for many seconds with a small input. No length bound (unlike an HTTP header).

Root cause — index.mjs + lib/re.mjs

// index.mjs (mailto validator) — runs at every "mailto:" hit
'mailto:': { validate: function (text, pos, self) {
  const tail = text.slice(pos)                                  // O(n) copy per hit
  if (!self.re.mailto) self.re.mailto = new RegExp('^' + self.re.src_email_name + '@' + self.re.src_host_strict, 'i')
  if (self.re.mailto.test(tail)) { ... }                        // scans the whole O(n) tail
  return 0
}}
// lib/re.mjs:91-93 — every char of "mailto:" (incl. ':','-',';') is in this class:
re.src_email_name = '[\\-;:&=\\+\\$,\\.a-zA-Z0-9_][\\-;:&=\\+\\$,\\"\\.a-zA-Z0-9_]*'

The while ((m = re.exec(text)) !== null) { …testSchemaAt… } scan loop calls the validator at each mailto: hit; src_email_name greedily consumes the whole tail (all chars are in its class) then fails for lack of @. http:/https: do NOT blow up — their validator requires the tail to start with //, failing in O(1) per hit.

Proof of Concept (confirmed, linkify-it 5.0.1, Node v24)

const LinkifyIt = require('linkify-it');
const lf = new LinkifyIt();
lf.match('mailto:'.repeat(48000));   // ~336 KB of "mailto:mailto:…" -> seconds of blocked event loop
input (same bytes) 56 KB 112 KB 224 KB 336 KB
mailto: contiguous 97 ms 357 ms 1438 ms 3272 ms
mailto: space-separated 2 ms 3 ms 5 ms 8 ms
http:// contiguous 12 ms 17 ms 33 ms 49 ms

×~4 per 2× input ⇒ O(n²); equal-byte controls stay flat ⇒ algorithmic, not a GC/allocation artifact. Real-world via markdown-it 14.x ({linkify:true}), md.render('mailto:'.repeat(n)): 219 KB ≈ ~5 s. image

Impact

Reachable on arbitrary user text via the documented .test()/.match() API and through markdown-it's linkifier — comment systems, chat, forums, wikis, note apps that render user markdown with linkify enabled. A ~220 KB post hangs the event loop ~5 s; a few hundred KB → tens of seconds. Availability only.

Suggested remediation

Bound the email local-part per RFC 5321 (≤64) so per-hit work is O(1), and avoid the full-tail slice:

// lib/re.mjs — cap the greedy run:
re.src_email_name = '[\\-;:&=\\+\\$,\\.a-zA-Z0-9_][\\-;:&=\\+\\$,\\"\\.a-zA-Z0-9_]{0,63}'
// index.mjs — prefer a sticky regex anchored at `pos` over text.slice(pos).

Affected / disclosure

All versions through 5.0.1 (latest); same code on master. cve-mcp/OSV report no known vulnerability for linkify-it. Distinct from markdown-it's own *-run ReDoS (CVE-2026-2327, different package/path) and the recent markdown-it DoS. Reported privately; happy to test a patch against the PoC.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "linkify-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T19:06:09Z",
    "nvd_published_at": "2026-07-08T17:17:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`linkify-it`\u0027s schema-scan loop (`.test()` / `.match()`, the documented public API) invokes the `mailto:`\nschema validator at **every** `mailto:` occurrence in the input text. For each occurrence the validator does\n`text.slice(pos)` (an O(n) copy) and runs an email regex whose local-part class `src_email_name` greedily\nscans the **entire remaining tail** (O(n)) before failing. With N `mailto:` occurrences that is\n**N \u00d7 O(n) = O(n\u00b2)**. Because linkify-it runs on arbitrary user text (markdown-it feeds it whole documents\nwhen `linkify:true`), an unauthenticated attacker can block the single-threaded event loop for many seconds\nwith a small input. No length bound (unlike an HTTP header).\n\n### Root cause \u2014 `index.mjs` + `lib/re.mjs`\n```js\n// index.mjs (mailto validator) \u2014 runs at every \"mailto:\" hit\n\u0027mailto:\u0027: { validate: function (text, pos, self) {\n  const tail = text.slice(pos)                                  // O(n) copy per hit\n  if (!self.re.mailto) self.re.mailto = new RegExp(\u0027^\u0027 + self.re.src_email_name + \u0027@\u0027 + self.re.src_host_strict, \u0027i\u0027)\n  if (self.re.mailto.test(tail)) { ... }                        // scans the whole O(n) tail\n  return 0\n}}\n// lib/re.mjs:91-93 \u2014 every char of \"mailto:\" (incl. \u0027:\u0027,\u0027-\u0027,\u0027;\u0027) is in this class:\nre.src_email_name = \u0027[\\\\-;:\u0026=\\\\+\\\\$,\\\\.a-zA-Z0-9_][\\\\-;:\u0026=\\\\+\\\\$,\\\\\"\\\\.a-zA-Z0-9_]*\u0027\n```\nThe `while ((m = re.exec(text)) !== null) { \u2026testSchemaAt\u2026 }` scan loop calls the validator at each\n`mailto:` hit; `src_email_name` greedily consumes the whole tail (all chars are in its class) then fails for\nlack of `@`. `http:`/`https:` do NOT blow up \u2014 their validator requires the tail to start with `//`, failing\nin O(1) per hit.\n\n### Proof of Concept (confirmed, linkify-it 5.0.1, Node v24)\n```js\nconst LinkifyIt = require(\u0027linkify-it\u0027);\nconst lf = new LinkifyIt();\nlf.match(\u0027mailto:\u0027.repeat(48000));   // ~336 KB of \"mailto:mailto:\u2026\" -\u003e seconds of blocked event loop\n```\n| input (same bytes) | 56 KB | 112 KB | 224 KB | 336 KB |\n|---|---:|---:|---:|---:|\n| **`mailto:` contiguous** | 97 ms | 357 ms | 1438 ms | 3272 ms |\n| `mailto:` space-separated | 2 ms | 3 ms | 5 ms | 8 ms |\n| `http://` contiguous | 12 ms | 17 ms | 33 ms | 49 ms |\n\n\u00d7~4 per 2\u00d7 input \u21d2 O(n\u00b2); equal-byte controls stay flat \u21d2 algorithmic, not a GC/allocation artifact.\nReal-world via markdown-it 14.x (`{linkify:true}`), `md.render(\u0027mailto:\u0027.repeat(n))`: 219 KB \u2248 ~5 s.\n\u003cimg width=\"737\" height=\"161\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b5d390f3-68d0-4861-9c47-ad8aff0203d5\" /\u003e\n\n### Impact\nReachable on arbitrary user text via the documented `.test()`/`.match()` API and through markdown-it\u0027s\nlinkifier \u2014 comment systems, chat, forums, wikis, note apps that render user markdown with linkify enabled.\nA ~220 KB post hangs the event loop ~5 s; a few hundred KB \u2192 tens of seconds. Availability only.\n\n### Suggested remediation\nBound the email local-part per RFC 5321 (\u226464) so per-hit work is O(1), and avoid the full-tail slice:\n```js\n// lib/re.mjs \u2014 cap the greedy run:\nre.src_email_name = \u0027[\\\\-;:\u0026=\\\\+\\\\$,\\\\.a-zA-Z0-9_][\\\\-;:\u0026=\\\\+\\\\$,\\\\\"\\\\.a-zA-Z0-9_]{0,63}\u0027\n// index.mjs \u2014 prefer a sticky regex anchored at `pos` over text.slice(pos).\n```\n\n### Affected / disclosure\nAll versions through 5.0.1 (latest); same code on `master`. cve-mcp/OSV report no known vulnerability for\nlinkify-it. Distinct from markdown-it\u0027s own `*`-run ReDoS (CVE-2026-2327, different package/path) and the\nrecent markdown-it DoS. Reported privately; happy to test a patch against the PoC.",
  "id": "GHSA-v245-v573-v5vm",
  "modified": "2026-07-21T19:06:09Z",
  "published": "2026-07-21T19:06:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/linkify-it/security/advisories/GHSA-v245-v573-v5vm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/linkify-it/commit/105e5d77f7d119871d2b2d86ed208568eb3e7ffe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/markdown-it/linkify-it"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/linkify-it/releases/tag/5.0.2"
    }
  ],
  "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": "linkify-it: Quadratic-complexity DoS via the `mailto:` validator scan-loop on attacker text"
}

GHSA-V247-6F48-MGCJ

Vulnerability from github – Published: 2026-10-01 15:07 – Updated: 2026-10-01 15:07
VLAI
Summary
pypdf: Possible long runtimes with large amount of embedded files
Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.

Patches

This has been fixed in pypdf==6.19.0.

Workarounds

If you cannot upgrade yet, consider applying the changes from PR #4081.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:07:35Z",
    "nvd_published_at": "2026-09-30T21:17:07Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.\n\n### Patches\n\nThis has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).\n\n### Workarounds\n\nIf you cannot upgrade yet, consider applying the changes from PR [#4081](https://github.com/py-pdf/pypdf/pull/4081).",
  "id": "GHSA-v247-6f48-mgcj",
  "modified": "2026-10-01T15:07:35Z",
  "published": "2026-10-01T15:07:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-v247-6f48-mgcj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102999"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/4081"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/6b10556d13609a68f9ed18bb29fdd8bba88eb2c3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.19.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypdf: Possible long runtimes with large amount of embedded files"
}

GHSA-V36G-JCW9-X7CW

Vulnerability from github – Published: 2026-10-08 17:40 – Updated: 2026-10-08 17:40
VLAI
Summary
Pydantic AI: Excessive resource use when local web fetching converts nested HTML
Details

Summary

Applications using Pydantic AI's local web-fetch tool can experience excessive CPU and memory use when it converts attacker-controlled HTML. An agent must fetch the affected page; provider-native web fetching is not affected.

Details

Nested block elements cause HTML-to-Markdown conversion to reprocess accumulated text at each level and can greatly expand the intermediate output. The response-body limit bounds downloaded bytes, while the returned-content limit is applied only after conversion. On current releases, conversion runs in a worker thread but can still consume substantial resources and delay other work in the process. Older releases performed conversion on the event loop.

Mitigation

Upgrade to a patched release of pydantic-ai or pydantic-ai-slim. If you cannot upgrade yet, avoid using local web fetching for attacker-controlled HTML.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.77.0"
            },
            {
              "fixed": "1.107.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.52.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai-slim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.77.0"
            },
            {
              "fixed": "1.107.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai-slim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.52.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:40:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nApplications using Pydantic AI\u0027s local web-fetch tool can experience excessive CPU and memory use when it converts attacker-controlled HTML. An agent must fetch the affected page; provider-native web fetching is not affected.\n\n### Details\n\nNested block elements cause HTML-to-Markdown conversion to reprocess accumulated text at each level and can greatly expand the intermediate output. The response-body limit bounds downloaded bytes, while the returned-content limit is applied only after conversion. On current releases, conversion runs in a worker thread but can still consume substantial resources and delay other work in the process. Older releases performed conversion on the event loop.\n\n### Mitigation\n\nUpgrade to a patched release of `pydantic-ai` or `pydantic-ai-slim`. If you cannot upgrade yet, avoid using local web fetching for attacker-controlled HTML.",
  "id": "GHSA-v36g-jcw9-x7cw",
  "modified": "2026-10-08T17:40:50Z",
  "published": "2026-10-08T17:40:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-v36g-jcw9-x7cw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/pull/8984"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/pull/8985"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/commit/2b247add4950bef61d352e7ca8aefbd20539180c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/commit/2fd38792693da00a3ca5412aeffb436787af3545"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pydantic/pydantic-ai"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/releases/tag/v1.107.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/releases/tag/v2.52.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Pydantic AI: Excessive resource use when local web fetching converts nested HTML"
}

GHSA-V53P-9FQP-M79J

Vulnerability from github – Published: 2026-09-29 23:43 – Updated: 2026-09-29 23:43
VLAI
Summary
Nodemailer: Quadratic backtracking in the addressparser free-text fallback allows remote denial of service
Details

Summary

When addressparser finds no address by its strict reading, it falls back to pulling one out of the free text with /\s*\b[^@\s]+@[^\s]+\b\s*/. That pattern backtracks quadratically: [^@\s]+ is retried from every offset and rescans the run to the next @ each time. A single header value holding a long whitespace-free run with no usable @ blocks the Node.js event loop for tens of seconds.

It is cheaper to exploit than GHSA-prgh-xp8r-p3m5: 273KB is enough for ~43s, where the comment-joined shape needed ~1.5MB for ~10s.

Details

The fallback in src/addressparser/index.ts ran the pattern as a search. [^@\s]+ crosses neither whitespace nor @, so from each start offset it scans forward to the next @ or to the end of the run and then fails, and the engine simply advances one character and repeats. Three shapes make every offset fail:

  • the run holds no @ at all
  • the only @ has nothing after it
  • the only @ has nothing before it

A fourth reaches it with a valid address present but placed past a long run, so the long run is walked before the match is found.

PoC

const addressparser = require('nodemailer/lib/addressparser');
const s = Date.now();
addressparser(' >' + '>[x][x]'.repeat(40000)); // 273KB
console.log(Date.now() - s, 'ms'); // ~43000 ms, blocking

Measured on 10.0.5:

Value Parse time
'[x]'.repeat(40000) (117KB) 9.0 s
'[x]'.repeat(40000) + '@' (117KB) 8.9 s
'@' + '[x]'.repeat(40000) (117KB) 8.8 s
' >' + '>[x][x]'.repeat(40000) (273KB) 42.9 s

Impact

Algorithmic-complexity denial of service. Node is single threaded, so the block stalls the whole process. Reachable without authentication anywhere inbound header values are handed to this parser, mailparser being the notable case, and reachable from application input wherever a user-supplied string is used as a message address, since mime-node parses to, from and cc when composing.

Patch

The search is replaced by a single linear pass that finds the one offset the pattern can match at, which is then applied there with a sticky regex. Match results are unchanged, verified against the previous implementation over 3.4 million random strings comparing both the match offset and the matched text, plus 800k full-parse comparisons.

Found while validating the report in GHSA-prgh-xp8r-p3m5, not reported externally.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:43:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen `addressparser` finds no address by its strict reading, it falls back to pulling one out of the free text with `/\\s*\\b[^@\\s]+@[^\\s]+\\b\\s*/`. That pattern backtracks quadratically: `[^@\\s]+` is retried from every offset and rescans the run to the next `@` each time. A single header value holding a long whitespace-free run with no usable `@` blocks the Node.js event loop for tens of seconds.\n\nIt is cheaper to exploit than GHSA-prgh-xp8r-p3m5: 273KB is enough for ~43s, where the comment-joined shape needed ~1.5MB for ~10s.\n\n### Details\n\nThe fallback in `src/addressparser/index.ts` ran the pattern as a search. `[^@\\s]+` crosses neither whitespace nor `@`, so from each start offset it scans forward to the next `@` or to the end of the run and then fails, and the engine simply advances one character and repeats. Three shapes make every offset fail:\n\n- the run holds no `@` at all\n- the only `@` has nothing after it\n- the only `@` has nothing before it\n\nA fourth reaches it with a valid address present but placed past a long run, so the long run is walked before the match is found.\n\n### PoC\n\n```js\nconst addressparser = require(\u0027nodemailer/lib/addressparser\u0027);\nconst s = Date.now();\naddressparser(\u0027 \u003e\u0027 + \u0027\u003e[x][x]\u0027.repeat(40000)); // 273KB\nconsole.log(Date.now() - s, \u0027ms\u0027); // ~43000 ms, blocking\n```\n\nMeasured on 10.0.5:\n\n| Value | Parse time |\n| --- | --- |\n| `\u0027[x]\u0027.repeat(40000)` (117KB) | 9.0 s |\n| `\u0027[x]\u0027.repeat(40000) + \u0027@\u0027` (117KB) | 8.9 s |\n| `\u0027@\u0027 + \u0027[x]\u0027.repeat(40000)` (117KB) | 8.8 s |\n| `\u0027 \u003e\u0027 + \u0027\u003e[x][x]\u0027.repeat(40000)` (273KB) | 42.9 s |\n\n### Impact\n\nAlgorithmic-complexity denial of service. Node is single threaded, so the block stalls the whole process. Reachable without authentication anywhere inbound header values are handed to this parser, mailparser being the notable case, and reachable from application input wherever a user-supplied string is used as a message address, since `mime-node` parses `to`, `from` and `cc` when composing.\n\n### Patch\n\nThe search is replaced by a single linear pass that finds the one offset the pattern can match at, which is then applied there with a sticky regex. Match results are unchanged, verified against the previous implementation over 3.4 million random strings comparing both the match offset and the matched text, plus 800k full-parse comparisons.\n\nFound while validating the report in GHSA-prgh-xp8r-p3m5, not reported externally.",
  "id": "GHSA-v53p-9fqp-m79j",
  "modified": "2026-09-29T23:43:36Z",
  "published": "2026-09-29T23:43:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-v53p-9fqp-m79j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/437d7fc47403df176bc39271641541b7a9bce102"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/releases/tag/v10.0.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nodemailer: Quadratic backtracking in the addressparser free-text fallback allows remote denial of service"
}

GHSA-V569-HP3G-36WR

Vulnerability from github – Published: 2026-04-02 20:32 – Updated: 2026-05-13 16:18
VLAI
Summary
Rack has quadratic complexity in Rack::Utils.select_best_encoding via wildcard Accept-Encoding header
Details

Summary

Rack::Utils.select_best_encoding processes Accept-Encoding values with quadratic time complexity when the header contains many wildcard (*) entries. Because this method is used by Rack::Deflater to choose a response encoding, an unauthenticated attacker can send a single request with a crafted Accept-Encoding header and cause disproportionate CPU consumption on the compression middleware path.

This results in a denial of service condition for applications using Rack::Deflater.

Details

Rack::Utils.select_best_encoding expands parsed Accept-Encoding values into a list of candidate encodings. When an entry is *, the method computes the set of concrete encodings by subtracting the encodings already present in the request:

if m == "*"
  (available_encodings - accept_encoding.map(&:first)).each do |m2|
    expanded_accept_encoding << [m2, q, preference]
  end
else
  expanded_accept_encoding << [m, q, preference]
end

Because accept_encoding.map(&:first) is evaluated inside the loop, it is recomputed for each wildcard entry. If the request contains N wildcard entries, this produces repeated scans over the full parsed header and causes quadratic behavior.

After expansion, the method also performs additional work over expanded_accept_encoding, including per-entry deletion, which further increases the cost for large inputs.

Rack::Deflater invokes this method for each request when the middleware is enabled:

Utils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))

As a result, a client can trigger this expensive code path simply by sending a large Accept-Encoding header containing many repeated wildcard values.

For example, a request with an approximately 8 KB Accept-Encoding header containing about 1,000 *;q=0.5 entries can cause roughly 170 ms of CPU time in a single request on the Rack::Deflater path, compared to a negligible baseline for a normal header.

This issue is distinct from CVE-2024-26146. That issue concerned regular expression denial of service during Accept header parsing, whereas this issue arises later during encoding selection after the header has already been parsed.

Impact

Any Rack application using Rack::Deflater may be affected.

An unauthenticated attacker can send requests with crafted Accept-Encoding headers to trigger excessive CPU usage in the encoding selection logic. Repeated requests can consume worker time disproportionately and reduce application availability.

The attack does not require invalid HTTP syntax or large payload bodies. A single header-sized request is sufficient to reach the vulnerable code path.

Mitigation

  • Update to a patched version of Rack in which encoding selection does not repeatedly rescan the parsed header for wildcard entries.
  • Avoid enabling Rack::Deflater on untrusted traffic.
  • Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive Accept-Encoding values.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0.beta1"
            },
            {
              "fixed": "3.1.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T20:32:19Z",
    "nvd_published_at": "2026-04-02T17:16:23Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`Rack::Utils.select_best_encoding` processes `Accept-Encoding` values with quadratic time complexity when the header contains many wildcard (`*`) entries. Because this method is used by `Rack::Deflater` to choose a response encoding, an unauthenticated attacker can send a single request with a crafted `Accept-Encoding` header and cause disproportionate CPU consumption on the compression middleware path.\n\nThis results in a denial of service condition for applications using `Rack::Deflater`.\n\n## Details\n\n`Rack::Utils.select_best_encoding` expands parsed `Accept-Encoding` values into a list of candidate encodings. When an entry is `*`, the method computes the set of concrete encodings by subtracting the encodings already present in the request:\n\n```ruby\nif m == \"*\"\n  (available_encodings - accept_encoding.map(\u0026:first)).each do |m2|\n    expanded_accept_encoding \u003c\u003c [m2, q, preference]\n  end\nelse\n  expanded_accept_encoding \u003c\u003c [m, q, preference]\nend\n```\n\nBecause `accept_encoding.map(\u0026:first)` is evaluated inside the loop, it is recomputed for each wildcard entry. If the request contains `N` wildcard entries, this produces repeated scans over the full parsed header and causes quadratic behavior.\n\nAfter expansion, the method also performs additional work over `expanded_accept_encoding`, including per-entry deletion, which further increases the cost for large inputs.\n\n`Rack::Deflater` invokes this method for each request when the middleware is enabled:\n\n```ruby\nUtils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))\n```\n\nAs a result, a client can trigger this expensive code path simply by sending a large `Accept-Encoding` header containing many repeated wildcard values.\n\nFor example, a request with an approximately 8 KB `Accept-Encoding` header containing about 1,000 `*;q=0.5` entries can cause roughly 170 ms of CPU time in a single request on the `Rack::Deflater` path, compared to a negligible baseline for a normal header.\n\nThis issue is distinct from CVE-2024-26146. That issue concerned regular expression denial of service during `Accept` header parsing, whereas this issue arises later during encoding selection after the header has already been parsed.\n\n## Impact\n\nAny Rack application using `Rack::Deflater` may be affected.\n\nAn unauthenticated attacker can send requests with crafted `Accept-Encoding` headers to trigger excessive CPU usage in the encoding selection logic. Repeated requests can consume worker time disproportionately and reduce application availability.\n\nThe attack does not require invalid HTTP syntax or large payload bodies. A single header-sized request is sufficient to reach the vulnerable code path.\n\n## Mitigation\n\n* Update to a patched version of Rack in which encoding selection does not repeatedly rescan the parsed header for wildcard entries.\n* Avoid enabling `Rack::Deflater` on untrusted traffic.\n* Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive `Accept-Encoding` values.",
  "id": "GHSA-v569-hp3g-36wr",
  "modified": "2026-05-13T16:18:11Z",
  "published": "2026-04-02T20:32:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-v569-hp3g-36wr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34230"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34230.yml"
    }
  ],
  "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": "Rack has quadratic complexity in Rack::Utils.select_best_encoding via wildcard Accept-Encoding header"
}

GHSA-V6X5-CG8R-VV6X

Vulnerability from github – Published: 2026-04-02 20:30 – Updated: 2026-05-13 16:18
VLAI
Summary
Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters
Details

Summary

Rack::Multipart::Parser#handle_mime_head parses quoted multipart parameters such as Content-Disposition: form-data; name="..." using repeated String#index searches combined with String#slice! prefix deletion. For escape-heavy quoted values, this causes super-linear processing.

An unauthenticated attacker can send a crafted multipart/form-data request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing.

This results in a denial of service condition in Rack applications that accept multipart form data.

Details

Rack::Multipart::Parser#handle_mime_head parses quoted parameter values by repeatedly:

  1. Searching for the next quote or backslash,
  2. Copying the preceding substring into a new buffer, and
  3. Removing the processed prefix from the original string with slice!.

An attacker can exploit this by sending a multipart request with many parts whose name parameters contain long escape-heavy values such as:

name="a\\a\\a\\a\\a\\..."

Under default Rack limits, a request can contain up to 4095 parts. If many of those parts use long quoted values with dense escape characters, the parser performs disproportionately expensive CPU work while remaining within normal request size and part-count limits.

Impact

Any Rack application that accepts multipart/form-data requests may be affected, including file upload endpoints and standard HTML form handlers.

An unauthenticated attacker can send crafted multipart requests that consume excessive CPU time during request parsing. Repeated requests can tie up application workers, reduce throughput, and degrade or deny service availability.

Mitigation

  • Update to a patched version of Rack that parses quoted multipart parameters without repeated rescanning and destructive prefix deletion.
  • Apply request throttling or rate limiting to multipart upload endpoints.
  • Where operationally feasible, restrict or isolate multipart parsing on untrusted high-volume endpoints.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0.beta1"
            },
            {
              "fixed": "3.1.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T20:30:12Z",
    "nvd_published_at": "2026-04-02T18:16:33Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`Rack::Multipart::Parser#handle_mime_head` parses quoted multipart parameters such as `Content-Disposition: form-data; name=\"...\"` using repeated `String#index` searches combined with `String#slice!` prefix deletion. For escape-heavy quoted values, this causes super-linear processing.\n\nAn unauthenticated attacker can send a crafted `multipart/form-data` request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing.\n\nThis results in a denial of service condition in Rack applications that accept multipart form data.\n\n## Details\n\n`Rack::Multipart::Parser#handle_mime_head` parses quoted parameter values by repeatedly:\n\n1. Searching for the next quote or backslash,\n2. Copying the preceding substring into a new buffer, and\n3. Removing the processed prefix from the original string with `slice!`.\n\nAn attacker can exploit this by sending a multipart request with many parts whose `name` parameters contain long escape-heavy values such as:\n\n```text\nname=\"a\\\\a\\\\a\\\\a\\\\a\\\\...\"\n```\n\nUnder default Rack limits, a request can contain up to 4095 parts. If many of those parts use long quoted values with dense escape characters, the parser performs disproportionately expensive CPU work while remaining within normal request size and part-count limits.\n\n## Impact\n\nAny Rack application that accepts `multipart/form-data` requests may be affected, including file upload endpoints and standard HTML form handlers.\n\nAn unauthenticated attacker can send crafted multipart requests that consume excessive CPU time during request parsing. Repeated requests can tie up application workers, reduce throughput, and degrade or deny service availability.\n\n## Mitigation\n\n* Update to a patched version of Rack that parses quoted multipart parameters without repeated rescanning and destructive prefix deletion.\n* Apply request throttling or rate limiting to multipart upload endpoints.\n* Where operationally feasible, restrict or isolate multipart parsing on untrusted high-volume endpoints.",
  "id": "GHSA-v6x5-cg8r-vv6x",
  "modified": "2026-05-13T16:18:33Z",
  "published": "2026-04-02T20:30:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-v6x5-cg8r-vv6x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34827"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34827.yml"
    }
  ],
  "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": "Rack\u0027s multipart header parsing allows Denial of Service via escape-heavy quoted parameters"
}

GHSA-VCC3-GHJQ-M6FR

Vulnerability from github – Published: 2026-08-31 22:10 – Updated: 2026-08-31 22:10
VLAI
Summary
decode-uri-component: Denial of service via exponential decoding of malformed percent-encoded input
Details

Impact

An attacker who can supply input to decodeUriComponent() (directly or via a dependency that uses this package on URL/query/path data) can cause excessive CPU usage and application unresponsiveness. This is an availability issue; there is no known memory corruption, data disclosure, or remote code execution impact.

Patches

Upgrade to decode-uri-component@0.5.0.

Workarounds

Limit the size of the input.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "decode-uri-component"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1176",
      "CWE-400",
      "CWE-405",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-31T22:10:20Z",
    "nvd_published_at": "2026-06-30T09:16:25Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker who can supply input to `decodeUriComponent()` (directly or via a dependency that uses this package on URL/query/path data) can cause excessive CPU usage and application unresponsiveness. This is an availability issue; there is no known memory corruption, data disclosure, or remote code execution impact.\n\n### Patches\nUpgrade to `decode-uri-component@0.5.0`.\n\n### Workarounds\nLimit the size of the input.",
  "id": "GHSA-vcc3-ghjq-m6fr",
  "modified": "2026-08-31T22:10:20Z",
  "published": "2026-08-31T22:10:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/security/advisories/GHSA-vcc3-ghjq-m6fr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45822"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/commit/fa479dafeede7bedf04e5c89aa78f2a78c664005"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SamVerschueren/decode-uri-component"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/blob/00662938dc7c6241547ae8abce7785cc13ffd3f6/index.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/releases/tag/v0.5.0"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/decode-uri-component"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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:U/S:N/AU:Y/R:U/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ],
  "summary": "decode-uri-component: Denial of service via exponential decoding of malformed percent-encoded input"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.