CVE-2022-23302: Apache Log4j JMSSink RCE Vulnerability

CVE-2022-23302 Overview

CVE-2022-23302 is an insecure deserialization vulnerability affecting the JMSSink component in all versions of Apache Log4j 1.x. When an attacker has write access to the Log4j configuration or if the configuration references an LDAP service under attacker control, they can manipulate the TopicConnectionFactoryBindingName configuration parameter to force JMSSink to perform malicious JNDI (Java Naming and Directory Interface) requests. This exploitation path can result in remote code execution, similar to the attack vector exploited in CVE-2021-4104.

Critical Impact
This vulnerability enables remote code execution through JNDI injection when attackers can modify Log4j configuration or control referenced LDAP services, potentially leading to complete system compromise of enterprise Java applications.

Affected Products

Apache Log4j 1.x (all versions)
NetApp SnapManager (Oracle and SAP editions)
Broadcom Brocade SANnav
QOS reload4j
Oracle WebLogic Server 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0
Oracle Business Intelligence 5.9.0.0.0, 12.2.1.3.0, 12.2.1.4.0
Oracle Enterprise Manager Base Platform 13.4.0.0, 13.5.0.0
Oracle Communications Unified Inventory Management 7.4.1, 7.4.2
Oracle MySQL Enterprise Monitor

Discovery Timeline

2022-01-18 - CVE-2022-23302 published to NVD
2025-07-07 - Last updated in NVD database

Technical Details for CVE-2022-23302

Vulnerability Analysis

This vulnerability is classified as CWE-502 (Deserialization of Untrusted Data) and affects the JMSSink appender component within Log4j 1.x. The JMSSink appender is designed to send log events to a JMS (Java Message Service) topic, requiring JNDI lookups to establish connections with JMS providers. The vulnerability arises because the appender accepts a TopicConnectionFactoryBindingName configuration value that can point to arbitrary JNDI resources.

When an attacker gains the ability to modify the Log4j configuration file or controls an LDAP server referenced in the configuration, they can specify a malicious JNDI URI. During the connection initialization process, JMSSink performs a JNDI lookup using the attacker-controlled binding name, which can resolve to a remote object containing malicious serialized Java classes. Upon deserialization, these classes execute arbitrary code within the context of the vulnerable application.

Apache Log4j 1.2 reached end of life in August 2015 and no longer receives security updates. This vulnerability specifically requires JMSSink to be explicitly configured, which is not the default configuration.

Root Cause

The root cause of this vulnerability lies in the unsafe handling of JNDI lookups within the JMSSink component. The TopicConnectionFactoryBindingName and TopicBindingName configuration parameters are used directly in JNDI InitialContext.lookup() calls without proper validation or restrictions on the types of resources that can be retrieved. This allows attackers to specify LDAP, RMI, or other JNDI protocol URIs that can load and instantiate arbitrary classes from remote servers, leading to deserialization-based code execution.

Attack Vector

The attack requires one of two prerequisites: write access to the Log4j configuration file, or control over an LDAP service that is already referenced in the existing configuration. Once either condition is met, the attacker can inject a malicious JNDI reference that points to a remote server hosting a serialized Java payload.

When the vulnerable application initializes the JMSSink appender with the malicious configuration, it performs a JNDI lookup to the attacker-controlled endpoint. The remote server responds with a serialized object containing malicious code. Java's JNDI implementation deserializes this object, instantiating the attacker's payload and executing arbitrary code with the same privileges as the application. This attack is network-accessible and does not require user interaction once the malicious configuration is in place.

The exploitation mechanism closely mirrors CVE-2021-4104 (JMSAppender vulnerability), leveraging the same fundamental weakness in JNDI lookup handling that enabled the widespread Log4Shell attacks against Log4j 2.x versions.

Detection Methods for CVE-2022-23302

Indicators of Compromise

Presence of JMSSink configuration entries in log4j.properties or log4j.xml files with suspicious TopicConnectionFactoryBindingName values
JNDI lookup attempts to external LDAP, RMI, or DNS servers from Java application processes
Network connections to unexpected external endpoints on ports commonly used by LDAP (389, 636) or RMI (1099)
Log4j configuration files modified recently or containing references to external LDAP servers

Detection Strategies

Scan application deployments for Log4j 1.x JAR files (e.g., log4j-1.*.jar) using software composition analysis tools
Search configuration files for JMSSink class references and review all JNDI binding name parameters
Monitor DNS queries for unusual patterns that may indicate JNDI injection attempts (e.g., DNS queries containing encoded data)
Implement network segmentation rules to detect and block outbound JNDI protocol connections from application servers

Monitoring Recommendations

Deploy network detection rules to identify LDAP and RMI traffic originating from Java application servers to non-standard destinations
Enable file integrity monitoring on Log4j configuration files to detect unauthorized modifications
Correlate Java process behavior with outbound network connections to identify anomalous JNDI lookup patterns
Review application logs for javax.naming.NamingException errors that may indicate failed exploitation attempts

How to Mitigate CVE-2022-23302

Immediate Actions Required

Upgrade from Log4j 1.x to Log4j 2.x (version 2.17.1 or later recommended), which addresses this and numerous other security issues
If immediate upgrade is not possible, remove the JMSSink class from the Log4j JAR file by deleting org/apache/log4j/net/JMSSink.class
Remove all JMSSink configurations from log4j.properties and log4j.xml files
Restrict write access to Log4j configuration files using file system permissions
Block outbound LDAP and RMI connections from application servers at the network level

Patch Information

Apache Log4j 1.x has been end-of-life since August 2015 and will not receive a security patch for this vulnerability. Organizations must migrate to Apache Log4j 2.x (version 2.17.1 or later) to receive ongoing security support. For those requiring a drop-in replacement maintaining API compatibility, the QOS reload4j project provides a fork with security fixes applied.

Affected Oracle products have patches available through the Oracle April 2022 Critical Patch Update and Oracle July 2022 Critical Patch Update. NetApp has released advisories with remediation guidance through their security advisory portal.

Workarounds

Remove the JMSSink.class file from the Log4j JAR to prevent the vulnerable code from being loaded
Configure Java security manager policies to restrict JNDI lookups to trusted, internal naming services only
Implement network-level controls to block outbound LDAP (ports 389, 636) and RMI (port 1099) traffic from application servers
Set the com.sun.jndi.ldap.object.trustURLCodebase system property to false to prevent loading remote classes via LDAP

bash

# Remove JMSSink class from Log4j JAR as a workaround
zip -q -d log4j-1.2.*.jar org/apache/log4j/net/JMSSink.class

# Verify the class has been removed
jar -tf log4j-1.2.*.jar | grep -i jmssink

# Set JVM property to disable remote class loading (add to application startup)
# -Dcom.sun.jndi.ldap.object.trustURLCodebase=false