CVE-2025-64087
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-20

Last updated on: 2026-02-03

Assigner: MITRE

Description
A Server-Side Template Injection (SSTI) vulnerability in the FreeMarker component of opensagres XDocReport v1.0.0 to v2.1.0 allows attackers to execute arbitrary code via injecting crafted template expressions.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-20
Last Modified
2026-02-03
Generated
2026-05-07
AI Q&A
2026-01-20
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
opensagres xdocreport From 1.0.0 (inc) to 2.1.0 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-1336 The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2025-64087 is a critical Server-Side Template Injection (SSTI) vulnerability in the FreeMarker template engine integration within the OpenSAGRES XDocReport library (versions 1.0.0 to 2.1.0). It occurs because the system processes uploaded DOCX templates containing FreeMarker expressions without validating or sanitizing them. Attackers can upload malicious DOCX files embedding crafted FreeMarker expressions that get executed on the server during template rendering. This allows arbitrary code execution remotely, such as running system commands or launching reverse shells. The root cause is the lack of input validation and sandboxing in the template processing pipeline, specifically in the FreemarkerTemplateEngine.java file, which directly processes template content without restrictions. [1, 3, 4]


How can this vulnerability impact me? :

Exploitation of this vulnerability can lead to severe impacts including remote arbitrary code execution on the server, full system compromise, unauthorized access, data theft, and manipulation of sensitive information. Attackers can execute system commands, retrieve sensitive data, establish reverse shells for persistent access, and potentially use the compromised system to launch phishing or malware distribution attacks. This poses a critical security risk to any organization using vulnerable versions of XDocReport for document generation with FreeMarker templates. [1, 3, 4]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for uploads of DOCX files containing suspicious FreeMarker template expressions such as `${"freemarker.template.utility.Execute"?new()("whoami")}`, `${"freemarker.template.utility.Execute"?new()("calc")}`, or other expressions using the `?new()` operator that execute system commands. Detection can involve scanning uploaded DOCX files for these patterns before processing. Since the DOCX format is a ZIP archive containing XML files, you can unzip the DOCX and search for these malicious expressions inside the template XML files. Example commands to detect such payloads include: 1. Unzip the DOCX file: `unzip suspicious.docx -d extracted_docx` 2. Search for suspicious FreeMarker expressions: `grep -r '\${.*\?new()' extracted_docx/` or `grep -r 'freemarker.template.utility.Execute' extracted_docx/` 3. Monitor server logs or application logs for unexpected execution of commands like `whoami`, `calc`, or other suspicious activities triggered by template processing. Additionally, network monitoring for unusual outbound connections (e.g., reverse shells) may help detect exploitation attempts. [1, 3, 4]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include: 1. Apply the official patch that adds input validation and sandboxing in the `FreemarkerTemplateEngine.java` file to block dangerous FreeMarker expressions such as those using the `?new()` operator and reflection-based calls. 2. Configure the FreeMarker template engine to use a safer class resolver by setting the `NEW_BUILTIN_CLASS_RESOLVER_KEY` configuration property to "safer", which blocks access to dangerous classes like `Runtime` and `ProcessBuilder`. 3. Disable API access in FreeMarker by calling `setAPIBuiltinEnabled(false)` to prevent runtime execution of arbitrary code. 4. Restrict template variable access to a whitelist of safe variables only. 5. Validate and sanitize all user-supplied DOCX templates before processing to detect and reject malicious templates. 6. If patching is not immediately possible, consider disabling or restricting the ability for users to upload DOCX templates or process FreeMarker templates until a fix is applied. These steps effectively sandbox the template engine and prevent execution of malicious expressions, mitigating the risk of remote code execution. [1, 2, 3, 4]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability allows attackers to execute arbitrary code on the server, potentially leading to full system compromise, data theft, unauthorized access, and manipulation of sensitive information. Such impacts can result in breaches of data confidentiality and integrity, which are critical requirements under common standards and regulations like GDPR and HIPAA. Therefore, exploitation of this vulnerability could lead to non-compliance with these regulations due to unauthorized disclosure or alteration of protected data. However, specific compliance impacts are not explicitly detailed in the provided resources. [1, 3, 4]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart