CVE-2022-23302

What it actually does

CVE-2022-23302 is a remote code execution issue in Log4j 1.x JMSSink behavior caused by unsafe JNDI/JMS lookups and deserialization of untrusted data. It is exploitable only when Log4j 1.x or a compatible fork such as affected reload4j code is specifically configured to use JMSSink, which is not the default. An attacker who can modify Log4j configuration, or who controls an LDAP service already referenced by the configuration, can cause the Java process to perform attacker-controlled JNDI requests and load or deserialize malicious objects, resulting in code execution with the privileges of the affected application.

Why it matters to the business

Successful exploitation can allow an attacker to take control of an affected Java application, steal data accessible to that application, alter business transactions, deploy malware, or disrupt service availability. Although the vulnerable JMSSink configuration is uncommon and Log4j 1.x is end-of-life, the CVSS score is high and the EPSS probability is elevated, so organizations with legacy Java estates should treat confirmed JMSSink exposure as urgent. The issue is not currently listed in CISA KEV and is not identified as ransomware-associated in the provided data, but legacy Log4j components remain attractive because they are often embedded deep in applications and third-party packages.

How an attack unfolds

An attacker first identifies a Java application using Log4j 1.x or an affected compatible implementation with JMSSink enabled, or obtains write access to the logging configuration through a deployment pipeline, admin interface, compromised account, writable configuration path, or supply-chain modification. The attacker then changes or abuses JMSSink configuration values such as TopicConnectionFactoryBindingName, InitialContextFactory, or ProviderURL so that the application performs a JNDI lookup to an attacker-controlled LDAP, RMI, IIOP, or JMS-related endpoint. When the application starts, reloads logging configuration, or otherwise initializes JMSSink, the Java process contacts the attacker-controlled naming service. The malicious service returns a crafted object, reference, or serialized payload that triggers unsafe deserialization or class loading behavior. If the runtime is susceptible, the payload executes inside the application process, giving the attacker the same operating-system and application permissions as the compromised Java service. Post-exploitation commonly focuses on credential theft, lateral movement, persistence, data access, and deployment of additional tooling. No specific named threat actor is confirmed from the provided data.

How to fix it

The preferred remediation is to remove Log4j 1.x entirely and migrate to a supported Log4j 2 release, because Log4j 1.2 has been end-of-life since 2015 and contains multiple unresolved security risks. For reload4j users, upgrade to a version containing the fix identified by commit 527f5374efd3c534b8aae7c133898019182e9f99 or a vendor release that explicitly includes that commit. Remove JMSSink configuration wherever possible; if JMS logging is required, replace it with a supported and hardened logging mechanism that does not perform unsafe JNDI lookups. Search all application packages, container images, and build dependencies for embedded Log4j 1.x or affected reload4j artifacts, including shaded JARs. Restrict write access to logging configuration files and deployment artifacts. Block unnecessary outbound LDAP, RMI, IIOP, and other JNDI-related traffic from application servers. Treat network egress filtering and configuration hardening as compensating controls only, not substitutes for removing the vulnerable component.

How to confirm the fix worked

Confirm that no production or packaged application contains Log4j 1.x JMSSink classes or affected reload4j code. Use dependency tooling, SBOMs, source scans, container image scans, and direct JAR inspection to identify org/apache/log4j/net/JMSSink.class and Log4j 1.x artifacts. Verify that deployed configurations do not reference org.apache.log4j.net.JMSSink, TopicConnectionFactoryBindingName, ProviderURL, InitialContextFactory, or attacker-controlled LDAP/RMI/IIOP endpoints. Confirm that reload4j builds include commit 527f5374efd3c534b8aae7c133898019182e9f99 or a vendor release documented as fixed. Validate runtime controls by ensuring Java application hosts cannot initiate unnecessary outbound LDAP, RMI, or IIOP connections. After remediation, restart affected applications and verify that no JMSSink initialization or JNDI lookup attempts occur in application logs or network telemetry.

Typical attack path

