Apache Jackrabbit EUVD-2026-94407

The affected application must use jackrabbit-spi2dav directly or through jackrabbit-jcr2dav to connect to a REMOTE repository over WebDAV/DavEx; standalone Jackrabbit servers and non-dav client configurations are NOT affected. The attacker must either control the remote DavEx/WebDAV server the client connects to, or be positioned to intercept/modify the client-server connection (e.g., absent or weak TLS enabling MITM). Limiting factors: this is client-side only, requires the victim to initiate a connection to a malicious or intercepted endpoint, and the demonstrated impact is bounded to instantiating classes already on the client classpath leading to file creation/truncation rather than confirmed arbitrary code execution.

CVSS 4.0 base score is 6.9 (medium), with a vendor vector of AV:N/AC:L/PR:N/UI:N and impact limited to VI:L (integrity-low) - no confidentiality (VC:N) and no availability (VA:N) impact. No EPSS score, CISA KEV listing, or POC/exploit code was provided, so exploitation status is 'no public exploit identified at time of analysis'; these signals are absent rather than negative, and absence is not proof of low interest. The decisive risk-limiting factor is NOT captured well by the vendor's AC:L choice: exploitation requires the victim application to connect, via jackrabbit-spi2dav/jcr2dav, to an attacker-controlled DavEx/WebDAV server OR for the attacker to man-in-the-middle an existing client connection - a precondition largely outside the attacker's sole control, which I assess as AC:H. This is a CLIENT-side flaw (Jackrabbit servers are explicitly not affected), so it is not an internet-facing server exploit and does not lend itself to opportunistic mass scanning. The 'RCE' input tag also conflicts with the vendor-stated impact (arbitrary file creation/truncation) and the CVSS (VI:L only, no VC/VA) - treat this as integrity-impact, not confirmed remote code execution, pending vendor clarification. Overall this is a real but conditional, integrity-only issue best handled in a normal patch cycle, with elevated priority only for applications that connect to remote/untrusted JCR repositories over untrusted networks.

A Java application uses jackrabbit-jcr2dav/spi2dav to connect to a remote JCR content repository. An attacker who operates a rogue DavEx/WebDAV endpoint the client connects to - or who intercepts an unencrypted or weakly-protected connection - returns a crafted response that names an arbitrary class, causing the client to instantiate it via reflection and create or truncate files on the client host. No public exploit was identified at time of analysis, and success depends on the client reaching a malicious or intercepted server (AC:H).