Summary
LogicalDOC Community Edition contains a code injection vulnerability in Velocity template processing for email subject and message fields. An authenticated user may abuse template evaluation to invoke command-execution functionality, causing operating-system commands to run with the privileges of the LogicalDOC process.
LogicalDOC Community Edition contains a code injection vulnerability in Velocity template processing for email subject and message fields. An authenticated user may abuse template evaluation to invoke command-execution functionality, causing operating-system commands to run with the privileges of the LogicalDOC process.
Affected context
The issue occurs in LogicalDOC deployments where authenticated users can submit or influence values processed as Velocity templates by DocumentService.sendAsEmail. Risk is increased when template-accessible tools expose runtime or process-execution capabilities and denylist controls do not comprehensively restrict them.
The issue occurs in LogicalDOC deployments where authenticated users can submit or influence values processed as Velocity templates by DocumentService.sendAsEmail. Risk is increased when template-accessible tools expose runtime or process-execution capabilities and denylist controls do not comprehensively restrict them.
Exploit preconditions
- Attack surface: Email-sending functionality that evaluates user-influenced subject or message templates
- Required access: An authenticated LogicalDOC account permitted to invoke the affected document email operation
- Trigger point: Velocity template evaluation during email preparation or sending
- Why exploitation is possible: Template expressions can reach command-execution-related functionality that is not fully blocked by the configured runtime denylist
- Attack surface: Email-sending functionality that evaluates user-influenced subject or message templates
- Required access: An authenticated LogicalDOC account permitted to invoke the affected document email operation
- Trigger point: Velocity template evaluation during email preparation or sending
- Why exploitation is possible: Template expressions can reach command-execution-related functionality that is not fully blocked by the configured runtime denylist
Why this happens
The vulnerability results from treating user-influenced email content as executable Velocity template logic rather than as data. Template-accessible helpers such as runtime or class-related tools can expose capabilities beyond simple formatting, while denylist-based restrictions may omit alternate paths to those capabilities. This behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-controlled input is interpreted in an executable context.
The vulnerability results from treating user-influenced email content as executable Velocity template logic rather than as data. Template-accessible helpers such as runtime or class-related tools can expose capabilities beyond simple formatting, while denylist-based restrictions may omit alternate paths to those capabilities. This behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-controlled input is interpreted in an executable context.
Potential impact
- An attacker may execute operating-system commands with LogicalDOC process privileges
- The application and its accessible data may be compromised
- Confidential documents or configuration secrets could be exposed
- The host may be used for persistence, lateral movement, or additional attacks
- Data integrity may be affected through unauthorized changes or deletion
- An attacker may execute operating-system commands with LogicalDOC process privileges
- The application and its accessible data may be compromised
- Confidential documents or configuration secrets could be exposed
- The host may be used for persistence, lateral movement, or additional attacks
- Data integrity may be affected through unauthorized changes or deletion
General mitigation guidance
Mitigation generally focuses on separating email content from executable template logic and reducing the capabilities available during rendering.
Common defensive patterns include:
- Treating subject and message values as plain text or using a narrowly constrained, non-executable templating model
- Allowing only explicitly approved formatting operations and exposing no runtime, reflection, class-loading, or process-execution helpers
- Replacing denylist-only controls with an allowlist-based execution policy and strong sandbox boundaries where templating is required
- Validating and encoding user-controlled content according to the intended email format
- Running the application with least-privilege operating-system and service-account permissions
- Restricting access to email-sending features and monitoring changes to template-related configuration
Mitigation generally focuses on separating email content from executable template logic and reducing the capabilities available during rendering.
Common defensive patterns include:
- Treating subject and message values as plain text or using a narrowly constrained, non-executable templating model
- Allowing only explicitly approved formatting operations and exposing no runtime, reflection, class-loading, or process-execution helpers
- Replacing denylist-only controls with an allowlist-based execution policy and strong sandbox boundaries where templating is required
- Validating and encoding user-controlled content according to the intended email format
- Running the application with least-privilege operating-system and service-account permissions
- Restricting access to email-sending features and monitoring changes to template-related configuration
How teams detect issues like this
Detection approaches can include:
- Static analysis rules identifying evaluation of user-controlled values through Velocity or comparable executable template engines
- Code review checks for exposed runtime, reflection, class, process, or command-execution helpers
- Tests that verify untrusted email fields remain data and cannot resolve arbitrary methods or classes
- Policy enforcement that prohibits executable template processing in user-editable fields unless an explicit, constrained allowlist is present
- Runtime monitoring for unusual child processes, command interpreters, or filesystem and network activity originating from the LogicalDOC process
- Neutral automated security review tools that flag code-generation and template-injection patterns
Detection approaches can include:
- Static analysis rules identifying evaluation of user-controlled values through Velocity or comparable executable template engines
- Code review checks for exposed runtime, reflection, class, process, or command-execution helpers
- Tests that verify untrusted email fields remain data and cannot resolve arbitrary methods or classes
- Policy enforcement that prohibits executable template processing in user-editable fields unless an explicit, constrained allowlist is present
- Runtime monitoring for unusual child processes, command interpreters, or filesystem and network activity originating from the LogicalDOC process
- Neutral automated security review tools that flag code-generation and template-injection patterns
