Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability is an authorization bypass in the Scriban template engine, caused by a stale cache. The root cause is the Scriban.TemplateContext.Reset method, which was intended to prepare a TemplateContext object for reuse but failed to clear the CachedTemplates dictionary. The patch for this vulnerability, found in commit 099cb0491df92fafda95acb8c731c60d765bf41a, adds the line CachedTemplates.Clear(); to the Reset method, rectifying this omission.
When an application pools and reuses TemplateContext objects, the following sequence of events can occur:
include directive is compiled and stored in CachedTemplates.TemplateContext.Reset() to clean up the context before reusing it for another user.CachedTemplates are not cleared.TemplateContext object.include directive is rendered for the second user, the Scriban.Functions.IncludeFunction.Invoke method is called. This in turn calls Scriban.TemplateContext.GetOrCreateTemplate, which finds the sensitive template in the still-populated CachedTemplates and returns it, bypassing the ITemplateLoader's authorization logic. This results in the sensitive data from the first user being leaked to the second user.The identified vulnerable functions are therefore Scriban.TemplateContext.Reset (the root cause) and Scriban.Functions.IncludeFunction.Invoke and Scriban.TemplateContext.GetOrCreateTemplate as key components of the runtime exploitation path.
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| scriban | nuget | < 7.0.0 | 7.0.0 |
| Scriban.Signed | nuget | < 7.0.0 | 7.0.0 |
using Scriban;
using Scriban.Parsing;
using Scriban.Runtime;
var loader = new SwitchingLoader();
var context = new TemplateContext
{
TemplateLoader = loader,
};
var template = Template.Parse("{{ include 'profile' }}");
loader.Content = "admin-only";
Console.WriteLine("first=" + template.Render(context));
context.Reset();
loader.Content = "guest-view";
Console.WriteLine("second=" + template.Render(context));
sealed class SwitchingLoader : ITemplateLoader
{
public string Content { get; set; } = string.Empty;
public string GetPath(TemplateContext context, SourceSpan callerSpan, string templateName) => templateName;
public string Load(TemplateContext context, SourceSpan callerSpan, string templatePath) => Content;
public ValueTask<string> LoadAsync(TemplateContext context, SourceSpan callerSpan, string templatePath)
=> new(Content);
}
dotnet run
first=admin-only
second=admin-only
first=admin-only
second=guest-view
The second render should reload the template after Reset(), but it instead reuses the cached compiled template from the previous render.
This is a cross-render data isolation issue. Any application that reuses TemplateContext objects and uses a request-dependent ITemplateLoader can leak previously authorized template content across requests, users, or tenants.
The issue impacts applications that:
TemplateContextReset() between requestsinclude