Ssti — CraftedSignal Threat Feed

Kirby CMS Server-Side Template Injection via Double Template Resolution

hello@craftedsignal.io — Thu, 23 Apr 2026 21:24:37 +0000

A server-side template injection (SSTI) vulnerability has been identified in Kirby CMS affecting sites using option fields (checkboxes, color, multiselect, select, radio, tags, or toggles) with options sourced from queries or APIs where the values cannot be fully trusted. This vulnerability, discovered and reported by @offset, stems from a double resolution of templates within the options rendering logic. An attacker with Panel access or through user interaction can inject malicious query templates. This can lead to unauthorized access to sensitive information (like user passwords) or malicious modification of site content. The vulnerability affects Kirby CMS versions prior to 4.9.0 and versions between 5.0.0 and 5.4.0.

Attack Chain

An attacker gains access to the Kirby Panel, or convinces a user with access to interact with a malicious element.
The attacker identifies a page or blueprint using dynamic options for form fields (checkboxes, selects, etc.) sourced from a query or API.
The attacker injects a malicious query template, such as {{ users.first.password }} or {{ page.delete }}, into a page title or data returned from an external API.
The administrator or another privileged user navigates to the affected Panel view, triggering the rendering of the form field with the injected malicious template.
The Kirby CMS options logic improperly double-resolves the template, executing the injected query.
The attacker gains access to sensitive information, such as user passwords, or triggers unauthorized actions like page deletion, depending on the injected query.
The attacker escalates privileges by exploiting the compromised user’s session or by directly accessing sensitive information.

Impact

Successful exploitation of this vulnerability could allow attackers to access sensitive site information, such as user credentials, or perform unauthorized actions, like modifying or deleting content. This could lead to a complete compromise of the Kirby CMS website and its data. The vulnerability specifically targets sites that leverage dynamic options for form fields, making them susceptible to malicious query injection. Sites running vulnerable versions of Kirby CMS are at risk of information disclosure and unauthorized modification.

Recommendation

