CVE-2026-73060 in Scriban
Summary
by MITRE • 08/16/2026
Scriban versions from 3.0.0 through 7.2.5 contain a denial of service vulnerability in the ScriptRange.Multiply operator that bypasses LoopLimit when the left operand is a lazy sequence. Attackers can supply templates with array multiplication on lazy sequences to execute billions of uncharged iterations, pinning CPU cores and exhausting garbage collection resources even when LoopLimit is set to 1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability identified in Scriban versions ranging from 3.0.0 through 7.2.5 represents a critical resource exhaustion flaw within the template engine's arithmetic evaluation logic, specifically targeting the ScriptRange.Multiply operator. This issue arises when the left operand of the multiplication operation is defined as a lazy sequence rather than a standard array or integer value. In typical usage scenarios, Scriban employs a LoopLimit mechanism to prevent infinite loops and excessive resource consumption during template rendering. However, this safeguard fails to apply correctly in the specific context of multiplying lazy sequences by integers. The engine incorrectly calculates the iteration count for these operations, effectively bypassing the configured loop limits that are intended to cap computational complexity. This design flaw allows an attacker to construct malicious templates where array multiplication on lazy sequences triggers billions of uncharged iterations, leading to severe performance degradation and potential service disruption.
From a technical perspective, the core issue lies in how the Scriban interpreter handles memory allocation and iteration bounds for lazy-loaded data structures during arithmetic operations. Lazy sequences are designed to compute values only when accessed, which is generally efficient for large datasets. However, when such a sequence is used as the left operand in a multiplication operation within the ScriptRange context, the engine fails to enforce the global LoopLimit constraint that governs other loop constructs like ForEach or While loops. Consequently, the interpreter proceeds with an unbounded number of iterations proportional to the size of the lazy sequence multiplied by the right-hand integer operand. This results in excessive CPU utilization as cores are pinned to handle the massive computational load, and significant memory pressure due to garbage collection overhead from creating numerous intermediate objects during these unchecked iterations. The vulnerability is particularly insidious because it operates silently under normal conditions until triggered by a specifically crafted input that exploits this logical gap in the loop limit enforcement mechanism.
The operational impact of this denial of service vulnerability can be severe for any application relying on Scriban for dynamic template rendering, such as web applications generating HTML emails or server-side rendered pages. An attacker who has control over user-supplied template content or data passed into templates can exploit this flaw to cause a sustained CPU spike that renders the host system unresponsive. This effectively denies service to legitimate users by consuming all available processing resources on the affected machine. Furthermore, the exhaustion of garbage collection resources may lead to increased latency in application response times even after the malicious request completes, as the runtime struggles to reclaim memory from the massive number of short-lived objects created during the attack. In cloud environments or containerized deployments, this could trigger auto-scaling events or cause node failures if resource limits are not strictly enforced at the infrastructure level, thereby amplifying the impact beyond a single process crash.
To mitigate this vulnerability, organizations must immediately upgrade Scriban to version 7.2.6 or later, where the loop limit enforcement logic has been corrected for lazy sequence multiplication operations. For environments where upgrading is not immediately feasible, implementing strict input validation and sanitization of template strings can help prevent exploitation by rejecting templates that contain suspicious array multiplication patterns involving large integers or complex nested structures. Additionally, deploying runtime application self-protection tools or web application firewalls with rules targeting abnormal CPU usage spikes associated with Scriban processing may provide a layer of defense against active attacks. It is also advisable to review template rendering configurations and ensure that LoopLimit settings are consistently applied across all execution paths within the engine. Monitoring system metrics for unusual patterns in garbage collection frequency and CPU utilization can aid in early detection of such abuse attempts, allowing security teams to respond before significant service disruption occurs. This incident underscores the importance of rigorous testing of edge cases in template engines, particularly those involving lazy evaluation mechanisms that interact with arithmetic operators.