← Vulnerability feed

Vulnerability record · CVE-2023-37895 · published 25 July 2023

CVE-2023-37895: Apache jackrabbit deserialization of untrusted data vulnerability

Apache · Jackrabbit

Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including) 2.20.10 (stable branch) and 2.21.17 (unstable branch) use the component "commons-beanutils", which contains a class that can be used for remote code execution over RMI. Users are advised to immediately update to versions 2.20.11 or 2.21.18. Note that earlier stable branches (1.0.x .. 2.18.x) have been EOLd already and do not receive updates anymore. In general, RMI support can expose vulnerabilities by the mere presence of an exploitable class on the classpath. Even if Jackrabbit itself does not contain any code known to be exploitable anymore, adding other components to your server can expose the same type of problem. We therefore recommend to disable RMI access altogether (see further below), and will discuss deprecating RMI support in future Jackrabbit releases. How to check whether RMI support is enabledRMI support can be over an RMI-specific TCP port, and over an HTTP binding. Both are by default enabled in Jackrabbit webapp/standalone. The native RMI protocol by default uses port 1099. To check whether it is enabled, tools like "netstat" can be used to check. RMI-over-HTTP in Jackrabbit by default uses the path "/rmi". So when running standalone on port 8080, check whether an HTTP GET request on localhost:8080/rmi returns 404 (not enabled) or 200 (enabled). Note that the HTTP path may be different when the webapp is deployed in a container as non-root context, in which case the prefix is under the user's control. Turning off RMIFind web.xml (either in JAR/WAR file or in unpacked web application folder), and remove the declaration and the mapping definition for the RemoteBindingServlet:         <servlet>             <servlet-name>RMI</servlet-name>             <servlet-class>org.apache.jackrabbit.servlet.remote.RemoteBindingServlet</servlet-class>         </servlet>         <servlet-mapping>             <servlet-name>RMI</servlet-name>             <url-pattern>/rmi</url-pattern>         </servlet-mapping> Find the bootstrap.properties file (in $REPOSITORY_HOME), and set         rmi.enabled=false     and also remove         rmi.host         rmi.port         rmi.url-pattern  If there is no file named bootstrap.properties in $REPOSITORY_HOME, it is located somewhere in the classpath. In this case, place a copy in $REPOSITORY_HOME and modify it as explained.

9.8 CVSS 3.1 Critical EPSS 3.2% · top 12.2% CWE-502 · Deserialization of untrusted data
9.8CVSS 3.1 base score
3.2%EPSS exploitation probability, 30 days
NoNot in CISA KEV
1Affected product versions listed by NVD
8References
17 Jun 2026Last modified by NVD

Description

Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including) 2.20.10 (stable branch) and 2.21.17 (unstable branch) use the component "commons-beanutils", which contains a class that can be used for remote code execution over RMI. Users are advised to immediately update to versions 2.20.11 or 2.21.18. Note that earlier stable branches (1.0.x .. 2.18.x) have been EOLd already and do not receive updates anymore. In general, RMI support can expose vulnerabilities by the mere presence of an exploitable class on the classpath. Even if Jackrabbit itself does not contain any code known to be exploitable anymore, adding other components to your server can expose the same type of problem. We therefore recommend to disable RMI access altogether (see further below), and will discuss deprecating RMI support in future Jackrabbit releases. How to check whether RMI support is enabledRMI support can be over an RMI-specific TCP port, and over an HTTP binding. Both are by default enabled in Jackrabbit webapp/standalone. The native RMI protocol by default uses port 1099. To check whether it is enabled, tools like "netstat" can be used to check. RMI-over-HTTP in Jackrabbit by default uses the path "/rmi". So when running standalone on port 8080, check whether an HTTP GET request on localhost:8080/rmi returns 404 (not enabled) or 200 (enabled). Note that the HTTP path may be different when the webapp is deployed in a container as non-root context, in which case the prefix is under the user's control. Turning off RMIFind web.xml (either in JAR/WAR file or in unpacked web application folder), and remove the declaration and the mapping definition for the RemoteBindingServlet:         <servlet>             <servlet-name>RMI</servlet-name>             <servlet-class>org.apache.jackrabbit.servlet.remote.RemoteBindingServlet</servlet-class>         </servlet>         <servlet-mapping>             <servlet-name>RMI</servlet-name>             <url-pattern>/rmi</url-pattern>         </servlet-mapping> Find the bootstrap.properties file (in $REPOSITORY_HOME), and set         rmi.enabled=false     and also remove         rmi.host         rmi.port         rmi.url-pattern  If there is no file named bootstrap.properties in $REPOSITORY_HOME, it is located somewhere in the classpath. In this case, place a copy in $REPOSITORY_HOME and modify it as explained.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Affected products

1 vulnerable configurations from NVD's CPE data, grouped by vendor and product.

References

Track CVE-2023-37895 inside VULONE

Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.

Start free Open in platform

Related vulnerabilities

Same products first, then exploited flaws of the same weakness class.

8.8CVE-2025-53689Apache jackrabbit xml external entity (xxe) vulnerabilityBlind XXE Vulnerabilities in jackrabbit-spi-commons and jackrabbit-core in Apache Jackrabbit < 2.23.2 due to usage of an unsecured document build to …EPSS 0.49%8.8CVE-2016-6801Apache jackrabbit cross-site request forgery vulnerabilityCross-site request forgery (CSRF) vulnerability in the CSRF content-type check in Jackrabbit-Webdav in Apache Jackrabbit 2.4.x before 2.4.6, 2.6.x be…EPSS 2.3%6.5CVE-2025-58782Apache jackrabbit deserialization of untrusted data vulnerabilityDeserialization of Untrusted Data vulnerability in Apache Jackrabbit Core and Apache Jackrabbit JCR Commons. This issue affects Apache Jackrabbit Cor…EPSS 1.3%6.4CVE-2015-1833Apache Jackrabbit WebDAV XXE allows file read and SSRFApache Jackrabbit fails to properly restrict XML external entity processing in WebDAV requests, allowing crafted XML to resolve external entities. Th…EPSS 55%analysed4.3CVE-2009-0026Apache jackrabbit cross-site scripting vulnerabilityMultiple cross-site scripting (XSS) vulnerabilities in Apache Jackrabbit before 1.5.2 allow remote attackers to inject arbitrary web script or HTML v…EPSS 27%9.8CVE-2021-23758Ajax.NET Professional ajaxpro.2 untrusted deserialization RCEAll versions of the ajaxpro.2 package (Ajax.NET Professional) deserialize untrusted data and permit deserialization of arbitrary .NET classes. That l…KEVEPSS 83%analysed9.8CVE-2026-63077JetBrains TeamCity unauthenticated RCE via agent polling deserializationJetBrains TeamCity before 2026.1.3 and 2025.11.7 deserializes untrusted data received through the agent polling protocol, allowing unauthenticated re…KEVEPSS 9.8%analysed9.8CVE-2026-50522Microsoft SharePoint deserialization flaw allows remote code executionMicrosoft SharePoint Server deserializes untrusted data, letting an unauthorized attacker run code over the network. The flaw is remotely reachable w…KEVEPSS 3.0%analysed

Source: NIST National Vulnerability Database (record CVE-2023-37895), CISA KEV, FIRST EPSS (scores of 2026-09-26). This page is refreshed as NVD updates the record.