Scriban CVE-2026-74795

Exploitation requires that the target application passes attacker-controlled or user-supplied content directly to Scriban's Template.Parse() method while using the default ParserOptions configuration where ExpressionDepthLimit is null. Applications that already set an explicit ExpressionDepthLimit value are not vulnerable. No authentication, privilege escalation, or special network positioning is required beyond the ability to reach any endpoint that triggers template parsing of untrusted input. Exploitation is bounded to applications that process untrusted templates - services using only internally-authored, trusted templates at fixed code paths are not at risk regardless of the installed Scriban version.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) confirms this is network-reachable, requires no authentication, no special attack preconditions, and no user interaction, with high availability impact. This is not a high-CVSS-but-low-real-risk scenario: the attack payload is trivially constructable (a string of repeated parentheses), the failure mode is unrecoverable without a process restart, and a working proof-of-concept is publicly available in the GitHub Security Advisory. EPSS data was not present in the available intelligence, so a quantitative exploitation probability cannot be cited. KEV listing is not confirmed, indicating no verified mass exploitation campaign at time of analysis - though the low attack complexity and public PoC substantially lower the bar for opportunistic abuse. The primary real-world limiting factor is deployment scope: only applications that pass untrusted or attacker-influenced input to Scriban's parser are at risk; internally-authored template pipelines are not exposed regardless of version.

An unauthenticated attacker sends an HTTP request to a web API that renders Scriban templates from user-controlled input, embedding a payload such as 10,000 nested parentheses (e.g., {{ ((((...(1)...))) }}). The Scriban parser descends recursively into each nesting level without any depth limit, exhausting the thread stack and raising an uncatchable StackOverflowException that immediately terminates the entire .NET hosting process. A working proof-of-concept demonstrating this crash is publicly documented in the GHSA advisory, lowering the exploitation bar significantly.