dbcve.org
JackrabbitApplication · Apache

CVE-2023-37895

CRITICAL · 9.8 CVSS v3.1 Published 2023-07-25
Fix available
A fix is available. Upgrade to 2.20.11 / 2.21.18 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Java object deserialization vulnerability in Apache Jackrabbit's RMI component allows remote code execution via malicious deserialized objects. The included commons-beanutils library contains exploitable classes that can be leveraged over RMI (both native TCP port 1099 and RMI-over-HTTP at /rmi endpoint).

MitigationUpdate immediately to version 2.20.11 (stable) or 2.21.18 (unstable), or alternatively disable RMI entirely by removing RemoteBindingServlet from web.xml and setting rmi.enabled=false in bootstrap.properties.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
JackrabbitApplication
Affected:>= 1.0.0, < 2.20.11>= 2.21.0, < 2.21.18

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify installed Apache Jackrabbit version
    Check the jackrabbit-core JAR file name or examine the manifest file within the jackrabbit-core jar for the Implementation-Version attribute. Alternatively, check your dependency management system (Maven pom.xml, Gradle build.gradle) for the jackrabbit-core version declared.
    Affected if The version is 1.0.0 or higher but below 2.20.11, OR 2.21.0 or higher but below 2.21.18.
  2. Verify if RMI service is listening on port 1099
    Run 'netstat -an | grep 1099' or 'ss -tlnp | grep 1099' on the server hosting Jackrabbit to check if TCP port 1099 is in LISTEN state.
    Affected if Port 1099 is open and listening for RMI connections.
  3. Check for RMI-over-HTTP endpoint exposure
    Inspect your web.xml deployment descriptor for a servlet mapping to '/rmi' or '/rmi/*' path. Also verify if the application responds to HTTP requests at the /rmi endpoint by sending a test request.
    Affected if The RemoteBindingServlet is mapped to /rmi endpoint and accessible via HTTP.
  4. Inspect bootstrap.properties for RMI configuration
    Locate the bootstrap.properties file in your Jackrabbit configuration directory (typically under ${rep.home} or the working directory). Search for the property 'rmi.enabled' and check its value.
    Affected if The property 'rmi.enabled' is set to 'true' or is absent (defaulting to enabled).
  5. Confirm RemoteBindingServlet is registered in web.xml
    Examine the WEB-INF/web.xml file of your Jackrabbit web application. Search for any servlet definition with 'RemoteBindingServlet' as the servlet class, or search for 'rmi' in servlet-mapping sections.
    Affected if The RemoteBindingServlet is registered and active in the web application configuration.

You are affected if your Jackrabbit version falls within the vulnerable ranges AND either RMI port 1099 is exposed or the /rmi HTTP endpoint is accessible, indicating RMI functionality is enabled.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 2.20.11 / 2.21.18 or later
Fixed in 2.20.112.21.18
Interim mitigation

Update immediately to version 2.20.11 (stable) or 2.21.18 (unstable), or alternatively disable RMI entirely by removing RemoteBindingServlet from web.xml and setting rmi.enabled=false in bootstrap.properties.

Recommended fix High confidence

2.20.11 (stable branch) or 2.21.18 (unstable branch)

  1. Upgrade to Jackrabbit 2.20.11 (if using stable branch 2.20.x) or 2.21.18 (if using unstable branch 2.21.x)
  2. After upgrading, verify the upgrade by checking that the version number matches the fixed release
  3. Optionally disable RMI as additional hardening: edit web.xml and remove the RemoteBindingServlet declaration and mapping for /rmi
  4. Optionally disable RMI: in bootstrap.properties (in $REPOSITORY_HOME), set rmi.enabled=false and remove rmi.host, rmi.port, and rmi.url-pattern entries
  5. Verify RMI is disabled by checking that localhost:8080/rmi returns 404
Caveat RMI support is deprecated; ensure no production dependencies on RMI functionality before upgrading

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Jackrabbit Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing2.0 h
  • Review / QA1.0 h
9.0 hours of engineering $1,600
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,560.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2023-37895 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2023-37895 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data