CVE-2026-91145 in Activiti
Summary
by MITRE • 09/15/2026
Activiti through 7.1.0.M6 fails to validate hash-brace deferred expressions in process variables, allowing attackers to bypass expression filtering. Attackers can inject expressions beginning with #{ that are stored and later evaluated in the full Spring context when a mail task uses variable-backed body fields, enabling method invocation on application beans.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Activiti versions up through 7.1.0.M6 represents a critical server-side request forgery and remote code execution risk rooted in improper input validation of process variables. Specifically, the engine fails to adequately sanitize or validate hash-brace deferred expressions within data passed as part of workflow processes. In standard Spring Expression Language (SpEL) usage, expressions enclosed in #{ } are intended for dynamic evaluation at runtime. However, when Activiti accepts these expressions without sufficient scrutiny during variable assignment, it creates a pathway for malicious actors to inject arbitrary SpEL payloads into the process context. This flaw is particularly dangerous because it allows attackers to bypass existing expression filtering mechanisms that might otherwise restrict certain types of input or function calls.
The technical mechanism of exploitation relies on the specific behavior of mail tasks within Activiti workflows. When a mail task utilizes variable-backed body fields, the engine retrieves these variables and evaluates them as SpEL expressions before sending the email. If an attacker can control the content of such a variable by injecting a payload starting with #{, this expression is stored in the process instance data. Later, when the workflow execution reaches the mail task step, Activiti processes the field using the full Spring application context rather than a restricted or sandboxed environment. This distinction is crucial because access to the full Spring context grants the injected expression significant power over the underlying Java runtime and available beans within that container.
The operational impact of this vulnerability is severe, as it enables method invocation on arbitrary application beans managed by the Spring framework. An attacker who successfully injects a crafted SpEL payload can leverage common bean methods to execute system commands, read sensitive files, or perform other actions with the privileges of the running Java process. This effectively results in remote code execution (RCE), allowing complete compromise of the affected server infrastructure. The ability to invoke arbitrary methods means that even if direct shell access is not immediately obvious, an attacker can manipulate database records, exfiltrate data, or pivot further into internal networks depending on what beans are exposed and accessible within the Spring context.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) as it involves injecting executable code via expression evaluation. Furthermore, from a tactical perspective, this exploitation technique maps to MITRE ATT&CK techniques related to Command and Scripting Interpreter execution through application layers, specifically leveraging legitimate system features for malicious purposes. The lack of validation on deferred expressions also touches upon CWE-20 Improper Input Validation, as the software fails to verify that user-controlled data conforms to expected safe patterns before processing it in a sensitive context like email generation.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Organizations running Activiti versions prior to 7.1.0.M6 should upgrade to the latest patched version where this validation logic has been corrected. For environments that cannot immediately patch, implementing strict input sanitization at the application layer is essential; developers should ensure that any data entering process variables undergoes rigorous checking to reject or escape hash-brace sequences unless explicitly required and safely handled by a restricted expression evaluator. Additionally, adopting least-privilege principles for the Spring context used in mail tasks can limit the blast radius if an injection occurs. Restricting which beans are accessible during variable evaluation significantly reduces the attack surface available to potential exploiters. Regular security audits of workflow definitions and continuous monitoring for anomalous process variable patterns can also help detect attempted injections before they lead to successful exploitation.