GHSA-xcx6-vp38-8hr5 — Scriban
HIGHGHSA-xcx6-vp38-8hr5 is a high-severity (CVSS 7.5) CWE-674 vulnerability in Scriban. A fix is available for Scriban — see the affected versions and patch details below.
Scriban has Uncontrolled Recursion in `object.to_json` Causing Unrecoverable Process Crash via StackOverflowException
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-xcx6-vp38-8hr5.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-xcx6-vp38-8hr5 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
Scriban.NETScriban.SignedReal-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
The object.to_json builtin function in Scriban performs recursive JSON serialization via an internal WriteValue() static local function that has no depth limit, no circular reference detection, and no stack overflow guard. A Scriban template containing a self-referencing object passed to object.to_json triggers unbounded recursion, causing a StackOverflowException that terminates the hosting .NET process. This is a fatal, unrecoverable crash — StackOverflowException cannot be caught by user code in .NET.
Details
The vulnerable code is the WriteValue() static local function at src/Scriban/Functions/ObjectFunctions.cs:494:
static void WriteValue(TemplateContext context, Utf8JsonWriter writer, object value)
{
var type = value?.GetType() ?? typeof(object);
if (value is null || value is string || value is bool ||
type.IsPrimitiveOrDecimal() || value is IFormattable)
{
JsonSerializer.Serialize(writer, value, type);
}
else if (value is IList || type.IsArray) {
writer.WriteStartArray();
foreach (var x in context.ToList(context.CurrentSpan, value))
{
WriteValue(context, writer, x); // recursive, no depth check
}
writer.WriteEndArray();
}
else {
writer.WriteStartObject();
var accessor = context.GetMemberAccessor(value);
foreach (var member in accessor.GetMembers(context, context.CurrentSpan, value))
{
if (accessor.TryGetValue(context, context.CurrentSpan, value, member, out var memberValue))
{
writer.WritePropertyName(member);
WriteValue(context, writer, memberValue); // recursive, no depth check
}
}
writer.WriteEndObject();
}
}
This function has none of the safety mechanisms present in other recursive paths:
ObjectToString()atTemplateContext.Helpers.cs:98checksObjectRecursionLimit(default 20)EnterRecursive()atTemplateContext.cs:957callsRuntimeHelpers.EnsureSufficientExecutionStack()CheckAbort()atTemplateContext.cs:464also callsEnsureSufficientExecutionStack()
The WriteValue() function bypasses all of these because it is a static local function that only takes the TemplateContext for member access — it never calls EnterRecursive(), never checks ObjectRecursionLimit, and never calls EnsureSufficientExecutionStack().
Execution flow:
- Template creates a ScriptObject:
{{ x = {} }} - Sets a self-reference:
x.self = x— stores a reference inScriptObject.Storedictionary - Pipes to
object.to_json:x | object.to_json→ callsToJson()at line 477 ToJson()callsWriteValue(context, writer, value)at line 488WriteValueenters theelsebranch (line 515), gets members via accessor, finds "self"TryGetValuereturnsxitself,WriteValuerecurses with the same object — infinite loopStackOverflowExceptionis thrown — fatal, cannot be caught, process terminates
PoC
{{ x = {}; x.self = x; x | object.to_json }}
In a hosting application:
using Scriban;
// This will crash the entire process with StackOverflowException
var template = Template.Parse("{{ x = {}; x.self = x; x | object.to_json }}");
var result = template.Render(); // FATAL: process terminates here
Even without circular references, deeply nested objects can exhaust the stack since no depth limit is enforced:
{{ a = {}
b = {inner: a}
c = {inner: b}
d = {inner: c}
# ... continue nesting ...
result = deepest | object.to_json }}
Impact
- Process crash DoS: Any application embedding Scriban for user-provided templates (CMS platforms, email template engines, report generators, static site generators) can be crashed by a single malicious template. The crash is unrecoverable —
StackOverflowExceptionterminates the .NET process. - No try/catch protection possible: Unlike most exceptions,
StackOverflowExceptioncannot be caught by application code. The hosting application cannot wraptemplate.Render()in a try/catch to survive this. - No authentication required:
object.to_jsonis a default builtin function (registered inBuiltinFunctions.cs), available in all Scriban templates unless explicitly removed. - Trivial to exploit: The PoC is a single line of template code.
Recommended Fix
Add a depth counter parameter to WriteValue() and check it against ObjectRecursionLimit, consistent with how ObjectToString is protected. Also add EnsureSufficientExecutionStack() as a safety net:
static void WriteValue(TemplateContext context, Utf8JsonWriter writer, object value, int depth = 0)
{
if (context.ObjectRecursionLimit != 0 && depth > context.ObjectRecursionLimit)
{
throw new ScriptRuntimeException(context.CurrentSpan,
$"Exceeding object recursion limit `{context.ObjectRecursionLimit}` in object.to_json");
}
try
{
RuntimeHelpers.EnsureSufficientExecutionStack();
}
catch (InsufficientExecutionStackException)
{
throw new ScriptRuntimeException(context.CurrentSpan,
"Exceeding recursive depth limit in object.to_json, near to stack overflow");
}
var type = value?.GetType() ?? typeof(object);
if (value is null || value is string || value is bool ||
type.IsPrimitiveOrDecimal() || value is IFormattable)
{
JsonSerializer.Serialize(writer, value, type);
}
else if (value is IList || type.IsArray) {
writer.WriteStartArray();
foreach (var x in context.ToList(context.CurrentSpan, value))
{
WriteValue(context, writer, x, depth + 1);
}
writer.WriteEndArray();
}
else {
writer.WriteStartObject();
var accessor = context.GetMemberAccessor(value);
foreach (var member in accessor.GetMembers(context, context.CurrentSpan, value))
{
if (accessor.TryGetValue(context, context.CurrentSpan, value, member, out var memberValue))
{
writer.WritePropertyName(member);
WriteValue(context, writer, memberValue, depth + 1);
}
}
writer.WriteEndObject();
}
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Scriban | all versions | 7.0.0dotnet add package Scriban --version 7.0.0 |
| .NETNuGet | Scriban.Signed | all versions | 7.0.0dotnet add package Scriban.Signed --version 7.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update Scriban to 7.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xcx6-vp38-8hr5 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-xcx6-vp38-8hr5 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-xcx6-vp38-8hr5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xcx6-vp38-8hr5 in your dependencies?
O3 Security finds GHSA-xcx6-vp38-8hr5 across NuGet dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.