CVE-2021-44832

What it actually does

This vulnerability affects Apache Log4j2 versions 2.0-beta7 through 2.17.0, except the already-fixed 2.3.2 and 2.12.4 lines, when Log4j2 is configured with a JDBC Appender that uses a JNDI LDAP data source URI. If an attacker can influence the Log4j2 configuration or otherwise cause the JDBC Appender to resolve an attacker-controlled LDAP server, Log4j2 can perform unsafe JNDI resolution that may result in remote code execution in the context of the Java process. The practical exploitability is narrower than earlier Log4j issues because it requires high privileges or configuration control and a specific JDBC Appender/JNDI LDAP setup, but successful exploitation can fully compromise confidentiality, integrity, and availability of the affected application.

Why it matters to the business

A successful attack can allow an intruder to take over an affected application server, access sensitive data processed by that service, alter application behavior, deploy malware, or disrupt operations. Although this issue is not listed in CISA KEV and has high attack complexity due to the configuration-control requirement, the EPSS score is very high, and Log4j2 is widely embedded across Java applications and vendor products, making stale vulnerable versions an important supply-chain and asset-management risk long after publication.

How an attack unfolds

An attacker first identifies an application using a vulnerable Log4j2 version and determines whether it uses, or can be made to use, a JDBC Appender configured with a JNDI LDAP data source. The attacker then obtains the necessary level of control over logging configuration, application configuration, deployment descriptors, administrative settings, CI/CD artifacts, or another privileged configuration path. They modify or influence the JDBC Appender data source so that the JNDI name points to an LDAP URI under their control. When the application initializes or uses the affected appender, Log4j2 attempts to resolve the LDAP JNDI data source. The attacker-controlled LDAP server responds with a reference or serialized object chain intended to cause malicious code loading or execution, depending on runtime controls and JVM behavior. If execution succeeds, the attacker gains code execution as the application user and can establish persistence, dump secrets, pivot to internal services, or disrupt the service.

How to fix it

Upgrade Apache Log4j2 to a fixed version appropriate for the supported release line: 2.17.1 or later for the main line, 2.12.4 or later for the Java 7 maintenance line, or 2.3.2 for the legacy Java 6 line. For source-based consumers, the Apache logging-log4j2 repository includes the fix at commit e67bf55e72a54e564ebc822964589f252611ed1a. The provided input also lists python/cpython commit 49b5230a6c058e56d0f57c844327f0ca77352767, but this vulnerability is specifically a Log4j2 issue; prioritize Log4j2 package and embedded dependency remediation. Where immediate upgrade is not possible, remove or disable JDBC Appenders that use JNDI, replace LDAP-based JNDI data sources with safe local/java protocol names, restrict write access to Log4j2 configuration files, prevent untrusted administrative configuration changes, and block outbound LDAP/RMI/CORBA traffic from application servers except where explicitly required. Validate shaded, bundled, and vendor-supplied copies of log4j-core, not only direct package manager dependencies.

How to confirm the fix worked

Confirm that no deployed application contains log4j-core versions 2.0-beta7 through 2.17.0 unless it is exactly 2.3.2 or 2.12.4. Inspect application archives, container images, dependency lockfiles, SBOMs, vendor packages, and shaded JARs for log4j-core. Review Log4j2 configuration files, including XML, JSON, YAML, and properties formats, for JDBC Appenders and JNDI LDAP data source references. The fix is validated when applications run with Log4j2 2.17.1, 2.12.4, 2.3.2, or newer supported fixed versions, and configuration no longer contains LDAP-based JNDI data source names for JDBC Appenders. Where network controls are used as compensating controls, verify that application servers cannot initiate outbound LDAP, LDAPS, RMI, or other JNDI-related traffic to untrusted destinations.

Typical attack path

1. Identify Java applications or vendor products that include vulnerable Log4j2 versions from 2.0-beta7 through 2.17.0, excluding 2.3.2 and 2.12.4.
2. Determine whether Log4j2 configuration uses a JDBC Appender or whether privileged access can be used to add or modify one.
3. Gain control over a relevant configuration path, such as an admin console, deployment pipeline, writable configuration file, compromised administrator account, or application management interface.
4. Configure the JDBC Appender data source to use a JNDI LDAP URI pointing to attacker-controlled infrastructure.
5. Trigger application startup, reload, or logging activity that causes Log4j2 to initialize the JDBC Appender and resolve the JNDI data source.
6. Serve a malicious LDAP/JNDI response designed to cause code execution in the Java process.
7. Execute follow-on actions such as downloading payloads, harvesting secrets, creating persistence, moving laterally, or disrupting service.

