Apache Jackrabbit Webapp (jackrabbit-webapp): Deserialization of Untrusted Data

What to do

1. Update Apache Jackrabbit Webapp (jackrabbit-webapp) to 2.21.18 or 2.20.11, whichever matches your release line, or a later version.
2. Update Apache Jackrabbit Standalone (jackrabbit-standalone and jackrabbit-standalone-components) to 2.21.18 or 2.20.11, whichever matches your release line, or a later version.
3. Update jackrabbit to 2.20.11 or 2.21.18, whichever matches your release line, or a later version.
4. Read the advisory on lists.apache.org for workarounds and exact fixed builds.
5. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

NetworkCan be exploited remotely over a network, including the internet.

Attack complexity

LowNo special conditions are needed; the attack works reliably.

Privileges required

NoneNo account or login is needed.

User interaction

NoneNo action by a victim is required.

Scope

UnchangedImpact stays within the vulnerable component.

Confidentiality

HighAll data handled by the component can be read.

Integrity

HighData or code can be modified at will.

Availability

HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.

Official 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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Deserialization of Untrusted Data

Timeline

1. July 25, 2023CVE record published.
2. October 2, 2024CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
3. June 17, 2026Record last changed materially (score, affected products, status or references).

References

Recent Deserialization of Untrusted Data vulnerabilities

• 7.5 High severity

  Apache InLong: Deserialization of Untrusted Data

  CVE-2023-34434Jul 25, 2023ApacheEPSS 1.7%
• 7.5 High severity

  ABB Ability™ zenon: Deserialization of Untrusted Data

  CVE-2023-3324Jul 24, 2023ABB
• 9.8 Critical severity

  Adobe ColdFusion Deserialization of Untrusted Data Exploited

  CVE-2023-38203Jul 20, 2023AdobeEPSS 97.1%
• 8.8 High severity

  ShardingSphere-Agent: Deserialization of Untrusted Data

  CVE-2023-28754Jul 19, 2023ApacheEPSS 1.46%
• 9.8 Critical severity

  Apache EventMesh (incubating) RabbitMQ connector: Deserialization of Untrusted Data

  CVE-2023-26512Jul 17, 2023ApacheEPSS 1.36%
• 7.5 High severity

  C300: Deserialization of Untrusted Data

  CVE-2023-25770Jul 13, 2023Honeywell

Spotted an error? Tell us.