CVE-2026-109200 in Community Edition
Summary
by MITRE • 10/12/2026
LogicalDOC Community Edition through 9.3 contains a server-side request forgery vulnerability in the default-enabled XMLConverter that fetches xml-stylesheet href URLs without scheme or host allowlisting. Authenticated users can upload XML documents whose stylesheet href points to internal http, ftp, file, or jar URLs, forcing server requests and applying attacker-controlled XSLT during conversion.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in LogicalDOC Community Edition versions through 9.3 represents a critical Server-Side Request Forgery (SSRF) flaw located within the default-enabled XMLConverter component. This security defect arises from an insufficient validation of input data, specifically regarding Uniform Resource Locators specified in xml-stylesheet href attributes within uploaded XML documents. The core technical failure lies in the absence of any allowlisting mechanism for schemes or hostnames when processing these external references. Consequently, the application does not restrict which protocols or network destinations it is permitted to contact during the conversion process, leaving a significant attack vector open to exploitation by authenticated users who have upload privileges within the system.
From an operational perspective, this vulnerability allows attackers to force the server to initiate HTTP requests to arbitrary internal and external resources. By crafting malicious XML files that reference internal URLs using protocols such as http or ftp, adversaries can probe internal network infrastructure, potentially discovering sensitive services, exfiltrating data from internal databases, or interacting with backend APIs that are not exposed to the public internet. Furthermore, the vulnerability extends beyond simple SSRF by enabling arbitrary XSLT execution. When the server processes these malicious documents, it applies attacker-controlled Extensible Stylesheet Language Transformations during the conversion process. This capability transforms a standard request forgery issue into a more severe remote code execution or data leakage scenario, as the XSLT processor can invoke system functions and access local file systems depending on the specific configuration of the underlying XML processing library.
The impact of this vulnerability is multifaceted, affecting both confidentiality and integrity within the LogicalDOC environment. Attackers can leverage SSRF to map internal network topologies, bypass firewalls that restrict external traffic but allow outbound connections from application servers, and access sensitive information stored in local files or jar archives by referencing file:// or jar:// URLs. The ability to execute arbitrary XSLT code means that an attacker could potentially extract credentials, modify document content before storage, or cause denial of service conditions through resource exhaustion during complex transformations. This is particularly dangerous because the vulnerability persists as long as users with upload permissions are present in the system, making it a persistent threat vector for any organization relying on this version of LogicalDOC Community Edition without additional security controls.
To mitigate this risk, immediate remediation actions should focus on disabling or restricting access to the XMLConverter functionality if it is not strictly required for business operations. If the feature must remain enabled, administrators should implement strict allowlisting at the application level to restrict allowed schemes and hostnames in xml-stylesheet href attributes. This involves configuring the underlying XML processing library to reject any references that do not match a predefined list of trusted domains or internal IP ranges designated as safe. Additionally, deploying network-level controls such as egress filtering can provide an additional layer of defense by blocking outbound connections from the application server to unauthorized destinations. It is also advisable to apply vendor-provided patches if available for versions later than 9.3, which likely address these input validation gaps.
This vulnerability aligns with Common Weakness Enumeration (CWE) identifiers such as CWE-918 Server-Side Request Forgery and CWE-20 Improper Input Validation. In the context of the MITRE ATT&CK framework, this exploit technique corresponds to T1557 Adversary-in-the-Middle or potentially T1046 Network Service Discovery if used for reconnaissance, as well as T1059 Command and Scripting Interpreter via XSLT execution. Organizations should treat this issue with high priority due to the combination of SSRF capabilities and arbitrary code execution potential inherent in the flawed XML processing logic. Regular security assessments focusing on file upload mechanisms and external resource fetching behaviors are recommended to identify similar vulnerabilities across other enterprise content management systems.