Scriban TemplateContext MemberFilter Bypass Vulnerability
Scriban versions before 7.0.0 are vulnerable to a sandbox escape due to improper caching of type accessors in `TemplateContext`, leading to a `MemberFilter` bypass when a `TemplateContext` is reused, potentially exposing sensitive data.
Scriban, a .NET templating engine, is vulnerable to a sandbox escape vulnerability affecting versions prior to 7.0.0. This vulnerability arises from the TemplateContext caching type accessors without clearing them upon reset. Specifically, the TemplateContext caches accessors based on Type, but these accessors are created using the MemberFilter and MemberRenamer active at the time. When a TemplateContext is reused with a tightened filter for subsequent renders, Scriban reuses the old accessor, potentially exposing members that should be hidden. This bypass allows unauthorized access or modification of filtered properties or fields, leading to policy bypass across requests, users, or tenants when contexts are pooled. The vulnerability is present in src/Scriban/TemplateContext.cs and src/Scriban/Runtime/Accessors/TypedObjectAccessor.cs.
Attack Chain
- An application initializes a
TemplateContextwith a permissiveMemberFilter, allowing access to a wide range of object members. - The application renders a template using the
TemplateContext, creating aTypedObjectAccessorfor a specific type and caching it within the_memberAccessorsdictionary using theTypeas the key. - The application calls
TemplateContext.Reset(), which clears most of the context but crucially does not clear the_memberAccessorscache. - The application modifies the
MemberFilterto be more restrictive, aiming to limit access to specific members. - The application renders another template using the same (reused)
TemplateContext. - When the application attempts to access members of the same type as in step 2, Scriban retrieves the cached
TypedObjectAccessorfrom_memberAccessors. - The cached
TypedObjectAccessorstill uses the original, permissiveMemberFilter, bypassing the newly configured restrictive filter. - Sensitive data, which should have been filtered, is exposed or modified, leading to unauthorized access or policy bypass.
Impact
Successful exploitation of this vulnerability allows unauthorized read or write access to properties and fields that should have been filtered by the MemberFilter. This can lead to the exposure of sensitive data, unauthorized modification of application state, and policy bypass across requests, users, or tenants. Applications that rely on TemplateContext.MemberFilter for sandboxing or object-exposure policy are particularly vulnerable. The vulnerability affects Scriban versions prior to 7.0.0.
Recommendation
- Upgrade to Scriban version 7.0.0 or later to remediate the vulnerability (Affected Packages: nuget/scriban (vulnerable: < 7.0.0)).
- Avoid reusing
TemplateContextinstances with differentMemberFilterconfigurations. Create a newTemplateContextfor each rendering operation with a distinctMemberFilter. - Implement server-side checks to validate and sanitize data before rendering it with Scriban to mitigate the impact of potential sandbox escapes.
- Monitor Scriban template rendering for unexpected data access patterns to detect potential exploitation attempts.
Detection coverage 2
Detect Scriban TemplateContext Reset Without Member Accessor Clear
mediumDetects code patterns where TemplateContext.Reset() is called without clearing member accessors, indicating potential for MemberFilter bypass.
Detect Scriban Template Rendering with Changing Member Filters
mediumDetects code patterns where a Scriban template is rendered with TemplateContext and MemberFilter is changed without creating new TemplateContext.
Detection queries are available on the platform. Get full rules →