CVE-2025-64087: 
Java vulnerability analysis and mitigation

CVE-2025-64087 is a Server-Side Template Injection (SSTI) vulnerability in the FreeMarker template engine component of opensagres XDocReport versions 1.0.0 through 2.1.0. It allows unauthenticated attackers to execute arbitrary code by injecting crafted FreeMarker template expressions into documents processed by the library. The CVE was received by MITRE on January 20, 2026, and published to NVD the same day. It carries a CVSS v3.1 base score of 9.8 (Critical), assessed by CISA-ADP (Red Hat CVE, GitHub PR #705).

The root cause is classified as CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine). The vulnerable component is FreemarkerTemplateEngine.java in the fr.opensagres.xdocreport.template.freemarker module, which loads and processes DOCX template content through the FreeMarker engine without any sandboxing, input validation, or restriction on dangerous built-in operators. Specifically, FreeMarker's ?new operator allows instantiation of arbitrary Java classes — including freemarker.template.utility.Execute — enabling attackers to invoke Runtime.getRuntime().exec() or equivalent. The attack vector is a maliciously crafted .docx file containing a payload such as ${"freemarker.template.utility.Execute"?new()("whoami")} embedded as a merge field; when the application calls report.process(context, out), FreeMarker parses and evaluates the expression, triggering remote code execution. A public PoC repository and detailed write-ups are available (GitHub PoC, GitHub PR #705).

Successful exploitation results in full remote code execution on the server hosting the vulnerable application, with confidentiality, integrity, and availability all rated HIGH. An attacker can read sensitive files, execute system commands, establish reverse shells, and potentially pivot to other internal systems. The real-world attack scenario involves applications that accept user-uploaded .docx files (e.g., HR or document management systems) and process them with XDocReport, meaning any user with file upload capability can achieve server compromise (GitHub PoC, Red Hat CVE).

1. Identify target: Locate applications that accept .docx file uploads and process them server-side using XDocReport with the FreeMarker engine (versions 1.0.0–2.1.0). Common targets include HR systems, document management platforms, and reporting tools.
2. Craft malicious DOCX: Create a .docx file and insert a FreeMarker SSTI payload as a merge field or text content within the document body. Example payload for command execution:

   ${"freemarker.template.utility.Execute"?new()("whoami")}

3. Upload the document: Submit the crafted .docx file through the application's file upload functionality.
4. Trigger processing: The application calls XDocReportRegistry.getRegistry().loadReport(input, TemplateEngineKind.Freemarker) followed by report.process(context, out), which causes FreeMarker to parse and evaluate the injected expression.
5. Achieve RCE: The ?new operator instantiates freemarker.template.utility.Execute, which calls Runtime.getRuntime().exec() with the attacker-supplied command. For a reverse shell on Windows, use a Base64-encoded PowerShell payload:

   ${"freemarker.template.utility.Execute"?new()("powershell -e <BASE64_PAYLOAD>")}

6. Establish persistence: With shell access, deploy a web shell, create a scheduled task, or exfiltrate credentials for further lateral movement (GitHub PoC, GitHub PR #705).

• File System: Uploaded .docx files containing FreeMarker expressions such as ?new(), freemarker.template.utility.Execute, java.lang.Runtime, or java.lang.ProcessBuilder in document XML content (word/document.xml inside the ZIP archive).
• Process: Unexpected child processes spawned by the Java application server process (e.g., cmd.exe, powershell.exe, bash, sh, calc.exe, whoami, curl, wget) with the application service account as the parent.
• Network: Outbound connections from the application server to unknown external IPs on non-standard ports (e.g., 9999) shortly after a document upload event; DNS lookups to attacker-controlled domains initiated by the Java process.
• Logs: Application logs showing exceptions or output from FreeMarker template evaluation containing system command results; Java stack traces referencing freemarker.template.utility.Execute or freemarker.core.Environment.process.
• File System: New files created in the application's working directory or temp folders by the Java process (e.g., web shells, scripts, or exfiltration staging files) following document processing events (GitHub PoC).

The fix was merged into the XDocReport master branch on November 15, 2025 (PR #705), and a patched release (version 2.1.1 or 2.2.0) is expected to include the backport. The fix adds Configuration.NEW_BUILTIN_CLASS_RESOLVER_KEY = "safer" to FreemarkerTemplateEngine.java, which blocks instantiation of dangerous classes via the ?new operator, and disables the ?api built-in. Organizations should upgrade to XDocReport version 2.1.1 or later as soon as it is available. As an interim workaround, applications should validate and sanitize all user-supplied document content before passing it to XDocReport, restrict file upload functionality to trusted users, and consider scanning uploaded .docx files for FreeMarker expressions prior to processing (GitHub PR #705, Red Hat CVE).

The Hacker Wire published a dedicated article on the vulnerability titled "opensagres XDocReport SSTI RCE" shortly after disclosure, and the CVE was discussed on Mastodon and Bluesky security feeds. The original maintainer (angelozerr) initially dismissed the PR as not relevant to XDocReport's use case, but was persuaded by the researcher's analogy to Log4Shell — that unsafe library defaults can become attack vectors when processing untrusted input — and ultimately merged the fix. The vulnerability was also picked up by PoC-tracking blogs such as tonyharris.io and aggregated by INCIBE-CERT in Spain (The Hacker Wire, GitHub PR #705).