Description

Document Merge Service is a document template merge service providing an API to manage templates and merge them with given data. Prior to version 9.1.0, a remote code execution (RCE) via server-side template injection (SSTI) allows for user supplied code to be executed in the server's context where it is executed as the document-merge-server user with the UID 901 thus giving an attacker considerable control over the container. The vulnerability is limited to XLSX templates, were the xltpl library uses a npn-sandboxed Jinja environment for the processing of the template. This issue has been patched in version 9.1.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-10-01T20:17:25.440Z",
  "pubdate": "2026-10-01T20:17:25.440Z",
  "executiveSummary": "A critical remote code execution (RCE) vulnerability exists in the Document Merge Service prior to version 9.1.0 due to server-side template injection (SSTI).\nThe vulnerability originates from the insecure utilization of the xltpl library, which processes XLSX templates within a non-sandboxed Jinja template engine environment.\nBy crafting malicious XLSX templates, an unauthenticated attacker can execute arbitrary code within the server's execution context.\nThe process runs with the privileges of the document-merge-server user (UID 901), granting the attacker significant control over the containerized environment.\nSuccessful exploitation results in full system compromise of the container, potentially allowing for lateral movement, data exfiltration, or further infrastructure compromise.\nImmediate remediation involves upgrading to version 9.1.0 or higher to ensure the implementation of necessary sandboxing and secure template rendering practices.",
  "technicalDetails": "The vulnerability is identified as a server-side template injection (SSTI) flaw residing in the template processing pipeline of the Document Merge Service.\nThe root cause is the reliance on the xltpl library for processing XLSX document templates, which fails to enforce strict sandboxing when executing Jinja2 template logic. Jinja2 templates are inherently powerful and capable of accessing underlying Python objects, methods, and global namespaces.\nIn this specific implementation, the application passes user-supplied or template-embedded logic to the Jinja engine without sufficient input validation or environment restriction.\nAn attacker can exploit this by uploading or submitting a specially crafted XLSX file containing malicious Jinja2 expressions. When the server processes this template, the Jinja engine evaluates the injected expressions, enabling the attacker to break out of the intended template context.\nThe attack flow proceeds as follows: First, the attacker identifies the document upload/merge API endpoint. Second, the attacker embeds malicious Jinja2 syntax (e.g., accessing 'os' or 'subprocess' modules via Python's object resolution chains) into the XLSX template structure. Third, the attacker initiates a merge operation. Finally, the server-side process interprets the malicious template, executing the attacker-supplied payload with the effective permissions of the document-merge-server user (UID 901).\nBecause the execution environment lacks an effective sandbox, the injected code is interpreted directly by the Python runtime on the server. This bypasses typical application-layer security controls. The impact is significant because the attacker effectively gains the ability to execute shell commands or script execution within the container.\nPost-exploitation activities can include environment enumeration, scanning internal networks, exfiltrating sensitive merge data, or establishing persistent backdoors within the containerized infrastructure. The lack of process isolation between the Jinja engine and the host environment is the primary driver for this high-severity security failure."
}