CVE-2021-4104

What it actually does

CVE-2021-4104 affects Apache Log4j 1.2 when an application is explicitly configured to use JMSAppender. If an attacker can modify the Log4j configuration, they can set malicious TopicBindingName and TopicConnectionFactoryBindingName values that cause the application to perform attacker-controlled JNDI lookups. Those lookups can lead to deserialization of untrusted data and remote code execution in the Java process running the affected application. The issue is not exploitable in default Log4j 1.2 configurations; it requires JMSAppender to be present and attacker write access to logging configuration.

Why it matters to the business

Successful exploitation can give an attacker control of an application server, allowing data theft, service disruption, credential access, lateral movement, and deployment of additional malware. The practical risk is highest for legacy Java applications still using end-of-life Log4j 1.2, especially where application configuration files are writable by lower-privileged users or deployment automation can be abused. Although this vulnerability is not listed in CISA KEV and is not known to be ransomware-associated from the provided data, its EPSS score is high, and affected software is widely embedded across enterprise Java products, making legacy dependency discovery and remediation important.

How an attack unfolds

An attacker first needs a path to modify the application’s Log4j 1.2 configuration, such as access to a writable configuration file, compromised deployment pipeline, exposed administrative interface, or lower-privileged local account with write permissions. The attacker then adds or changes a JMSAppender configuration so that TopicBindingName and TopicConnectionFactoryBindingName point to attacker-controlled JNDI resources, commonly using LDAP, RMI, IIOP, or another naming service. When the application starts, reloads logging configuration, or initializes the affected appender, Log4j performs the configured JNDI lookup. If the lookup returns malicious serialized content or references a malicious object factory, the Java runtime may deserialize or load attacker-controlled code, resulting in command execution in the context of the application process. From there, the attacker can establish persistence, access application secrets, move laterally, or disrupt services.

How to fix it

Migrate away from Apache Log4j 1.2, which has been end-of-life since 2015, to a currently supported Log4j 2 release or a vendor-supported patched logging component. Because no exact fixed versions were provided, follow the affected product vendor’s current security advisory and upgrade guidance for each distribution or bundled product. As an immediate mitigation, remove JMSAppender from all Log4j 1.2 configurations, delete or disable references to org.apache.log4j.net.JMSAppender, and ensure TopicBindingName and TopicConnectionFactoryBindingName are not present in active logging configuration. Remove unused log4j-1.2.x JARs from application classpaths where possible. Restrict write permissions on logging configuration files to trusted administrators and deployment identities only. Limit outbound network access from Java application servers to approved destinations, especially LDAP, RMI, IIOP, and unexpected JMS/JNDI services. Review vendor-specific products that bundle Log4j 1.2, including application servers, integration platforms, identity products, and Oracle or Red Hat middleware, and apply vendor patches rather than replacing bundled libraries manually unless the vendor explicitly supports that action.

How to confirm the fix worked

Confirm that no active Log4j configuration uses org.apache.log4j.net.JMSAppender and that TopicBindingName or TopicConnectionFactoryBindingName do not appear in production logging configuration. Inventory Java applications and packaged products for log4j-1.2.x.jar and determine whether the vulnerable JMSAppender class is present and reachable. Validate that upgraded products no longer include vulnerable Log4j 1.2 components or are remediated according to vendor guidance. Check filesystem permissions on log4j.properties, log4j.xml, and equivalent externalized configuration files to ensure only trusted administrative or deployment users can modify them. Restart or redeploy applications after remediation and review startup logs for absence of JMSAppender initialization and JNDI lookup errors. Use egress controls or network telemetry to verify that application hosts are not initiating unexpected LDAP, RMI, IIOP, or other JNDI-related outbound connections.

Typical attack path

1. Identify a Java application using Apache Log4j 1.2 with JMSAppender available or configured.
2. Gain write access to Log4j configuration through a compromised account, writable filesystem path, deployment process, or administrative function.
3. Modify log4j.properties or log4j.xml to define or alter a JMSAppender with attacker-controlled TopicBindingName and TopicConnectionFactoryBindingName values.
4. Host or control a malicious JNDI endpoint, such as LDAP, RMI, or IIOP, that returns data designed to trigger code execution or unsafe deserialization.
5. Trigger application startup, configuration reload, or logging initialization so the JMSAppender performs the JNDI lookup.
6. Execute code in the vulnerable Java process and use that access to collect secrets, deploy tooling, pivot, or disrupt the application.

How to detect it

To determine whether exploitation already occurred, review configuration management history, source control, deployment artifacts, endpoint telemetry, and filesystem timestamps for unauthorized changes to Log4j configuration files. Focus on additions of JMSAppender, TopicBindingName, TopicConnectionFactoryBindingName, or JNDI URLs in log4j.properties, log4j.xml, and packaged application configuration. Review application logs around configuration changes, restarts, deployments, or crashes for JNDI, JMS, LDAP, RMI, IIOP, NamingException, InitialContext, or JMSAppender errors. Analyze network logs, proxy logs, DNS logs, firewall records, and EDR network telemetry for outbound connections from Java application processes to unexpected LDAP, RMI, IIOP, CORBA, JMS, or unknown external hosts. On endpoints, look for Java child processes spawned by application servers, suspicious command execution, new web shells, unusual temporary files, persistence mechanisms, or credential access following suspicious logging configuration changes. If any malicious JMSAppender configuration is found, preserve the configuration file, application logs, process telemetry, and network captures where available, then investigate the Java process and host as potentially compromised.

• org.apache.log4j.net.JMSAppender
• TopicBindingName
• TopicConnectionFactoryBindingName
• log4j.appender.JMS
• log4j.appender.*=org.apache.log4j.net.JMSAppender
• log4j.appender.*.TopicBindingName
• log4j.appender.*.TopicConnectionFactoryBindingName
• log4j.properties
• log4j.xml
• log4j-1.2.jar
• log4j-1.2.17.jar
• javax.naming.InitialContext
• InitialContext.lookup
• javax.naming.NamingException
• javax.jms.TopicConnectionFactory
• ldap://
• rmi://
• iiop://
• corbaloc:
• JMSAppender
• java.lang.RuntimeException: Error while activating options for appender named
• javax.naming.CommunicationException
• javax.naming.ServiceUnavailableException

What your security team should do

• Prioritize discovery of Log4j 1.2 across Java applications and vendor products, with special focus on externally exposed, business-critical, and middleware systems.
• Search configurations for JMSAppender usage and remove or disable it immediately where found.
• Upgrade affected applications and vendor products to supported versions that no longer depend on vulnerable Log4j 1.2 components.
• Harden file permissions and deployment controls so logging configuration cannot be modified by application users, service accounts with unnecessary privileges, or untrusted automation.
• Implement or verify outbound network restrictions from application servers to block unexpected LDAP, RMI, IIOP, and unapproved JMS/JNDI destinations.
• Review recent changes to logging configuration files and deployment artifacts for unauthorized JMSAppender additions or suspicious JNDI endpoints.
• Monitor Java application logs and network telemetry for evidence of JNDI lookups to untrusted infrastructure.
• Treat any confirmed malicious JMSAppender configuration as a likely application-server compromise and perform incident response, credential rotation, and host-level forensic review.