CWE-407
Allowed-with-ReviewInefficient 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:32A 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.
{
"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:22Impact
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:
- Open an issue in containerd
- Email us at security@containerd.io
To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io
{
"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:31mystrtod in mjson 1.2.7 requires more than a billion iterations during processing of certain digit strings such as 8891110122900e913013935755114.
{
"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:06Summary
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.
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.
{
"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:07Impact
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.
{
"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:40Summary
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.
{
"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:43Summary
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.
{
"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:18Summary
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::Deflateron untrusted traffic. - Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive
Accept-Encodingvalues.
{
"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:18Summary
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:
- Searching for the next quote or backslash,
- Copying the preceding substring into a new buffer, and
- 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.
{
"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:10Impact
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.
{
"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.