How to detect it

To determine whether exploitation already occurred, review application logs, Log4j2 internal status logs, configuration change history, CI/CD deployment records, file integrity monitoring, EDR telemetry, proxy logs, firewall logs, DNS logs, and LDAP/LDAPS network telemetry. Focus on Java applications using Log4j2 with JDBC Appenders. Look for recent additions or modifications of JDBC Appender configuration, especially JNDI names beginning with ldap:// or ldaps://. Investigate outbound LDAP, LDAPS, RMI, or unusual HTTP callbacks from Java application servers to untrusted IPs or domains, particularly around application startup or configuration reload times. Examine Java process child processes, unexpected command execution, dropped files in temporary directories, new scheduled jobs, new service definitions, modified startup scripts, suspicious environment variable access, credential store access, and abnormal outbound connections. Because exploitation requires attacker control over the target LDAP server and typically privileged configuration access, also review admin logins, source-control commits, deployment pipeline activity, and configuration-management changes for unauthorized edits to logging configuration. Known exploitation should be treated as full application compromise due to potential remote code execution.

• JDBC Appender
• <JDBC
• JdbcAppender
• type="JDBC"
• appender.rolling.type = JDBC
• appender.jdbc.type = JDBC
• DataSource
• JndiObjectFactoryBean
• InitialContext
• java.naming.provider.url
• ldap://
• ldaps://
• rmi://
• corba://
• jndi:ldap
• jndi:ldaps
• javax.naming.InitialContext
• javax.naming.Context.PROVIDER_URL
• org.apache.logging.log4j.core.appender.db.jdbc.JdbcAppender
• org.apache.logging.log4j.core.net.JndiManager
• Error looking up JNDI resource
• JNDI lookup failed
• NameNotFoundException
• CommunicationException
• Cannot locate JDBC DataSource
• log4j2.xml
• log4j2.json
• log4j2.yaml
• log4j2.yml
• log4j2.properties
• log4j-core-2.0-beta7.jar
• log4j-core-2.0-rc1.jar
• log4j-core-2.0-rc2.jar
• log4j-core-2.0.jar
• log4j-core-2.1.jar
• log4j-core-2.2.jar
• log4j-core-2.3.jar
• log4j-core-2.4.jar
• log4j-core-2.5.jar
• log4j-core-2.6.jar
• log4j-core-2.7.jar
• log4j-core-2.8.jar
• log4j-core-2.9.jar
• log4j-core-2.10.jar
• log4j-core-2.11.jar
• log4j-core-2.12.jar
• log4j-core-2.13.jar
• log4j-core-2.14.jar
• log4j-core-2.15.jar
• log4j-core-2.16.jar
• log4j-core-2.17.0.jar

What your security team should do

• Prioritize inventory and remediation of internet-facing, externally managed, or high-privilege Java services that include vulnerable log4j-core versions, despite the lack of KEV listing.
• Upgrade Log4j2 to 2.17.1 or later, or to the fixed maintenance versions 2.12.4 or 2.3.2 where constrained by Java runtime compatibility.
• Search all Log4j2 configurations for JDBC Appenders using JNDI LDAP data sources and remove or replace them.
• Audit administrative access, CI/CD pipelines, configuration repositories, and deployment systems for unauthorized changes to Log4j2 configuration around the time of any suspicious activity.
• Implement egress filtering to prevent application servers from contacting arbitrary LDAP, LDAPS, RMI, DNS, and HTTP endpoints unless business-required.
• Use software composition analysis and container/image scanning to detect embedded or shaded vulnerable Log4j2 copies across internally developed and vendor-supplied software.
• Monitor for outbound LDAP connections from Java application servers and correlate them with Log4j2 startup, reload, or configuration changes.
• If suspicious JNDI LDAP activity is found, perform incident response for possible Java process compromise, including memory/process review, secret rotation, persistence checks, and lateral movement investigation.