Scriban EUVD-2026-59950

The attacker must be able to supply template content that is evaluated by the Scriban engine - this is the sole prerequisite. The array.insert_at built-in is registered by default in Scriban's standard function set; no special configuration is needed to expose it. The exploit succeeds regardless of the host's configured LoopLimit or LimitToString values, which are explicitly bypassed by this code path. Exploitation is limited by one factor: the attacker must have a channel to submit or influence template content (e.g., a template editor UI, an API accepting template strings, or a file upload path for templates). Applications that use Scriban exclusively for developer-authored, compile-time templates with no runtime user input are not practically exploitable. Authentication requirements depend entirely on whether the template submission channel is gated - the CVSS 4.0 PR:N vector reflects deployments where template input is available to unauthenticated users; deployments requiring authenticated users to author templates reduce exposure accordingly.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) accurately reflects the real-world severity for any application that exposes Scriban template rendering to untrusted or semi-trusted input: a single crafted template causes a complete process crash with no recovery path. The supplied CVSS vector assigns PR:N, which is appropriate for deployments where template content originates from end users or API callers - though deployments that restrict template authoring to internal staff may face lower practical risk. The absence of a CISA KEV listing and the advisory's targeted disclosure suggest exploitation has not yet been observed at broad scale; however, a working proof-of-concept template ({{ [1] | array.insert_at 200000000 'x' | array.size }}) is explicitly documented in the GHSA advisory, making weaponization trivial for any attacker who can submit templates. Even a mid-sized managed-services team in bytom running a .NET-based CMS or report-generation platform could face a complete service outage if their application processes user-supplied Scriban templates. A critical compounding factor is that operators who configured LoopLimit or LimitToString as defense-in-depth controls may believe they are protected - they are not, because this code path ignores both constraints entirely. EPSS data was not provided in the intelligence feed, but the combination of trivial PoC, unauthenticated network vector, and process-terminating impact warrants urgent prioritization for any affected deployment.

An attacker submits the template {{ [1] | array.insert_at 200000000 'x' | array.size }} to any endpoint that renders Scriban templates with user-supplied content - such as a report builder, email template editor, or CMS field. The Scriban engine evaluates array.insert_at 200000000, which enters the unguarded fill loop and attempts to allocate roughly 200 million null-entry slots; on a host with 1 GB of available memory, an OutOfMemoryException is raised in under one second and, because the exception is not caught by the renderer, the entire host process terminates. A public proof-of-concept is available in the GHSA-24c8-4792-22hx advisory. No authentication, no network reconnaissance, and no chained vulnerability are required.