Upgrade to Kirby CMS version 4.9.0 or 5.4.0 or later to patch the vulnerability as described in the advisory (https://github.com/advisories/GHSA-jcjw-58rv-c452).
Apply input validation and sanitization to all data sources used for dynamic options to prevent the injection of malicious templates and mitigate CVE-2026-34587.
Monitor web server logs for suspicious activity, such as requests containing template syntax or attempts to access sensitive information, to identify potential exploitation attempts.

BentoML SSTI via Unsandboxed Jinja2 in Dockerfile Generation

hello@craftedsignal.io — Fri, 03 Apr 2026 23:14:15 +0000

BentoML versions 1.4.37 and earlier contain a critical vulnerability related to server-side template injection (SSTI). The vulnerability stems from the use of an unsandboxed Jinja2 environment within the generate_containerfile() function, which is responsible for creating Dockerfiles. By crafting a malicious bento archive containing a specially crafted dockerfile_template, an attacker can inject arbitrary Python code that executes directly on the host machine when a victim imports and containerizes the bento using bentoml containerize. This vulnerability bypasses all container isolation mechanisms and gives the attacker full access to the host’s filesystem, environment variables, and potentially other sensitive information. The lack of input validation during the import process allows the malicious template to be embedded within the bento archive undetected until the containerization process.

Attack Chain

Attacker crafts a malicious bentofile.yaml file containing a dockerfile_template directive pointing to a Jinja2 template with an SSTI payload.
The attacker builds a bento using bentoml build, which copies the malicious template into the bento archive at env/docker/Dockerfile.template.
The attacker exports the bento as a .bento or .tar.gz archive and distributes it to victims.
A victim imports the malicious bento archive using bentoml import bento.tar. No validation of the template content is performed during the import.
The victim attempts to containerize the imported bento using bentoml containerize, triggering the construct_containerfile() function.
The construct_containerfile() function detects the presence of the Dockerfile.template and sets the dockerfile_template attribute in the Docker options.
The generate_containerfile() function loads the attacker-controlled template into an unsandboxed Jinja2 environment.
The template is rendered, resulting in arbitrary Python code execution on the victim’s host machine, outside of any containerized environment. This allows the attacker to achieve full host compromise.

Impact

Successful exploitation allows arbitrary code execution on the host machine of any user who imports and containerizes the malicious bento archive. This provides the attacker with: full access to the host filesystem, the ability to install backdoors or pivot to other systems, and access to sensitive information such as credentials and API keys stored in environment variables. Due to the placement of the malicious code within a bento archive, and the nature of the containerize operation, users may be unaware of the risk and impact of this vulnerability.

Recommendation

Apply the patched version of BentoML (later than 1.4.37) to remediate CVE-2026-35044.
Deploy the Sigma rule “Detect BentoML SSTI Payload in Dockerfile Template” to identify potentially malicious Jinja2 templates being written to disk.
Monitor process creation events for the execution of suspicious commands originating from the bentoml process, particularly after importing a bento archive, to catch potential exploitation attempts using the rule “Detect Suspicious Process Execution from BentoML”.
Implement strict input validation and sanitization for any user-provided templates or configuration files to prevent server-side template injection vulnerabilities, as described in the overview.
Review and restrict the extensions used within the Jinja2 environment to only those absolutely necessary for Dockerfile generation, following the recommended fix in the source.

Contact Form by Supsystic WordPress Plugin SSTI Vulnerability (CVE-2026-4257)

hello@craftedsignal.io — Mon, 30 Mar 2026 22:16:20 +0000

The Contact Form by Supsystic plugin, a popular WordPress plugin, is susceptible to a critical Server-Side Template Injection (SSTI) vulnerability, identified as CVE-2026-4257. This vulnerability affects all versions up to and including 1.7.36. The root cause lies in the plugin’s use of the Twig template engine (Twig_Loader_String) without proper sandboxing. This, combined with the cfsPreFill functionality, allows unauthenticated attackers to inject arbitrary Twig expressions into form…

Giskard-agents ChatWorkflow.chat() Server-Side Template Injection

hello@craftedsignal.io — Fri, 27 Mar 2026 22:17:30 +0000

The giskard-agents library, specifically versions 0.3.3 and earlier, along with versions 1.0.1a1 through 1.0.2a1, contains a critical vulnerability related to server-side template injection. The ChatWorkflow.chat() method within the library directly passes user-provided strings to a non-sandboxed Jinja2 Environment. This design flaw allows a malicious actor to inject arbitrary Jinja2 templates into the message, which, when rendered, can lead to remote code execution (RCE) on the server hosting the application. This vulnerability exists because the chat() method, intended for processing user input, inadvertently interprets the input as a Jinja2 template due to the usage of _inline_env.from_string(). Defenders should be aware of applications using the vulnerable chat() method which creates the attack surface.

Attack Chain

Attacker crafts a malicious string containing a Jinja2 payload designed for RCE.
The attacker inputs the malicious string into a user interface or API endpoint that utilizes the ChatWorkflow.chat() method.
The application passes the attacker-controlled string to the ChatWorkflow.chat() method.
ChatWorkflow.chat() creates a MessageTemplate object with the attacker’s string as the content_template.
The render() method of the MessageTemplate object calls _inline_env.from_string() on the attacker-controlled string, creating a Jinja2 template.
The template.render() method is invoked, executing the attacker’s Jinja2 payload due to the non-sandboxed Jinja2 Environment.
The attacker’s payload leverages Jinja2 class traversal to gain access to sensitive modules like os.
The attacker executes arbitrary system commands via os.popen() (or equivalent), achieving remote code execution.

Impact

Successful exploitation of this vulnerability allows an attacker to execute arbitrary system commands on the server hosting the affected application. This could lead to complete compromise of the server, including data theft, modification, or destruction. The severity of the impact is critical, potentially affecting any application that relies on giskard-agents for chatbot functionality and exposes the ChatWorkflow.chat() method to user input. Affected versions include giskard-agents <=0.3.3 and 1.0.x alpha. Patched versions are giskard-agents 0.3.4 (stable) and 1.0.2b1 (pre-release).

Recommendation

Upgrade giskard-agents to version 0.3.4 or 1.0.2b1, which includes the fix mitigating the vulnerability described in this brief.
Deploy the Sigma rule Detect Giskard Agents SSTI Attempt via Jinja2 Class Traversal to detect exploitation attempts via webserver logs.
If upgrading is not immediately feasible, sanitize user inputs passed to the ChatWorkflow.chat() method to prevent Jinja2 template injection.

LiteLLM Server-Side Template Injection Vulnerability

hello@craftedsignal.io — Tue, 05 Nov 2024 12:00:00 +0000

A server-side template injection (SSTI) vulnerability has been identified in LiteLLM versions 1.80.5 up to, but not including, 1.83.7. This flaw resides within the /prompts/test endpoint, which processes user-supplied prompt templates. Due to insufficient input sanitization, a malicious actor with a valid proxy API key can inject arbitrary code into the template, leading to its execution within the LiteLLM Proxy process. This vulnerability was disclosed on April 24, 2026. Successful exploitation can compromise the proxy’s environment, potentially exposing sensitive credentials like provider API keys and database passwords, or allowing arbitrary command execution on the host system. Organizations using affected versions of LiteLLM are at risk. The vulnerability is addressed in version 1.83.7-stable by implementing a sandboxed template renderer.

Attack Chain

An attacker authenticates to the LiteLLM proxy server using a valid API key.
The attacker crafts a malicious prompt template containing SSTI payloads.
The attacker sends a POST request to the /prompts/test endpoint, including the crafted template in the request body.
The LiteLLM proxy server receives the request and processes the template without proper sanitization.
The SSTI payload executes arbitrary code within the LiteLLM proxy process.
The attacker gains access to environment variables containing sensitive information, such as API keys and database credentials.
The attacker uses the exposed credentials to gain unauthorized access to external services or data.
The attacker executes arbitrary commands on the host system, potentially leading to full system compromise.

Impact

Successful exploitation of this SSTI vulnerability allows attackers to execute arbitrary code within the LiteLLM Proxy process. This can lead to the exposure of sensitive information such as API keys and database credentials, potentially enabling unauthorized access to other systems and data. Furthermore, attackers can execute arbitrary commands on the host, leading to full system compromise. The impact is significant for organizations relying on LiteLLM for managing and routing AI model requests, as it could result in data breaches, service disruption, and reputational damage.

Recommendation

Upgrade LiteLLM to version 1.83.7-stable or later to patch the vulnerability, as this version implements a sandboxed template renderer (see Patches).
As a temporary workaround, block POST /prompts/test at your reverse proxy or API gateway to prevent exploitation attempts (see Workarounds).
Review and rotate API keys that should not have access to prompt management routes to limit the potential impact of compromised keys (see Workarounds).
Deploy the Sigma rule “Detect LiteLLM SSTI Attempts via /prompts/test” to your SIEM to identify potential exploitation attempts based on HTTP request patterns.

Thymeleaf Server-Side Template Injection Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A critical security vulnerability, CVE-2026-41901, has been identified in Thymeleaf, a Java template engine, affecting versions up to and including 3.1.4.RELEASE. This vulnerability allows for Server-Side Template Injection (SSTI) due to the improper neutralization of specific syntax patterns within sandboxed expression execution. Specifically, the library fails to properly sanitize certain constructs, allowing potentially dangerous expressions to be executed even within supposedly restricted contexts. This poses a significant risk if application developers pass unsanitized variables to the template engine and these variables are then utilized in sandboxed areas within the templates. Successful exploitation can lead to arbitrary code execution on the server. All users of affected versions are strongly advised to upgrade to version 3.1.5.RELEASE as soon as possible.

Attack Chain

An attacker identifies an application using a vulnerable version of Thymeleaf (<= 3.1.4.RELEASE).
The attacker locates a template within the application that uses Thymeleaf’s expression evaluation within a sandboxed context.
The attacker identifies an input field or parameter that passes data to the Thymeleaf template engine.
The attacker crafts a malicious payload containing a Thymeleaf expression designed to bypass the sandbox restrictions. This payload may utilize specific syntax patterns not properly neutralized by the vulnerable Thymeleaf version.
The attacker injects the crafted payload into the identified input field.
The application processes the attacker-controlled input via the Thymeleaf template engine.
Due to the vulnerability, the malicious Thymeleaf expression is executed despite the intended sandboxing.
The attacker achieves arbitrary code execution on the server, potentially gaining full control of the system.

Impact

Successful exploitation of CVE-2026-41901 can lead to complete system compromise. An attacker could potentially execute arbitrary code, install malware, steal sensitive data, or disrupt application services. The vulnerability affects any application using Thymeleaf versions up to 3.1.4.RELEASE, potentially impacting numerous organizations across various sectors. The lack of proper input sanitization is the root cause, which can be difficult to identify and mitigate without patching the underlying Thymeleaf library.

Recommendation

Immediately upgrade Thymeleaf to version 3.1.5.RELEASE or later to patch CVE-2026-41901.
If immediate patching is not feasible, review and sanitize all data passed to the Thymeleaf template engine to prevent the injection of malicious expressions. However, this workaround is not a complete solution and upgrading is strongly recommended.
Deploy the Sigma rule “Detect Suspicious Thymeleaf Template Injection Attempts” to identify potential exploitation attempts in web server logs, focusing on HTTP requests containing suspicious patterns related to Thymeleaf expressions.
Enable verbose logging on your web servers to capture detailed information about HTTP requests and responses, which can aid in identifying and investigating potential template injection attacks.

OpenMRS Stored Velocity SSTI to RCE via ConceptReferenceRange

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

OpenMRS is vulnerable to a critical security flaw stemming from the unsafe use of Apache Velocity templates. Specifically, the ConceptReferenceRangeUtility.evaluateCriteria() method processes database-stored criteria strings as Velocity templates without any sandbox restrictions. This allows for unrestricted Java reflection through template expressions. A user possessing the Manage Concepts privilege can inject a malicious Velocity template expression into a concept’s reference range criteria field. This payload will then execute automatically whenever a user or an API call validates an observation against the compromised concept. This issue impacts OpenMRS versions 2.7.0 through 2.7.8, and 2.8.0 through 2.8.5. Successful exploitation allows an attacker to escalate privileges from content management to arbitrary code execution as the Tomcat application server process, with the potential for exfiltration of protected health information (PHI). The vulnerability is identified as CVE-2026-41258.

Attack Chain

An attacker gains access to an OpenMRS account with the Manage Concepts privilege.
The attacker navigates to the concept dictionary management interface.
The attacker locates a commonly used concept, such as one for a standard clinical measurement.
The attacker modifies the concept and injects a malicious Velocity template expression into the concept’s reference range criteria field. The expression leverages Java reflection to execute arbitrary code.
The malicious template is saved and stored in the concept_reference_range database table.
A user or API call validates an observation against the affected concept, triggering the execution of the stored Velocity template.
The attacker achieves arbitrary code execution within the context of the Tomcat application server process.
The attacker can then perform actions such as installing a web shell for persistent access or exfiltrating patient data.

Impact

Successful exploitation of this vulnerability allows for persistent remote code execution on the OpenMRS server. The injected payload persists within the concept_reference_range database table (VARCHAR 65535). A single compromised concept, especially one used for common clinical measurements, can lead to the execution of the malicious payload on every subsequent observation validation across all users, API clients, and integrations. This affects all facilities using the compromised OpenMRS instance. The attacker can escalate privileges from content dictionary management to arbitrary code execution and potentially exfiltrate PHI data.

Recommendation

Upgrade OpenMRS to version 2.8.6 or 2.7.9 or later to patch CVE-2026-41258.
Restrict the Manage Concepts privilege to only authorized users, as mentioned in the advisory’s workarounds.
Deploy the provided Sigma rule detecting Velocity template injection attempts to your SIEM and tune for your environment.
Implement database monitoring to detect unauthorized modifications to the concept_reference_range table to identify potential exploitation attempts.