GHSA-v66j-x4hw-fv9g: Scriban: Uncontrolled Memory Allocation via string.pad_left/pad_right Allows Remote Denial of Service

Summary The built-in string.pad_left and string.pad_right template functions in Scriban perform no validation on the width parameter, allowing a template expression to allocate arbitrarily large strings in a single call. When Scriban is exposed to untrusted template input — as in the official Scriban.AppService playground deployed on Azure — an unauthenticated attacker can trigger ~1GB memory allocations with a 39-byte payload, crashing the service via OutOfMemoryException. Details StringFunctions.PadLeft and StringFunctions.PadRight (src/Scriban/Functions/StringFunctions.cs:1181-1203) directly delegate to .NET's String.PadLeft(int) / String.PadRight(int) with no bounds checking: // src/Scriban/Functions/StringFunctions.cs:1181-1183 public static string PadLeft(string text, int width) { return (text ?? string.Empty).PadLeft(width); } // src/Scriban/Functions/StringFunctions.cs:1200-1202 public static string PadRight(string text, int width) { return (text ?? string.Empty).PadRight(width); } The TemplateContext.LimitToString property (default 1MB, set at TemplateContext.cs:147) does not prevent the allocation. This limit is only checked during ObjectToString() conversion (TemplateContext.Helpers.cs:101-103), which runs *after* the string has been fully allocated by PadLeft/PadRight. The dangerous allocation is the return value of a built-in function — it occurs before output rendering. The Scriban.AppService playground (src/Scriban.AppService/Program.cs:63-140) exposes POST /api/render with: - No authentication - Template size limit of 1KB (line 71) — the payload fits in 39 bytes - A 2-second timeout via CancellationTokenSource (line 118) — but this only cancels the await Task.Run(...), not the running template.Render() call (line 122). The BCL PadLeft allocation completes atomically before the cancellation can take effect. - Rate limiting of 30 requests/minute (line 25) PoC Single r