Scriban has an authorization bypass due to stale include cache surviving TemplateContext.Reset()
## Summary `TemplateContext.Reset()` claims that a `TemplateContext` can be reused safely on the same thread, but it does not clear `CachedTemplates`. If an application pools `TemplateContext` objects and uses an `ITemplateLoader` that resolves content per request, tenant, or user, a previously authorized include can be served to later renders without calling `TemplateLoader.Load()` again. ## Details The relevant code path is: - `TemplateContext.Reset()` only clears output, globals, cultures, and source files in `src/Scriban/TemplateContext.cs` lines 877–902. - `CachedTemplates` is initialized once and kept on the context in `src/Scriban/TemplateContext.cs` line 197. - `include` resolves templates through `IncludeFunction.Invoke()` in `src/Scriban/Functions/IncludeFunction.cs` lines 29–43. - `IncludeFunction.Invoke()` calls `TemplateContext.GetOrCreateTemplate()` in `src/Scriban/TemplateContext.cs` lines 1249–1256. - If a template path is already present in `CachedTemplates`, Scriban returns the cached compiled template and does **not** call `TemplateLoader.Load()` again. This becomes a security issue when `ITemplateLoader.Load()` returns request-dependent content. A first render can prime the cache with an admin-only or tenant-specific template, and later renders on the same reused `TemplateContext` will receive that stale template even after `Reset()`. --- ## Proof of Concept ### Setup ```bash mkdir scriban-poc1 cd scriban-poc1 dotnet new console --framework net8.0 dotnet add package Scriban --version 6.6.0 ``` ### `Program.cs` ```csharp 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); } ``` ### Run ```bash dotnet run ``` ### Actual Output ``` first=admin-only second=admin-only ``` ### Expected Output ``` 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. --- ## Impact 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: - Pool or reuse `TemplateContext` - Call `Reset()` between requests - Use `include` - Resolve include content based on request-specific state
AI Analysis
Technical Summary
The vulnerability arises because TemplateContext.Reset() does not clear the CachedTemplates dictionary, which stores compiled templates. When include statements are used, Scriban checks CachedTemplates and returns cached templates without calling the TemplateLoader.Load() method again. If the TemplateLoader returns content that varies per request, tenant, or user, a previously cached template with restricted content can be reused across different requests after Reset(), leading to unauthorized template content exposure. This affects applications that pool or reuse TemplateContext instances, call Reset() between requests, use include statements, and have request-dependent template loading.
Potential Impact
This vulnerability can cause unauthorized disclosure of sensitive template content across requests, users, or tenants. Specifically, templates intended for admin-only or tenant-specific views may be served to unauthorized users due to stale cached templates surviving context resets. This breaks data isolation guarantees in multi-tenant or multi-user applications using Scriban with request-dependent template loading and TemplateContext reuse.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid reusing TemplateContext instances across requests when using request-dependent ITemplateLoader implementations. Alternatively, avoid relying on TemplateContext.Reset() to clear cached templates or disable template caching if possible. Monitor vendor communications for updates on patches addressing this issue.
Scriban has an authorization bypass due to stale include cache surviving TemplateContext.Reset()
Description
## Summary `TemplateContext.Reset()` claims that a `TemplateContext` can be reused safely on the same thread, but it does not clear `CachedTemplates`. If an application pools `TemplateContext` objects and uses an `ITemplateLoader` that resolves content per request, tenant, or user, a previously authorized include can be served to later renders without calling `TemplateLoader.Load()` again. ## Details The relevant code path is: - `TemplateContext.Reset()` only clears output, globals, cultures, and source files in `src/Scriban/TemplateContext.cs` lines 877–902. - `CachedTemplates` is initialized once and kept on the context in `src/Scriban/TemplateContext.cs` line 197. - `include` resolves templates through `IncludeFunction.Invoke()` in `src/Scriban/Functions/IncludeFunction.cs` lines 29–43. - `IncludeFunction.Invoke()` calls `TemplateContext.GetOrCreateTemplate()` in `src/Scriban/TemplateContext.cs` lines 1249–1256. - If a template path is already present in `CachedTemplates`, Scriban returns the cached compiled template and does **not** call `TemplateLoader.Load()` again. This becomes a security issue when `ITemplateLoader.Load()` returns request-dependent content. A first render can prime the cache with an admin-only or tenant-specific template, and later renders on the same reused `TemplateContext` will receive that stale template even after `Reset()`. --- ## Proof of Concept ### Setup ```bash mkdir scriban-poc1 cd scriban-poc1 dotnet new console --framework net8.0 dotnet add package Scriban --version 6.6.0 ``` ### `Program.cs` ```csharp 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); } ``` ### Run ```bash dotnet run ``` ### Actual Output ``` first=admin-only second=admin-only ``` ### Expected Output ``` 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. --- ## Impact 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: - Pool or reuse `TemplateContext` - Call `Reset()` between requests - Use `include` - Resolve include content based on request-specific state
CVSS v3.1
Score 8.6high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises because TemplateContext.Reset() does not clear the CachedTemplates dictionary, which stores compiled templates. When include statements are used, Scriban checks CachedTemplates and returns cached templates without calling the TemplateLoader.Load() method again. If the TemplateLoader returns content that varies per request, tenant, or user, a previously cached template with restricted content can be reused across different requests after Reset(), leading to unauthorized template content exposure. This affects applications that pool or reuse TemplateContext instances, call Reset() between requests, use include statements, and have request-dependent template loading.
Potential Impact
This vulnerability can cause unauthorized disclosure of sensitive template content across requests, users, or tenants. Specifically, templates intended for admin-only or tenant-specific views may be served to unauthorized users due to stale cached templates surviving context resets. This breaks data isolation guarantees in multi-tenant or multi-user applications using Scriban with request-dependent template loading and TemplateContext reuse.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid reusing TemplateContext instances across requests when using request-dependent ITemplateLoader implementations. Alternatively, avoid relying on TemplateContext.Reset() to clear cached templates or disable template caching if possible. Monitor vendor communications for updates on patches addressing this issue.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-x6m9-38vm-2xhf
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["NuGet"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a4c346127e9c79719600adb
Added to database: 07/06/2026, 23:04:01 UTC
Last enriched: 07/06/2026, 23:33:42 UTC
Last updated: 07/31/2026, 12:27:30 UTC
Views: 17
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.