cbcvebase.
CVE-2023-37895
published 2023-07-25

CVE-2023-37895: Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including)…

PriorityP265critical9.8CVSS 3.1
AVNACLPRNUINSUCHIHAH
EPSS
2.66%
83.8th percentile
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: RMI org.apache.jackrabbit.servlet.remote.RemoteBindingServlet RMI /rmi Find the bootstrap.properties file (in $REPOSITORY_HOME), and set rmi.enabled=false and also remove rmi.host rmi.port rmi.url-pattern I

Affected

9 ranges
VendorProductVersion rangeFixed in
apachejackrabbit>= 0 < 2.20.11-12.20.11-1
apachejackrabbit>= 0 < 2.20.11-12.20.11-1
apachejackrabbit>= 1.0.0 < 2.20.112.20.11
apachejackrabbit>= 2.21.0 < 2.21.182.21.18
apache_software_foundationapache_jackrabbit_standalone>= 1.0.0 < 2.20.112.20.11
apache_software_foundationapache_jackrabbit_standalone>= 2.21.0 < 2.21.182.21.18
apache_software_foundationapache_jackrabbit_webapp>= 1.0.0 < 2.20.112.20.11
apache_software_foundationapache_jackrabbit_webapp>= 2.21.0 < 2.21.182.21.18
debianjackrabbit< jackrabbit 2.20.11-1 (forky)jackrabbit 2.20.11-1 (forky)

Detection & IOCsextracted from sources · hover to see the quote

port1099
path/rmi
processorg.apache.jackrabbit.servlet.remote.RemoteBindingServlet
  • Check for open TCP port 1099 on Jackrabbit hosts — this indicates native RMI is enabled and the host may be exploitable via Java deserialization through commons-beanutils.
  • HTTP GET requests to the /rmi path returning HTTP 200 indicate RMI-over-HTTP is active on the Jackrabbit instance, exposing the deserialization attack surface.
  • Presence of RemoteBindingServlet declaration in web.xml confirms RMI endpoint is deployed; audit web.xml in JAR/WAR files or unpacked webapp directories for this servlet mapping.
  • The vulnerability is triggered via Java object deserialization over RMI using the commons-beanutils component; monitor for unexpected RMI traffic or deserialization payloads targeting port 1099.
  • Check bootstrap.properties in $REPOSITORY_HOME for rmi.enabled=true (or absence of rmi.enabled=false) to identify misconfigured/vulnerable Jackrabbit deployments.
  • ·Both RMI-over-TCP (port 1099) and RMI-over-HTTP (/rmi path) are enabled by default in Jackrabbit webapp/standalone, meaning all default deployments are exposed without explicit hardening.
  • ·Even after patching Jackrabbit itself, adding any other component with an exploitable class to the classpath can re-expose the same RMI deserialization attack vector.
  • ·The /rmi HTTP path may differ when the webapp is deployed as a non-root context in a container, making automated scanning for this path less reliable.
  • ·Stable branches 1.0.x through 2.18.x are EOL and will not receive patches; deployments on these branches remain permanently vulnerable.

CVSS provenance

nvdv3.19.8CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
osv9.8CRITICAL
vendor_debian9.8LOW
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.