Log4j 1.2.17 is the final release of the Apache Log4j 1.x branch, which reached end of life in August 2015, and it ships with several unpatched remote code execution and deserialization vulnerabilities that will never be fixed — the only real remediation is to migrate off it. If you still have log4j-1.2.17.jar on a classpath somewhere, you are running software the maintainers abandoned more than a decade ago, and no configuration tweak makes that safe.
There is a persistent confusion between the 1.x and 2.x lines, made worse by the Log4Shell panic of December 2021. Let us separate them cleanly, because the right fix depends on which one you have.
Log4j 1.x is not affected by Log4Shell — and that is not good news
The famous Log4Shell vulnerability, CVE-2021-44228, affects Apache Log4j 2.0 through 2.14.1. It does not affect Log4j 1.x. Some teams took that to mean their old 1.2.17 deployments were fine. They were not. Log4j 1.x has its own catalog of serious flaws; it simply was not the one on the news. Being immune to Log4Shell while carrying your own unpatchable RCE bugs is the worst of both worlds.
The vulnerabilities in Log4j 1.2.17
Two flaws stand out because both can lead to remote code execution:
CVE-2019-17571 is a deserialization-of-untrusted-data flaw in the SocketServer class present in Log4j 1.2 up to and including 1.2.17. If an application uses that class to receive serialized log events over the network, an attacker can send a malicious serialized object that, combined with a suitable gadget on the classpath, executes code. This one carries a high severity rating because it needs no unusual configuration beyond using the vulnerable class.
CVE-2021-4104 is an RCE in the JMSAppender component of Log4j 1.2. When an application is configured to use JMSAppender, an attacker who can influence the TopicBindingName or TopicConnectionFactoryBindingName settings can make it perform JNDI lookups that fetch and run remote code — conceptually similar to Log4Shell. The important caveat is that this only bites when JMSAppender is explicitly configured, which is not the default. That narrower trigger is why it is treated as lower severity than Log4Shell, but "not default" is not "not exploited."
Additional 1.x advisories exist for other appenders (SMTP, JDBC, JMS sink handling) reported after the branch went end of life, and by the maintainers' own policy those will not be checked or fixed. The Apache Logging project is explicit: vulnerabilities reported against Log4j 1 after August 2015 are out of scope.
What "end of life" actually means here
End of life is not a suggestion to upgrade eventually. It means the code is frozen. No security team is triaging Log4j 1.x reports, no patched 1.x jar is coming, and any new gadget chain discovered against it stays open forever. This is the defining fact about log4j 1.2.17: the log4j 1.2.17 vulnerability set is a fixed, growing-only liability with no upstream fix path.
The fix is migration, not a patch
Because you cannot patch 1.x, remediation means moving to a supported logger. Two realistic paths:
- Migrate to Log4j 2.x at a current, safe version. After the Log4Shell scramble, the safe baseline landed at 2.17.1, which fixed CVE-2021-44832 (an RCE via a malicious JDBC Appender configuration that remained in 2.17.0). Version 2.17.1 was released in late December 2021, and the branch continued with maintenance releases such as 2.17.2 afterward. If you are already on 2.x, confirm you are at or above 2.17.1 — the "log4j 2.17.1 vulnerability" question usually resolves to "2.17.1 is the fixed line, not the vulnerable one," whereas anything at 2.17.0 or below still carries an open issue.
- Migrate to a maintained alternative such as Logback via SLF4J, or Log4j 2's API with a supported backend.
For a straight 1.x-to-2.x move, the log4j-1.2-api bridge lets you keep the old org.apache.log4j calls while running the 2.x engine underneath, which reduces code churn during migration. It is a stepping stone, not a destination — plan to move configuration to the 2.x model.
Finding every copy first
You cannot migrate what you cannot see, and Log4j is almost always transitive — pulled in by a framework or an old library, not declared directly. Search the resolved dependency tree, not just your top-level manifest:
# Maven: show every path that pulls in log4j 1.x
mvn dependency:tree -Dincludes=log4j:log4j
# Gradle
./gradlew dependencies | grep log4j
# Scan a built artifact or container filesystem for the jar
find / -name 'log4j-1.2*.jar' 2>/dev/null
At scale, a manifest search misses shaded and repackaged copies. An SCA scan that reads the actual bytecode and SBOM of your artifacts will catch a log4j-1.2.17 jar that a framework bundled and renamed, and a tool such as Safeguard can flag it transitively across every service at once. If you are working through the broader Java logging exposure, our guide on Jackson databind security covers the related deserialization class of bugs that often sits alongside old Log4j.
FAQ
Is Log4j 1.2.17 vulnerable to Log4Shell (CVE-2021-44228)?
No. CVE-2021-44228 affects Log4j 2.0 through 2.14.1, not the 1.x branch. However, Log4j 1.2.17 has its own remote code execution flaws, including CVE-2019-17571 and CVE-2021-4104, so it is not safe.
Can I patch Log4j 1.2.17?
No. Log4j 1.x reached end of life in August 2015, and no security fixes are issued for it. The only remediation is to migrate to Log4j 2.17.1 or later, or to another maintained logging framework.
What is the difference between the 2.17.1 and 2.17.2 releases?
2.17.1 is the version that fixed CVE-2021-44832, released in late December 2021, and is the safe baseline for the 2.x line. 2.17.2 is a later maintenance release on that branch. Both are far safer than any 1.x version.
How do I find Log4j 1.2.17 in my projects?
Walk the resolved dependency tree with mvn dependency:tree or ./gradlew dependencies, scan built artifacts for log4j-1.2*.jar, and run an SCA scan to catch shaded or transitively bundled copies your manifests do not list.