Scriban EUVD-2026-59956

Exploitation requires that the host application reuse a single TemplateContext instance across more than one render AND tighten TemplateContext.MemberFilter (or otherwise rely on it as a sandbox) between renders for the same .NET Type, while EnableRelaxedMemberAccess/MemberFilter is the mechanism controlling member exposure. The vulnerable member is any property or field of a type whose permissive accessor was cached during an earlier, looser render; calling TemplateContext.Reset() between renders does not remediate it because Reset() leaves _memberAccessors populated. Limiting factors that reduce real-world risk: applications that instantiate a fresh TemplateContext per render, that never tighten MemberFilter on a reused context, or that do not use MemberFilter as their trust boundary are not exposed; the attacker must also be able to influence or supply the template (or the members referenced) in the later, more-restricted render.

The signals partly conflict and should be weighed honestly. The published CVSS 4.0 vector (9.3; AV:N/AC:L/PR:N/UI:N/VC:H/VI:H) portrays this as a trivially exploitable, unauthenticated, network-facing critical, but the described mechanism is conditional: it only bites applications that reuse one TemplateContext across renders AND tighten the MemberFilter between them, which is a specific developer usage pattern rather than a default remote attack surface - so real-world exploitability is narrower than AC:L implies, and the VI:H (integrity) rating is questionable since the flaw exposes members for reading rather than writing. No EPSS score and no CISA KEV entry were supplied, so there is no evidence of mass or active exploitation; however, a complete proof-of-concept is published in the GHSA advisory, so weaponization effort is low for anyone targeting a known-vulnerable multi-tenant deployment. Net assessment: a genuine and high-value bug for multi-tenant SaaS or template-sandbox use cases where MemberFilter is the trust boundary - such an operator should treat cross-tenant data leakage as urgent and patch promptly - but a low-to-moderate practical concern for apps that create a fresh context per render or do not rely on MemberFilter for isolation.

A multi-tenant .NET service reuses one TemplateContext and, for a privileged first render, sets MemberFilter to allow all members of a model exposing a Secret property; it then tightens MemberFilter to allow only Public before rendering a second, lower-trust tenant's template. Because the permissive TypedObjectAccessor for that model type is already cached, the second render of '{{ model.secret }}' still returns the hidden value, leaking cross-tenant data. A public proof-of-concept demonstrating exactly this two-render leak is included in the vendor advisory.