LogicalDOC Community Edition EUVD-2026-97445

Requires an authenticated low-privileged account on LogicalDOC Community Edition (version through 9.3) and the ability to upload an XML document. The vulnerable XMLConverter is enabled by default, so no non-default configuration is needed - the condition is simply that the default XML conversion path processes the uploaded document. Exploitation hinges on the converter fetching the xml-stylesheet href URL without scheme or host allowlisting, allowing http, ftp, file, and jar URLs. Limiting factors: authentication is mandatory (PR:L), no unauthenticated access is possible, and impact is partial read/forgery rather than full system compromise; there is no required user interaction beyond the attacker's own upload.

This is a medium-severity (CVSS 4.0 base 5.3) server-side request forgery issue, and the signals are consistent rather than conflicting. The CVSS vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation but requires authentication (PR:L), which materially limits the attacker population to users who already hold a valid LogicalDOC account - a meaningful barrier for a document management system that is typically behind authentication. No EPSS score, CISA KEV entry, or public proof-of-concept was provided in the input, so there is no evidence of active or widespread exploitation; this is a vendor/VulnCheck-disclosed issue rather than a confirmed in-the-wild threat. The impact is bounded (VC:L/VI:L, no availability impact), but the ability to reach file, ftp, and jar URL schemes elevates it beyond blind HTTP SSRF - an attacker can potentially read local files and apply attacker-controlled XSLT, making this a genuine but not emergency priority. Overall: a real, authenticated, low-privilege SSRF worth patching on a normal cycle, not a drop-everything issue, with the caveat that EPSS/POC data is absent and cannot confirm exploitation likelihood.

An attacker with a low-privileged authenticated account on a LogicalDOC Community Edition instance uploads a crafted XML document whose xml-stylesheet href points at an internal resource (e.g. a file:// path, an internal http:// service, or a jar: URL). When the default-enabled XMLConverter processes the document, the server fetches the attacker-specified URL and applies attacker-controlled XSLT, enabling internal network probing, local file disclosure, or interaction with internal-only services. No public exploit code was identified in the provided data, though the vulnerable source lines are referenced in the VulnCheck advisory and GitHub discussion.