Scriban EUVD-2026-59957

Exploitation requires a specific, concrete deployment pattern in the consuming application: a TemplateContext instance that is pooled and reused (rather than created fresh per request) with reliance on TemplateContext.Reset() for isolation, combined with an ITemplateLoader whose Load()/LoadAsync() returns request-, tenant-, or user-dependent content, and use of the 'include' function with a stable template path/name across those contexts. The attacker also needs a render to have previously primed the cache with the more-privileged content (e.g., an earlier admin or other-tenant request) before the attacker's lower-privileged render reuses the same context. Limiting factors: applications that build a new TemplateContext per request, use static/non-request-dependent loaders, or do not use include are not exploitable; despite the CVSS PR:N/AC:L rating, the vulnerable pooling-plus-per-request-loader configuration is not Scriban's default usage and must be present for the leak to occur.

The signals are genuinely mixed and should be read carefully. The vendor/VulnCheck CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N, 9.2) treats this as a network, low-complexity, unauthenticated, high-confidentiality issue with a scope change to a subsequent system (another tenant/user), which is why it scores Critical. However, the AC:L/AT:N rating understates real preconditions: exploitation only works when the consuming application (a) pools and reuses a single TemplateContext across requests, (b) relies on Reset() for isolation, and (c) uses an ITemplateLoader whose Load() returns request-dependent content. Those are application-architecture conditions the attacker cannot control or guarantee, so realistic attack complexity is higher than AC:L implies. No EPSS score, KEV listing, or SSVC decision was provided in the input; absence of an EPSS/KEV signal here means exposure is unquantified rather than confirmed-low. Net assessment: a real and cleanly demonstrated confidentiality/authorization bug worth prioritizing for any product that embeds Scriban with a per-request loader and pooled contexts, but not a mass-exploitable network flaw against arbitrary Scriban deployments. The high CVSS should be tempered against those deployment-specific prerequisites.

In a multi-tenant web app that pools one TemplateContext and uses an ITemplateLoader returning per-request content, an admin request first renders '{{ include "profile" }}', priming CachedTemplates with the admin-only compiled template. A later guest/low-privilege request reusing the same context after Reset() re-evaluates the same include path, receives the cached admin template without any fresh Load()/authorization call, and reads content it was never entitled to. The GHSA advisory ships a runnable dotnet proof-of-concept (a SwitchingLoader) demonstrating exactly this stale-cache leak.