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

# 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