Scriban: Zwei kritische Schwachstellen erlauben Zugriff auf geschützte Objektmember

Kurzfassung

Die Template-Engine Scriban hat zwei kritische Schwachstellen, die vor den Versionen 7.2.2 und 7.0.0 liegen. Beide Probleme drehen sich um den Zugriff auf CLR-Objekte aus Templates heraus. In der Praxis kann das dazu führen, dass ein Angreifer geschützte Eigenschaften ausliest oder sogar Objektzustände verändert, obwohl die Sandbox das eigentlich verhindern soll.

Für Unternehmen im DACH-Raum ist das vor allem dann relevant, wenn Scriban für Mandanten-Trennung, Konfigurationslogik oder dynamische Inhalte eingesetzt wird. Wer Templates mit Nutzereingaben oder fremden Daten füttert, sollte die Lage zügig prüfen. Privatnutzer sind nur am Rand betroffen; die Schwachstellen zielen klar auf Anwendungen und deren Serverlogik.

Was ist passiert?

Betroffen sind zwei Fehler in Scriban: CVE-2026-73061 und CVE-2026-74790. Beide werden als kritisch eingestuft. Sie betreffen unterschiedliche Schutzmechanismen, greifen aber am gleichen Punkt an: dem Umgang mit Objektzugriffen im Template-Kontext.

CVE-2026-73061 erlaubt es Template-Code, Eigenschaften von CLR-Objekten zu schreiben, obwohl die Zugriffsregeln das eigentlich untersagen. Das betrifft auch Properties mit privatem, internem oder nur beim Initialisieren gesetztem Setter. CVE-2026-74790 sorgt dafür, dass ein zwischengespeicherter Zugriffskontext Mitglieder sichtbar machen kann, die nach einer Verschärfung des MemberFilters verborgen bleiben sollten.

Technische Details

Bei CVE-2026-73061 liegt das Problem im TypedObjectAccessor. Die Komponente prüft die Sichtbarkeit von Settern zu lax. Ein Angreifer kann dadurch nicht nur Werte in öffentliche Properties schreiben, sondern auch Felder und Eigenschaften beeinflussen, die eigentlich geschützt sein müssten. Nach dem Rendern können diese Änderungen dauerhaft im Host-Objekt bleiben.

Das ist mehr als ein klassischer Lesezugriff. Wer Templates zur Datenaufbereitung oder zur Steuerung von Geschäftslogik nutzt, öffnet damit die Tür zu Manipulationen am Objektzustand. Aus Sicht eines Angreifers ist das attraktiv, weil sich so Berechtigungen, Flags oder interne Zustände unbemerkt verbiegen lassen.

CVE-2026-74790 betrifft das Caching von TypedObjectAccessor. Scriban berücksichtigt beim Cache nur den Typ, nicht aber spätere Änderungen am MemberFilter. Wenn derselbe TemplateContext weiterverwendet wird, kann ein strengerer Filter umgangen werden, weil zuvor aufgelöste Mitglieder wieder auftauchen. Das bricht die Annahme, dass eine nachträgliche Einschränkung auch wirklich greift.

Gerade in Multi-Tenant-Umgebungen ist das unschön. Ein Kontext, der für Mandant A einmal weiter geöffnet wurde, kann bei schlampiger Wiederverwendung auch Mandant B zu viel zeigen. Das ist kein theoretisches Detail, sondern ein typischer Fehler in Serveranwendungen, die Zustände wiederverwenden, um Performance zu sparen.

Wer ist betroffen?

Betroffen sind Anwendungen, die Scriban vor Version 7.2.2 einsetzen oder noch auf einer Version vor 7.0.0 laufen. Die Quellenlage nennt keine weiteren Produktreihen. Ob auch Forks, eingebettete Bibliotheken oder verpackte Software in Ihrer Umgebung betroffen sind, muss im Einzelfall geprüft werden.

In der Praxis trifft es vor allem Entwicklerteams und Plattformbetreiber. Wer Scriban für SaaS-Funktionen, Self-Service-Portale, Konfigurationsgeneratoren oder tenantfähige Dienste nutzt, sollte den Einsatz sofort inventarisieren. Für klassische Desktop- oder Consumer-Szenarien gibt es nach dem vorliegenden Stand keinen belastbaren Hinweis auf ein breites Endnutzer-Risiko.

Empfohlene Maßnahmen

Priorität eins ist das Update auf eine gefixte Scriban-Version. Wer noch unter 7.2.2 arbeitet, sollte das Paket zeitnah anheben. Läuft eine Umgebung sogar vor 7.0.0, gilt das erst recht, weil dort zusätzlich das Cache-Problem greift. Prüfen Sie dabei auch indirekte Abhängigkeiten in NuGet-Paketen oder internen Komponenten.

Danach lohnt ein Blick auf die Nutzung des TemplateContext. Wenn derselbe Kontext zwischen Requests, Nutzern oder Mandanten wiederverwendet wird, ist das riskant. Besser ist eine strikte Trennung pro Anfrage. Alte Kontextobjekte sollten nicht mit geänderten MemberFiltern weiterlaufen.

Admins und Entwickler sollten außerdem Templates auditieren, die auf interne Objektmodelle zugreifen. Wo möglich, nur freigegebene Datenstrukturen an Templates geben. Alles andere lädt zu Missbrauch ein. Logging auf ungewöhnliche Template-Zugriffe und Tests mit gesperrten Properties helfen, Fehlkonfigurationen schneller zu finden.

Einschätzung von CyberSecurity-News.de

Die beiden Lücken sind ernst zu nehmen, weil sie an einer heiklen Stelle sitzen: an der Grenze zwischen Template-Logik und Host-Objekt. Genau dort erwarten viele Teams eine harte Trennung. Wenn ein Template private oder intern gedachte Eigenschaften manipulieren kann, ist das kein Randproblem, sondern ein direkter Bruch des Sicherheitsmodells.

Wirklich kritisch wird es überall dort, wo Skript- oder Template-Kontexten zu viel Vertrauen geschenkt wird. Die zweite Schwachstelle zeigt zudem ein typisches Praxisproblem: Filter werden verschärft, aber der Zustand wird aus Performancegründen weiterverwendet. Das spart Sekunden und öffnet Türen. Wer solche Muster im Code hat, sollte sie jetzt überprüfen.

Die Informationslage ist allerdings knapp. Der Herstellerkontext, konkrete Angriffsszenarien und mögliche Folgeschäden in realen Produkten bleiben in der Quelle offen. Genau deshalb sollte man nicht dramatisieren, aber auch nicht abwarten. Für Organisationen mit Scriban im produktiven Einsatz ist das ein klarer Patch- und Review-Fall.

Fazit

Scriban vor 7.2.2 und vor 7.0.0 enthält zwei kritische Schwachstellen, die entweder geschützte Objektmember freilegen oder Sandbox-Regeln aushebeln können. Wer die Engine in serverseitigen Anwendungen nutzt, sollte Versionen, Cache-Verhalten und Template-Zugriffe jetzt prüfen. Besonders wichtig ist die Frage, ob ein TemplateContext zwischen Anfragen oder Mandanten wiederverwendet wird.

Für die meisten Leser ist das kein Bremsklotz im Alltag. Für Teams mit Scriban im Produktivbetrieb ist es aber ein sauberer Prioritätsfall. Erst patchen, dann Kontextnutzung und Datenfreigaben nachziehen.