Does CVE-2021-44832 affect Log4j 1.x?

No. The affected versions are Log4j 2.0-beta7 through 2.17.0. Log4j 1.x is a separate codebase and is not affected by this CVE.

Can I fix CVE-2021-44832 by modifying my configuration instead of upgrading?

Removing the JNDI data source from your JDBCAppender configuration can mitigate the vulnerability, but upgrading to 2.17.1 is the only complete fix. Configuration changes may break logging if your application relies on that data source.

Is CVE-2021-44832 exploitable remotely over the network?

Not directly. The attacker must first gain the ability to modify the logging configuration file. This typically requires local access or another vulnerability. Once the configuration is changed, the exploit can trigger remote code execution via LDAP.

What is the difference between CVE-2021-44832 and CVE-2021-45046?

CVE-2021-45046 is a bypass of the original Log4Shell fix that allowed remote code execution even in non-default configurations. CVE-2021-44832 is a separate flaw in the JDBCAppender that requires configuration control. Both are fixed in 2.17.1.

CVE-2021-44832: The Log4j JDBC Appender Flaw Fixed in 2.17.1

CVE-2021-44832 is the fourth Log4j CVE published in December 2021, and it is the reason version 2.17.1 (not 2.17.0) is the recommended target for upgrading. This vulnerability affects the JDBCAppender component when a JNDI LDAP data source URI is used and an attacker can modify the logging setup. Its CVSS base score is 6.6 (Medium), much lower than Log4Shell's 10.0, because exploitation requires control of the configuration. The fix is included in Log4j 2.17.1 for Java 8, as well as 2.12.4 for Java 7 and 2.3.2 for Java 6.

What is CVE-2021-44832

CVE-2021-44832 is a vulnerability in the Apache Log4j library that was published on 28 December 2021. It resides in the JDBCAppender, a component that writes log entries to a database. The flaw triggers when a JNDI LDAP data source URI is used in the logging setup and an attacker can modify that configuration. Under those conditions, the attacker can cause the JDBCAppender to load a malicious LDAP server, leading to arbitrary code execution or information disclosure.

The affected releases are Log4j 2.0-beta7 through 2.17.0. The Java 7 and Java 6 backport lines were fixed separately in releases 2.12.4 and 2.3.2 respectively. The fix in 2.17.1 limits JNDI data source names to the java protocol, preventing the use of the ldap protocol in this context.

Why Severity is Lower Than Log4Shell

The CVSS base score for CVE-2021-44832 is 6.6 (Medium), compared to CVE-2021-44228's 10.0 (Critical). The primary reason is the attack prerequisites. Log4Shell could be triggered remotely without authentication by sending a crafted string in any log message field. In contrast, CVE-2021-44832 requires that the attacker already has control over the logging configuration file. This control could come from write access to the file system, a separate vulnerability, or a misconfiguration that allows configuration injection.

Because the attacker must first modify the configuration, the vulnerability is less accessible and harder to exploit at scale. However, if an attacker does gain configuration control, the impact can still be severe, including remote code execution.

Why 2.17.1 is the Target Version

Skip 2.17.0 Entirely

Version 2.17.0 was released to address a denial of service vulnerability but did not fix the JDBCAppender flaw. CVE-2021-44832 remained exploitable in 2.17.0. The fix was released in 2.17.1, making it the earliest fully patched release for the Java 8 line.

If you are running Log4j 2.17.0, you are still vulnerable. Upgrade to 2.17.1 now. For Java 7 environments, the target is 2.12.4; for Java 6, 2.3.2.

How the Fix Works

The fix in Log4j 2.17.1 restricts the JNDI data source names that the JDBCAppender will accept. Specifically, it limits them to the java protocol (e.g., java:comp/env/myDataSource). The ldap protocol is no longer allowed in this context, which prevents an attacker from pointing the appender to a malicious LDAP server.

This is a narrow, targeted fix that does not affect other uses of JNDI in Log4j. It addresses the specific attack vector without breaking legitimate setups that rely on local JNDI lookups.

Defending Against CVE-2021-44832

Upgrade First

Upgrade to Log4j 2.17.1 (or 2.12.4 / 2.3.2). That is the primary defense.

Lock Down Configuration Files

Because the vulnerability requires control of the logging setup, protecting those files from modification is a relevant defense. Apply these practices:

Restrict write permissions on log4j configuration files to only the application user and administrators.
Use file integrity monitoring to detect unauthorized changes.
Validate any external input that influences logging configuration, especially JNDI URIs.
If you cannot upgrade immediately, disable the JDBCAppender or remove the JNDI data source from your configuration.

Checking Your Log4j Version

Use a Scanner

To determine if your application is affected, check the Log4j version in use. The site log4shell.tools provides a version checker that flags releases below 2.17.1.

Check Manually

You can also inspect your dependency files (pom.xml for Maven, build.gradle for Gradle, or the jar filename) to find the version string. If the version is between 2.0-beta7 and 2.17.0 inclusive, it is vulnerable to CVE-2021-44832. Any version below 2.0-beta7 is not affected by this specific CVE, but may be vulnerable to other Log4j flaws.