1. Find or compromise an application using Log4j 1.x or affected reload4j code with JMSSink present.
2. Obtain the ability to write or influence Log4j configuration, or control an LDAP/JNDI endpoint already referenced by that configuration.
3. Insert or modify JMSSink settings such as TopicConnectionFactoryBindingName and ProviderURL to point to attacker-controlled infrastructure.
4. Trigger application startup, logging reconfiguration, or JMSSink initialization.
5. Receive an outbound JNDI/JMS-related connection from the Java process.
6. Return a malicious object, reference, or serialized payload from the attacker-controlled naming service.
7. Achieve code execution in the Java application process.
8. Use the compromised process to access sensitive data, create persistence, move laterally, or disrupt operations.

How to detect it

To determine whether exploitation already occurred, review configuration history, file integrity monitoring, deployment logs, source-control commits, CI/CD audit trails, and administrator activity for unauthorized changes to Log4j properties, XML, YAML, or packaged configuration files. Search for JMSSink usage and suspicious JNDI settings, especially values pointing to external LDAP, RMI, IIOP, or unfamiliar JMS/naming-service hosts. Examine application, JVM, proxy, firewall, DNS, EDR, and NetFlow logs for outbound connections from Java processes to LDAP ports 389/636, RMI ports such as 1099 or dynamically assigned high ports, IIOP/CORBA ports, or unusual external hosts at the time of application startup or logging reconfiguration. Review process telemetry for Java spawning shells, script interpreters, download utilities, or reconnaissance commands. Inspect application servers for newly written class files, JARs, web shells, cron jobs, startup scripts, unauthorized SSH keys, and unexpected scheduled tasks. In Java logs, look for JNDI, InitialContext, LDAP, RMI, JMS, NamingException, ClassNotFoundException, or deserialization errors occurring near suspicious configuration changes. If an LDAP endpoint referenced by the application is internal, review that service for unexpected bind/search requests and malicious serialized responses. Correlate suspected exploitation with credential access, lateral movement, new accounts, data staging, or unusual outbound data transfer.

• org.apache.log4j.net.JMSSink
• TopicConnectionFactoryBindingName
• TopicBindingName
• InitialContextFactory
• ProviderURL
• java.naming.provider.url
• java.naming.factory.initial
• com.sun.jndi.ldap.LdapCtxFactory
• com.sun.jndi.rmi.registry.RegistryContextFactory
• ldap://
• ldaps://
• rmi://
• iiop://
• org/apache/log4j/net/JMSSink.class
• log4j.appender.JMS
• log4j.appender.jms
• log4j.appender.*=org.apache.log4j.net.JMSSink
• javax.naming.InitialContext
• javax.naming.NamingException
• java.io.InvalidClassException
• java.io.ObjectInputStream
• /tmp/*.class
• /tmp/*.jar
• /var/tmp/*.class
• /var/tmp/*.jar
• java.lang.Runtime.getRuntime
• java.lang.ProcessBuilder
• /bin/sh -c
• cmd.exe /c
• curl
• wget
• powershell -enc
• nc -e
• bash -i

What your security team should do

• Prioritize an inventory of legacy Log4j 1.x and reload4j usage across source repositories, dependency manifests, container images, vendor packages, and runtime file systems.
• Immediately remediate any application that combines Log4j 1.x or affected reload4j code with JMSSink configuration.
• Migrate Log4j 1.x applications to supported Log4j 2 versions; for reload4j, require a build containing commit 527f5374efd3c534b8aae7c133898019182e9f99 or a vendor-confirmed fixed release.
• Remove JMSSink and other legacy network/JNDI-based logging components unless there is a documented business requirement and a secure replacement design.
• Restrict write permissions on Log4j configuration files and monitor configuration changes through file integrity monitoring or deployment audit logs.
• Block unnecessary outbound LDAP, RMI, IIOP, and unusual JMS/naming-service traffic from Java application servers.
• Hunt for historical outbound naming-service connections from Java processes, especially around application restarts or configuration changes.
• Review build and deployment pipelines for unauthorized changes to logging configuration or dependency versions.
• Because EPSS is elevated despite no KEV listing, treat verified exposure as high priority rather than relying on KEV status alone.