CVE-2026-74789 in Scriban
Summary
by MITRE • 08/16/2026
Scriban before 7.0.0 (affected <= 6.6.0) applies its LoopLimit constraint only to script loop statements and not to expensive iteration performed inside built-in operators and functions. As a result, a single expression such as {{ 1..1000000 | array.size }} — or a memory-amplification expression such as {{ 'A' * 200000000 }} — can force large CPU or memory consumption even when LoopLimit is configured to a very small value, resulting in denial of service. Applications that render attacker-controlled templates and rely on LoopLimit for safe execution are affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability identified in Scriban versions prior to 7.0.0 represents a significant flaw in the template engine's resource management logic, specifically concerning how it enforces safety constraints against denial of service attacks. The core issue lies in an incomplete implementation of the LoopLimit configuration parameter. While this limit is correctly applied to explicit script loop statements such as for or foreach loops, it fails to extend its protective scope to expensive iteration operations performed within built-in operators and functions. This inconsistency creates a critical bypass mechanism where attackers can circumvent intended resource caps by utilizing specific template expressions that trigger internal iterations outside the purview of the LoopLimit check.
From a technical perspective, the flaw allows for both CPU exhaustion and memory amplification through carefully crafted input strings. For instance, an expression like {{ 1..1000000 | array.size }} forces the engine to iterate over a massive range to calculate its size, consuming substantial processing power without triggering the loop limit protection. Similarly, string multiplication operations such as {{ 'A' * 200000000 }} can allocate hundreds of megabytes or even gigabytes of memory in a single expression. Because these operations are handled by built-in functions rather than explicit control flow statements, they remain unchecked against the configured safety thresholds. This design oversight means that applications relying on LoopLimit to prevent resource exhaustion when rendering user-supplied templates are left vulnerable to abuse.
The operational impact of this vulnerability is severe for any service that processes untrusted template data. An attacker can craft a malicious payload that causes the application server to become unresponsive due to high CPU usage or memory allocation failures, effectively leading to a denial of service condition. This type of attack does not require code execution privileges but merely access to the templating interface, making it particularly dangerous in web applications where templates are rendered based on user input. The ability to force large resource consumption can degrade performance for legitimate users and potentially crash the hosting process if memory limits are exceeded.
This vulnerability aligns with CWE-787: Out-of-bounds Write when considering potential memory corruption risks, though it is more accurately classified under CWE-400: Uncontrolled Resource Consumption due to its primary impact on availability through resource exhaustion. In terms of attack vectors and tactics, this behavior corresponds to the ATT&CK technique T1496: Resource Hijacking, where an adversary uses computing resources for their own purposes rather than those intended by system administrators or users. It also relates to CWE-755: Improper Handling of Unexpected Data Type if one considers that the engine fails to properly validate the computational cost associated with different data operations.
Mitigation strategies must prioritize upgrading to Scriban version 7.0.0 or later, where this inconsistency in LoopLimit enforcement has been addressed. For applications unable to upgrade immediately, developers should implement additional safeguards such as strict input validation on template strings, limiting the complexity of allowed expressions via a whitelist approach, and deploying resource monitoring tools that can detect abnormal spikes in CPU or memory usage associated with template rendering. Additionally, running templating engines within isolated environments with hard limits on memory allocation and execution time can provide an extra layer of defense against such exploitation attempts.