[ 
https://issues.apache.org/jira/browse/JCR-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated JCR-5260:
--------------------------------
    Labels: secuity  (was: )

> DavEx client runs Class.forName + (String)-constructor on server-controlled 
> error bodies (Uncaught non-RepositoryException types in HTTP responses break 
> JCR clients)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JCR-5260
>                 URL: https://issues.apache.org/jira/browse/JCR-5260
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr2dav
>    Affects Versions: 2.20.17, 2.22.4, 2.23.5
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>            Priority: Critical
>              Labels: secuity
>             Fix For: 2.20.18, 2.23.6, 2.22.5
>
>
> *_[https://www.cve.org/CVERecord?id=CVE-2026-92415]_*
> *_Use of Externally-Controlled Input to Select Classes or Code vulnerability 
> in Apache Jackrabbit's WebDAV/Davex client._*
> *_A malicious WebDAV/DavEx server, or an attacker able to intercept the 
> connection, can cause the client to instantiate arbitrary classes from its 
> classpath, which can lead to arbitrary file creation or truncation._*
> *_Only applications that use jackrabbit-spi2dav (directly or through 
> jackrabbit-jcr2dav) to connect to a remote repository are affected. 
> Jackrabbit servers are not affected._*
> *_Category: unsafe reflection on wire data (HIGH)._*
> The WebDAV remoting layer currently marshals arbitrary Java exceptions into 
> HTTP response payloads instead of restricting them strictly to 
> javax.jcr.RepositoryException and its subclasses.
> Why this breaks clients expecting javax.jcr.RepositoryException:
> Clients only have JCR and Jackrabbit client JARs on their classpath. If the 
> server serializes a server-only exception, client deserialization fails with 
> ClassNotFoundException, hiding the real cause.
> Client code expects to catch javax.jcr.RepositoryException. Unmapped runtime 
> exceptions bypass these catch blocks and cause unexpected application crashes.
> Serializing arbitrary exceptions exposes internal server stack traces and 
> dependency details over the wire.
> Client compatibility becomes tied to the server's internal classpath and 
> library dependencies.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to