If you deploy Scriban in any context where untrusted users can submit templates, you need to treat this CVE as more than a DoS fix. The vulnerability isn't that insert_at can crash your process with a large index — it's that this single function bypasses the resource constraint framework that Scriban markets as its primary safety feature for untrusted input execution.
Scriban's LoopLimit and LimitToString are documented, tested, and relied upon by security reviewers who approved Scriban for multi-tenant workloads. CVE-2026-74784 breaks that assumption entirely. A single insert_at call with index 10^8 allocates 100 million null entries in one operation — no loops, no recursion, no iteration-based constraint catches it. The constraint architecture was built around iterative operations (loops, string concatenation) but never audited against positional access methods. This means the documented security boundary is incomplete by design, not just bypassed by accident.
The supply-chain exposure is the real concern. Scriban sits as a transitive dependency in dozens of .NET products — report generators, email templating engines, dynamic configuration systems. Any product that exposes template editing to users assumed the resource limits were comprehensive. That review was wrong, and the gap wasn't hidden in obscure API — it was a single well-documented function that passed every test except the one nobody wrote.
Your immediate actions: audit any Scriban deployment that handles untrusted input and verify whether template users have access to array manipulation functions. If insert_at or similar positional methods are reachable, treat them as an active bypass of your resource exhaustion defenses. Check your Scriban version — 7.2.0 is the fix — but recognize that a single-function patch doesn't restore confidence in the broader constraint architecture. Assume other untested combinations exist until proven otherwise.