Is Log4j 1.x vulnerable to Log4Shell?

No. CVE-2021-44228 (Log4Shell) only affects Log4j 2.x. Log4j 1.x does not have the JNDI lookup feature that Log4Shell exploits.

Can I still get security updates for Log4j 1.x from Apache?

No. Log4j 1.x reached end of life in August 2015 and receives no security fixes from Apache. You must either migrate to Log4j 2.x or use Reload4j.

Reload4j is a community fork of Log4j 1.2.17 that fixes all known 1.x vulnerabilities. It is a drop-in replacement, so no code changes are needed.

Is Log4j 1.x Vulnerable? CVE-2021-4104 and Other 1.x Flaws

Q: Does the JMSAppender vulnerability (CVE-2021-4104) affect all Log4j 1.x users?

No. CVE-2021-4104 only affects you if your application uses JMSAppender and an attacker can change its configuration. For most users, the risk is low, but it is still a known CVE.

Log4j 1.x is not affected by Log4Shell (CVE-2021-44228), which is specific to Log4j 2. However, teams running legacy Log4j 1.x often ask log4j 1.x vulnerable and the answer is yes, but for different reasons. Log4j 1.x reached end of life in August 2015 and receives no security fixes from Apache. It carries its own unpatched CVEs, including CVE-2021-4104, CVE-2019-17571, and others. Here are the risks and what to do about them.

Log4j 1.x and Log4Shell a Common Misconception

Because Log4j 2.x was widely exploited via Log4Shell, many assume Log4j 1.x is equally dangerous. It is not. The vulnerability in CVE-2021-44228 exists only in Log4j 2.x. Log4j 1.x does not have the JNDI lookup feature that Log4Shell exploits. However, that does not mean Log4j 1.x is safe. It has its own set of vulnerabilities that remain unpatched because the project is end of life.

CVE-2021-4104 and the JMSAppender Vulnerability

When CVE-2021-4104 Becomes Exploitable

The most well-known Log4j 1.x flaw is CVE-2021-4104. This vulnerability affects Log4j 1.2 only when the application is configured to use JMSAppender and an attacker can change its configuration. Exploitation requires two conditions: the JMSAppender must be active, and the attacker must be able to modify the JMS configuration (for example, via a separate injection flaw). If those conditions are met, the attacker can execute arbitrary code. For most deployments, this is not a practical risk, but it is still a known CVE that security scanners will flag.

Other Known Vulnerabilities in Log4j 1.x

Unpatched CVEs in Legacy Components

Beyond CVE-2021-4104, Log4j 1.x has several other unpatched CVEs:

CVE-2019-17571 is a deserialization flaw in Log4j 1.2's SocketServer class. If you use the SocketServer to receive log events over the network, an attacker can send crafted serialized data to execute code.
CVE-2022-23302 affects the JMSSink component, allowing arbitrary code execution via a malicious JMS server.
CVE-2022-23305 is an SQL injection vulnerability in the JDBCAppender. If an attacker can control log messages, they can inject SQL commands.
CVE-2022-23307 is a deserialization vulnerability in the Chainsaw log viewer component.

All of these remain unpatched in the official Log4j 1.x line because Apache no longer maintains it.

Why Log4j 1.x is Still in Use

Many organizations still run Log4j 1.x because of legacy applications that cannot easily upgrade to Log4j 2.x. Log4j 2.x requires Java 8 or later and has a different API, which can require code changes. Some teams also rely on the JMSAppender or other components that changed in Log4j 2. This creates a security gap that needs a practical solution.

Migration Options Log4j 2.x and Reload4j

Choose Your Upgrade Path

There are two recommended paths for teams still on Log4j 1.x:

Migrate to Log4j 2.17.1 or later (Java 8+). This is the official fix from Apache. It requires updating your code to use the Log4j 2 API, which may involve rewriting logger calls and configuration files. It is the most future-proof option.
Replace Log4j 1.x with Reload4j, a community fork of Log4j 1.2.17. Reload4j is a drop-in replacement that fixes all known 1.x vulnerabilities, including CVE-2021-4104, CVE-2019-17571, and the 2022 CVEs. No code changes are needed. It maintains the same API and configuration format.

For teams that cannot migrate to Log4j 2 immediately, Reload4j offers a way to close the security gaps without refactoring.

Using the Version Checker on This Site

If you are unsure which Log4j version your application uses, run the version checker to report Log4j version status. It identifies whether you are on a vulnerable 1.x release, a patched 2.x release, or using Reload4j. Run the checker against your application or its dependencies to get a clear picture.

Summary What to Do Now

Act Before Scanners Flag You

If you are on Log4j 1.x, you are not vulnerable to Log4Shell, but you are exposed to CVE-2021-4104, CVE-2019-17571, CVE-2022-23302, CVE-2022-23305, and CVE-2022-23307. Migrate to Log4j 2.17.1 or later. If that is not possible, switch to Reload4j as a drop-in replacement. Do not stay on unpatched Log4j 1.x.