CVE-2026-73061

CVE-2026-73061 exposes a vulnerability in Scriban's TypedObjectAccessor that bypasses C# access modifiers, allowing template scripts to mutate init-only properties and private setters that developers expected to be immutable. The CVSS 9.8 reflects not just ease of exploitation, but the cascading architectural violations that follow: when a developer marks a property init-only, they're encoding a domain invariant — that an object's state cannot change after construction. Scriban silently invalidates that invariant, and worse, does so without any runtime signal. The mutation succeeds, tests pass, and the system ships with corrupted state that no one detected. This is the same vulnerability class that produced CVE-2012-1823 in Rails (mass assignment) and multiple Laravel fillable/guarded bypasses — a pattern where templating or ORM layers built for developer convenience bypass language-level access controls. The fact that Scriban arrived at the same flaw in 2026, with the same 9.8 severity, indicates the template engine ecosystem has not internalized lessons from a decade of identical CVEs across other stacks. If you're running Scriban below 7.2.2, upgrade immediately. But the patch alone isn't sufficient. Audit every location where you pass CLR objects to templates — particularly value objects, DDD aggregate roots, and financial records built on post-construction immutability. The blast radius of this bypass isn't the property mutation itself; it's every downstream assumption that relied on that immutability. A system that exposed an init-only transaction object to a template may now have silently corrupted records in production with no error and no log. Assume zero-trust by default when exposing any CLR object to the template layer. The template engine's convenience API was never designed as a security boundary, and documentation never stated otherwise. Retrofitting visibility enforcement into an accessor built without it requires architectural changes — either explicit permission models that break backward compatibility, or accepting that the template layer cannot guarantee the access control semantics C# provides. Until that contract is explicit in documentation and enforced in code, treat every template-object interaction as mutable unless you've explicitly designed it otherwise.

Reviewed through automated stages and approved by a human before publication.