CVE-2026-74790 in Scriban
Summary
by MITRE • 08/16/2026
Scriban before 7.0.0 caches TypedObjectAccessor by Type only without considering MemberFilter changes, allowing reused TemplateContext instances to expose members that should be hidden. Attackers can access filtered properties and fields by reusing a TemplateContext after tightening its MemberFilter, bypassing sandbox policies across requests or tenants.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability in Scriban prior to version 7.0.0 represents a critical flaw in the library's caching mechanism for TypedObjectAccessor instances, which directly undermines security controls designed to restrict access to object members within templating contexts. The core technical issue stems from the fact that the internal cache key is derived solely from the Type of the object being accessed, completely ignoring any changes made to the MemberFilter configuration on a per-request or per-tenant basis. This design oversight means that once an accessor for a specific type is cached and stored in memory, subsequent requests utilizing different security policies will retrieve this same cached instance rather than generating a new one that respects the current filtering rules. Consequently, the library fails to isolate access control boundaries between distinct execution contexts, creating a persistent state dependency that persists across request lifecycles.
From an operational perspective, this flaw allows attackers to bypass sandboxing mechanisms and tenant isolation policies by exploiting the reuse of TemplateContext instances. In multi-tenant environments or applications enforcing strict data privacy through member filtering, an attacker can first trigger a template execution where certain sensitive properties are exposed due to a loose MemberFilter setting. Once these members are cached via their Type key, subsequent requests that attempt to tighten the filter and hide those same properties will inadvertently reuse the previously cached accessor. This results in the exposure of restricted data fields or methods that were explicitly intended to be inaccessible under the new security policy. The attack does not require complex exploitation techniques; it relies on the predictable behavior of the caching system, making it a reliable method for privilege escalation and unauthorized data access within the application's logical boundary.
This vulnerability aligns with CWE-200, which classifies information exposure through misconfigured security controls, as well as CWE-697 regarding incorrect comparison logic in cache key generation. Furthermore, from an adversary perspective, this technique facilitates lateral movement or privilege escalation by allowing access to internal application states and sensitive data structures that should remain encapsulated. It maps closely to ATT&CK techniques involving unauthorized access to system resources and potentially exploitation of software vulnerabilities for initial access if the templating engine is exposed via a web interface. The impact extends beyond simple data leakage, as it compromises the integrity of multi-tenant architectures where strict isolation between tenants is paramount for compliance with standards such as GDPR or HIPAA.
Mitigation strategies must prioritize immediate upgrading to Scriban version 7.0.0 or later, where this caching logic has been corrected to include MemberFilter parameters in the cache key calculation. This ensures that distinct security contexts generate distinct accessor instances, thereby preserving the intended isolation boundaries. For applications unable to upgrade immediately due to dependency constraints, a temporary workaround involves disabling object caching entirely if performance impact is acceptable, or implementing custom wrapper classes that enforce strict context separation and prevent the reuse of TemplateContexts across different tenant sessions. Additionally, developers should audit existing templates for reliance on cached accessors and ensure that security policies are applied at the earliest possible stage in the request lifecycle to minimize the window of exposure before caching occurs. Regular security assessments focusing on template injection and sandbox bypass techniques are recommended to detect similar misconfigurations in other templating engines or custom implementations.