CVE-2026-74784 in Scriban
Summary
by MITRE • 08/16/2026
Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
The Scriban templating engine, prior to version 7.2.0, contains a critical denial of service vulnerability within its array manipulation logic, specifically affecting the insert_at function. This flaw stems from an improper handling of input parameters when inserting elements into arrays at specific indices. The core technical issue lies in the failure of the implementation to enforce resource limits defined by LoopLimit or LimitToString constraints during this operation. When a user supplies a large index parameter for insertion, the engine attempts to allocate memory for null entries up to that index without checking against established boundaries designed to prevent excessive resource consumption. This lack of validation allows an attacker to trigger unbounded memory allocation, leading directly to an OutOfMemoryException and causing the host process to crash in under one second.
From a technical perspective, this vulnerability represents a classic case of insufficient input validation combined with improper limit enforcement. The Scriban engine is designed to protect against infinite loops and excessive resource usage through configurable limits such as LoopLimit, which restricts the number of iterations or operations allowed during template execution. However, the array.insert_at function bypasses these safeguards by directly allocating memory based on the provided index value rather than respecting the configured constraints. This behavior deviates from secure coding practices where all user-supplied data must be validated against expected ranges and system limits before processing. The absence of bounds checking allows for a rapid exhaustion of available heap space, resulting in application instability or complete failure.
The operational impact of this vulnerability is severe due to its potential for remote exploitation if Scriban is used within web applications or services that process untrusted template inputs. An attacker can craft a malicious payload containing an excessively large index value and submit it through any interface that accepts Scriban templates, such as API endpoints, email generators, or dynamic content renderers. The resulting denial of service condition disrupts availability for legitimate users and may require manual intervention to restart the affected services. In environments where high availability is critical, this single point of failure can lead to significant business disruption. Furthermore, repeated exploitation attempts could contribute to broader infrastructure strain if not properly monitored or rate-limited at the network level.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-20, indicating improper input validation. In terms of attack vectors and techniques, it corresponds to MITRE ATT&CK technique T1499, specifically endpoint denial of service via application layer attacks. The exploitability is high given the simplicity of the required payload and the speed at which the crash occurs. Mitigation strategies should prioritize upgrading to Scriban version 7.2.0 or later, where this issue has been addressed by enforcing proper bounds checking on array operations regardless of input values. Additionally, organizations implementing older versions should apply compensating controls such as strict rate limiting on template rendering endpoints and deploying web application firewalls that can detect and block requests with unusually large numeric parameters in template contexts. Monitoring for OutOfMemoryException events in logs can also aid in early detection of exploitation attempts while patches are being applied.