XDocReport – Product & Risk Overview

XDocReport is a Java-based document generation library widely used to merge business data into .docx and .odt templates. It is commonly embedded in backend services, reporting engines, and document automation platforms where templates are uploaded and rendered dynamically.

Because XDocReport processes XML-based document formats and server-side templates, any weakness in parsing or rendering logic has a direct impact on server security. The vulnerabilities described below affect applications where user-controlled templates or documents are accepted and processed without strict isolation.

Summary of Identified Vulnerabilities

Two critical vulnerabilities were identified in XDocReport during 2025. Both issues can lead to remote code execution (RCE) when the library is used in common enterprise deployment patterns.

Vulnerability 1: CVE-2025-65482 – XML External Entity (XXE) Leading to RCE

Technical Description

During the parsing of .docx and .odt files, XML components inside the document container are processed. In affected versions of XDocReport, XML external entity resolution is not fully disabled in certain parsing paths.

As a result, when a crafted document containing a malicious DOCTYPE declaration is processed, external entities may be resolved. This behavior allows:

• Reading of arbitrary local files
• Server-side request forgery (SSRF)
• In specific processing flows, escalation to remote code execution

The escalation to RCE occurs when parsed XML data is later consumed by components that allow execution, file writing, or unsafe template evaluation.

Exploitation Scenario

1. A malicious .docx file is uploaded to an application using XDocReport.
2. The document contains an XML part with a crafted DOCTYPE and external entity.
3. The parser resolves the external entity.
4. The resolved content is processed further by the application.
5. Under vulnerable configurations, command execution or unsafe file operations are triggered.

This exploitation path is especially realistic in automated document pipelines where uploaded files are processed without manual review.

Vulnerability 2: CVE-2025-64087 – Server-Side Template Injection (SSTI) Leading to RCE

Technical Description

XDocReport supports multiple template engines (such as FreeMarker and Velocity). In affected implementations, template expressions provided by users are evaluated without sufficient sandboxing.

When attacker-controlled template content is rendered, the template engine may expose:

• Java reflection
• Runtime execution helpers
• Utility classes capable of spawning OS commands

This results in direct remote command execution under the privileges of the application process.

Exploitation Scenario

1. A user uploads or controls a document template.
2. The template includes malicious expressions.
3. The template is rendered by XDocReport.
4. The template engine evaluates the injected expression.
5. Arbitrary system commands are executed on the server.

This vulnerability is frequently exploited in environments where business users are allowed to customize templates.

Proof of Concept & Exploit Availability (Educational)

• Public proof-of-concept examples are available demonstrating both XXE-based file access and SSTI-based command execution.
• Payloads are short and reliable, making exploitation straightforward in vulnerable environments.
• These examples are commonly used in red team exercises and security testing labs.

Detection & Monitoring Guidance

Application-Level Indicators

• XML parser errors referencing DOCTYPE, ENTITY, or entity resolution
• Unexpected file content appearing in generated documents
• Template rendering errors involving expression evaluation
• Sudden crashes during document generation

System-Level Indicators

• Unexpected child processes spawned by the application
• Command execution logs tied to document rendering events
• Outbound DNS or HTTP traffic triggered immediately after template uploads

Log Sources to Monitor

Example Detection Logic

XXE Indicators

• Presence of <!DOCTYPE or <!ENTITY inside uploaded document contents
• XML parsing attempts accessing local file paths or external URLs

SSTI Indicators

• Template expressions using ${}, #set, or engine-specific syntax
• References to execution helpers or reflection-related classes

These indicators can be implemented as:

• WAF rules
• SIEM correlation rules
• Pre-upload validation checks

Mitigation & Hardening Recommendations

The following actions are recommended immediately:

1. Disable XML external entities
   All XML parsers used by the application should explicitly disallow DTDs and external entities.
2. Do not render untrusted templates
   User-supplied templates should never be rendered with full template engine capabilities.
3. Restrict template engine features
   Remove access to execution utilities, reflection, and runtime helpers.
4. Apply isolation controls
   Run document rendering services with minimal privileges and restricted filesystem/network access.
5. Implement upload validation
   Inspect uploaded documents for XML constructs and template syntax before processing.
6. Monitor actively
   Add alerting around document processing workflows and template rendering failures.

Official Patch / Upgrade Information

At the time of writing, a clearly labeled patched release addressing both vulnerabilities has not been published as a standalone security release.

Official project location for patches and upgrades:

➡️ https://github.com/opensagres/xdocreport

All upgrades, security fixes, and release notes are published through the official repository.
It is strongly recommended to:

• Track new releases from this repository
• Upgrade immediately once a fixed version is announced
• Review commit history for security-related changes if custom builds are used

Final Takeaway

These vulnerabilities represent real-world, exploitable attack paths commonly abused in document processing systems. Because document generation services are often exposed internally and externally, the attack surface is broader than it appears.

Until official patches are applied, strict input controls and runtime hardening are essential to prevent exploitation.