{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/scriban/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Scriban"],"_cs_severities":["critical"],"_cs_tags":["scriban","sandbox-escape","memberfilter-bypass"],"_cs_type":"advisory","_cs_vendors":["Scriban"],"content_html":"\u003cp\u003eScriban, a .NET templating engine, is vulnerable to a sandbox escape vulnerability affecting versions prior to 7.0.0. This vulnerability arises from the \u003ccode\u003eTemplateContext\u003c/code\u003e caching type accessors without clearing them upon reset. Specifically, the \u003ccode\u003eTemplateContext\u003c/code\u003e caches accessors based on \u003ccode\u003eType\u003c/code\u003e, but these accessors are created using the \u003ccode\u003eMemberFilter\u003c/code\u003e and \u003ccode\u003eMemberRenamer\u003c/code\u003e active at the time. When a \u003ccode\u003eTemplateContext\u003c/code\u003e is reused with a tightened filter for subsequent renders, Scriban reuses the old accessor, potentially exposing members that should be hidden. This bypass allows unauthorized access or modification of filtered properties or fields, leading to policy bypass across requests, users, or tenants when contexts are pooled. The vulnerability is present in \u003ccode\u003esrc/Scriban/TemplateContext.cs\u003c/code\u003e and \u003ccode\u003esrc/Scriban/Runtime/Accessors/TypedObjectAccessor.cs\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn application initializes a \u003ccode\u003eTemplateContext\u003c/code\u003e with a permissive \u003ccode\u003eMemberFilter\u003c/code\u003e, allowing access to a wide range of object members.\u003c/li\u003e\n\u003cli\u003eThe application renders a template using the \u003ccode\u003eTemplateContext\u003c/code\u003e, creating a \u003ccode\u003eTypedObjectAccessor\u003c/code\u003e for a specific type and caching it within the \u003ccode\u003e_memberAccessors\u003c/code\u003e dictionary using the \u003ccode\u003eType\u003c/code\u003e as the key.\u003c/li\u003e\n\u003cli\u003eThe application calls \u003ccode\u003eTemplateContext.Reset()\u003c/code\u003e, which clears most of the context but crucially does \u003cem\u003enot\u003c/em\u003e clear the \u003ccode\u003e_memberAccessors\u003c/code\u003e cache.\u003c/li\u003e\n\u003cli\u003eThe application modifies the \u003ccode\u003eMemberFilter\u003c/code\u003e to be more restrictive, aiming to limit access to specific members.\u003c/li\u003e\n\u003cli\u003eThe application renders another template using the same (reused) \u003ccode\u003eTemplateContext\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen the application attempts to access members of the same type as in step 2, Scriban retrieves the cached \u003ccode\u003eTypedObjectAccessor\u003c/code\u003e from \u003ccode\u003e_memberAccessors\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe cached \u003ccode\u003eTypedObjectAccessor\u003c/code\u003e still uses the original, permissive \u003ccode\u003eMemberFilter\u003c/code\u003e, bypassing the newly configured restrictive filter.\u003c/li\u003e\n\u003cli\u003eSensitive data, which should have been filtered, is exposed or modified, leading to unauthorized access or policy bypass.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows unauthorized read or write access to properties and fields that should have been filtered by the \u003ccode\u003eMemberFilter\u003c/code\u003e. This can lead to the exposure of sensitive data, unauthorized modification of application state, and policy bypass across requests, users, or tenants. Applications that rely on \u003ccode\u003eTemplateContext.MemberFilter\u003c/code\u003e for sandboxing or object-exposure policy are particularly vulnerable. The vulnerability affects Scriban versions prior to 7.0.0.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Scriban version 7.0.0 or later to remediate the vulnerability (Affected Packages: nuget/scriban (vulnerable: \u0026lt; 7.0.0)).\u003c/li\u003e\n\u003cli\u003eAvoid reusing \u003ccode\u003eTemplateContext\u003c/code\u003e instances with different \u003ccode\u003eMemberFilter\u003c/code\u003e configurations. Create a new \u003ccode\u003eTemplateContext\u003c/code\u003e for each rendering operation with a distinct \u003ccode\u003eMemberFilter\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement server-side checks to validate and sanitize data before rendering it with Scriban to mitigate the impact of potential sandbox escapes.\u003c/li\u003e\n\u003cli\u003eMonitor Scriban template rendering for unexpected data access patterns to detect potential exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T12:00:00Z","date_published":"2024-05-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-05-02-scriban-sandbox-escape/","summary":"Scriban versions before 7.0.0 are vulnerable to a sandbox escape due to improper caching of type accessors in `TemplateContext`, leading to a `MemberFilter` bypass when a `TemplateContext` is reused, potentially exposing sensitive data.","title":"Scriban TemplateContext MemberFilter Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-05-02-scriban-sandbox-escape/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Scriban"],"_cs_severities":["high"],"_cs_tags":["denial-of-service","scriban",".net"],"_cs_type":"advisory","_cs_vendors":["Scriban"],"content_html":"\u003cp\u003eScriban versions prior to 7.0.0 are susceptible to a denial-of-service vulnerability due to uncontrolled recursion in the \u003ccode\u003eobject.to_json\u003c/code\u003e function. This function, used for recursive JSON serialization, lacks depth limits, circular reference detection, and stack overflow guards. A malicious Scriban template containing a self-referencing object, when processed by \u003ccode\u003eobject.to_json\u003c/code\u003e, triggers unbounded recursion, leading to a \u003ccode\u003eStackOverflowException\u003c/code\u003e that terminates the hosting .NET process. This vulnerability poses a significant risk to applications embedding Scriban for user-provided templates, such as CMS platforms, email template engines, and static site generators. The vulnerability is easily exploitable, requiring only a single line of template code, and does not require authentication.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Scriban template containing a self-referencing object. For example: \u003ccode\u003e{{ x = {}; x.self = x; x | object.to_json }}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe template is submitted to an application that uses Scriban for template processing.\u003c/li\u003e\n\u003cli\u003eThe Scriban engine parses the template and encounters the \u003ccode\u003eobject.to_json\u003c/code\u003e function call.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eToJson()\u003c/code\u003e function in \u003ccode\u003eObjectFunctions.cs\u003c/code\u003e calls the vulnerable \u003ccode\u003eWriteValue()\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eWriteValue()\u003c/code\u003e attempts to serialize the self-referencing object without proper recursion checks.\u003c/li\u003e\n\u003cli\u003eDue to the self-reference, \u003ccode\u003eWriteValue()\u003c/code\u003e enters an infinite recursion loop.\u003c/li\u003e\n\u003cli\u003eEach recursive call consumes stack space, eventually leading to a \u003ccode\u003eStackOverflowException\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eStackOverflowException\u003c/code\u003e terminates the entire .NET process hosting the Scriban engine, resulting in a denial of service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability leads to a denial-of-service condition, crashing the entire .NET process hosting the Scriban engine. Any application embedding Scriban for user-provided templates is vulnerable. Because \u003ccode\u003eStackOverflowException\u003c/code\u003e cannot be caught by application code, the hosting application cannot implement try/catch to survive this. This allows an unauthenticated attacker to trivially crash services using Scriban.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Scriban version 7.0.0 or later, which includes the fix for this vulnerability.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, consider implementing input validation and sanitization to prevent the use of self-referencing objects in Scriban templates.\u003c/li\u003e\n\u003cli\u003eMonitor application logs for signs of \u003ccode\u003eStackOverflowException\u003c/code\u003e errors originating from Scriban template processing.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-scriban-stack-overflow/","summary":"The Scriban library is vulnerable to a denial-of-service attack where a specially crafted template with a self-referencing object passed to the `object.to_json` function causes unbounded recursion, leading to a `StackOverflowException` that terminates the .NET process.","title":"Scriban `object.to_json` Uncontrolled Recursion DoS","url":"https://feed.craftedsignal.io/briefs/2024-01-scriban-stack-overflow/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Scriban Template Engine"],"_cs_severities":["high"],"_cs_tags":["scriban","dos","template-injection"],"_cs_type":"advisory","_cs_vendors":["Scriban"],"content_html":"\u003cp\u003eThe Scriban template engine is vulnerable to a denial-of-service attack due to a bypass in its \u003ccode\u003eLoopLimit\u003c/code\u003e functionality. This vulnerability, affecting Scriban versions prior to 7.0.0, allows attackers to craft template expressions that bypass the configured loop limits, leading to excessive CPU or memory consumption. The issue stems from the fact that \u003ccode\u003eLoopLimit\u003c/code\u003e only applies to script loop statements and not to expensive iteration performed inside operators and built-in functions such as \u003ccode\u003earray.size\u003c/code\u003e and string multiplication. An attacker can exploit this by submitting a single expression, like \u003ccode\u003e{{ 1..1000000 | array.size }}\u003c/code\u003e for CPU exhaustion or \u003ccode\u003e{{ 'A' * 200000000 }}\u003c/code\u003e for memory amplification, even when \u003ccode\u003eLoopLimit\u003c/code\u003e is set to a small value. This vulnerability impacts applications using Scriban with untrusted template content, including template-as-a-service systems, CMS, and email rendering systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Scriban template containing an expression designed to bypass \u003ccode\u003eLoopLimit\u003c/code\u003e. Example: \u003ccode\u003e{{ 1..1000000 | array.size }}\u003c/code\u003e or \u003ccode\u003e{{ 'A' * 200000000 }}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker submits the malicious template to a vulnerable application that uses Scriban for template processing.\u003c/li\u003e\n\u003cli\u003eThe application parses the template using \u003ccode\u003eTemplate.Parse()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application renders the template using \u003ccode\u003etemplate.Render(context)\u003c/code\u003e with a specified \u003ccode\u003eLoopLimit\u003c/code\u003e in \u003ccode\u003eTemplateContext\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003earray.size\u003c/code\u003e function (or string multiplication) is invoked, leading to a large number of iterations or memory allocations \u003cem\u003ewithout\u003c/em\u003e respecting the \u003ccode\u003eLoopLimit\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application's CPU or memory resources are exhausted due to the uncontrolled iteration or allocation.\u003c/li\u003e\n\u003cli\u003eThe application becomes unresponsive or crashes, resulting in a denial-of-service condition.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows for uncontrolled resource consumption, leading to denial-of-service conditions. Any application that accepts attacker-controlled templates and relies on \u003ccode\u003eLoopLimit\u003c/code\u003e is vulnerable. Observed damage includes CPU exhaustion and memory amplification. Vulnerable systems could include template-as-a-service platforms, content management systems (CMS), and email rendering systems. A successful attack can cause application downtime, impacting availability and potentially leading to data loss or corruption if the system crashes during critical operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Scriban to version 7.0.0 or later to address the vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement additional safeguards to limit the resources available to template rendering, such as setting CPU and memory limits.\u003c/li\u003e\n\u003cli\u003eImplement input validation on templates to detect and reject potentially malicious expressions. Specifically, look for large ranges used in conjunction with \u003ccode\u003earray.size\u003c/code\u003e, or excessively large string multiplications. Deploy the Sigma rules in this brief to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor application resource usage (CPU, memory) for unusual spikes during template rendering. Enable process monitoring and alerting to detect processes consuming excessive resources.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-27T12:00:00Z","date_published":"2024-01-27T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-scriban-dos/","summary":"Scriban's LoopLimit can be bypassed by crafted template expressions, allowing attackers to perform resource exhaustion through CPU or memory amplification, leading to denial of service.","title":"Scriban Template Engine LoopLimit Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-scriban-dos/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Scriban"],"_cs_severities":["high"],"_cs_tags":["scriban","template-injection","authorization-bypass"],"_cs_type":"advisory","_cs_vendors":["Scriban"],"content_html":"\u003cp\u003eScriban, a .NET templating engine, is vulnerable to an authorization bypass issue affecting applications that reuse \u003ccode\u003eTemplateContext\u003c/code\u003e objects. Specifically, versions prior to 7.0.0 do not properly clear the \u003ccode\u003eCachedTemplates\u003c/code\u003e collection when \u003ccode\u003eTemplateContext.Reset()\u003c/code\u003e is called. This can lead to a situation where an \u003ccode\u003eITemplateLoader\u003c/code\u003e that resolves content based on request-specific state (e.g., user identity, tenant context) serves a stale, previously authorized template to subsequent renders, even after the context is reset. This bypass occurs because the \u003ccode\u003einclude\u003c/code\u003e function retrieves templates from the cache without re-evaluating authorization, potentially leaking sensitive data across requests or tenants. This vulnerability could be exploited in multi-tenant or permission-sensitive applications using Scriban templates.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn application initializes a \u003ccode\u003eTemplateContext\u003c/code\u003e object and configures an \u003ccode\u003eITemplateLoader\u003c/code\u003e that resolves template content based on the current request or user context.\u003c/li\u003e\n\u003cli\u003eA user (e.g., an administrator) makes a request that causes the \u003ccode\u003eITemplateLoader\u003c/code\u003e to load a privileged template (e.g., \u0026quot;admin_profile.scriban\u0026quot;) into the \u003ccode\u003eTemplateContext\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003einclude\u003c/code\u003e function is used within the main template to load the privileged template. The compiled template is then cached in \u003ccode\u003eCachedTemplates\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application calls \u003ccode\u003eTemplateContext.Reset()\u003c/code\u003e in an attempt to clear the context for reuse. However, \u003ccode\u003eCachedTemplates\u003c/code\u003e is not cleared during this reset operation.\u003c/li\u003e\n\u003cli\u003eA different user (e.g., a regular user) makes a subsequent request that reuses the same \u003ccode\u003eTemplateContext\u003c/code\u003e object.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003einclude\u003c/code\u003e function is called again, attempting to load a template.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eTemplateContext\u003c/code\u003e retrieves the previously cached, privileged template from \u003ccode\u003eCachedTemplates\u003c/code\u003e without calling \u003ccode\u003eITemplateLoader.Load()\u003c/code\u003e again, bypassing the intended authorization check.\u003c/li\u003e\n\u003cli\u003eThe regular user is served the content of the administrator's template, leading to information disclosure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows unauthorized access to sensitive information or functionality in applications using Scriban templating. The primary impact is cross-render data isolation issues, where previously authorized template content can be leaked across different requests, users, or tenants. This can lead to the exposure of sensitive data, privilege escalation, or other security breaches, depending on the content of the leaked templates. Applications that pool or reuse \u003ccode\u003eTemplateContext\u003c/code\u003e objects, call \u003ccode\u003eReset()\u003c/code\u003e between requests, use \u003ccode\u003einclude\u003c/code\u003e for template inclusion, and resolve included content based on request-specific state are vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Scriban version 7.0.0 or later, where this vulnerability is resolved.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, avoid reusing \u003ccode\u003eTemplateContext\u003c/code\u003e objects across different requests or user sessions. Create a new \u003ccode\u003eTemplateContext\u003c/code\u003e for each request.\u003c/li\u003e\n\u003cli\u003eReview and audit existing Scriban templates and \u003ccode\u003eITemplateLoader\u003c/code\u003e implementations to ensure that sensitive data is not inadvertently exposed through template inclusion.\u003c/li\u003e\n\u003cli\u003eImplement additional authorization checks within the templates themselves to verify user permissions before displaying sensitive data, even if the \u003ccode\u003eTemplateLoader\u003c/code\u003e is compromised.\u003c/li\u003e\n\u003cli\u003eMonitor the usage of \u003ccode\u003eTemplateContext.Reset()\u003c/code\u003e in your application and ensure that it is used correctly and does not lead to unintended data leakage.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:23:00Z","date_published":"2024-01-09T18:23:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-09-scriban-auth-bypass/","summary":"Scriban versions before 7.0.0 have an authorization bypass vulnerability due to a stale include cache surviving TemplateContext.Reset(), potentially serving previously authorized content to subsequent renders in applications reusing TemplateContext objects with request-dependent ITemplateLoaders.","title":"Scriban TemplateContext Reset Authorization Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-09-scriban-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Scriban","version":"https://jsonfeed.org/version/1.1"}