log4j-1.2.13.jar substitution in v.2.17.1

[ElaHuskovic68]

Inside war file at path /WEB-INF/lib we found log4j-1.2.13 which needs to be replaced with log4j-2.17.1.jar. In
apache-log4j-2.17.1-bin there is no that file. What jar file replaces old one? Thanks!

[vy]

@ElaHuskovic68, does the Migrating from Log4j 1 page help?

[ElaHuskovic68]

Not in our case. We though just to replace .jar file but no proper match in higher version.

[ppkarwasz]

Can you provide us with some feedback on the migration page? Where does it come short of your expectations?

To better understand, how we can help, can you tell us:

• Do you have access to the source code of the application or is it a third-party application?
• If it is a third-party application, is the producer still around?
• Why did you choose to upgrade to 2.17.1 instead of the currently supported (2.24.x) version?

[ElaHuskovic68]

hi @ppkarwasz - thank you for your answer.
This is third party application, I dont have source code, only war file which contains 1.x version of log4j jar file. I checked with Owner and it looks like it wont work with newer jar file, proper migration has to be done from their end. Due to vulnerability of log4j it is recommended to upgrade on new version. Since I already have application with log4j 2.17.1 - though it could be the same version. Anyway, thanks for your reply.

[ppkarwasz]

@ElaHuskovic68,

This is third party application, I dont have source code, only war file which contains 1.x version of log4j jar file.

Thanks for clarifying your situation — dealing with third-party applications can be tricky, especially when you're limited to what's inside a WAR file.

You're right that our migration guide is primarily geared toward developers who can modify application code. For deployers like yourself, who need to assess risk without modifying the source, the relevant details are available but admittedly not easy to navigate. You're very welcome to suggest improvements or a dedicated section — we’d appreciate the contribution!

In your case, where you're dealing with Log4j 1.x embedded in a third-party WAR, you have a few practical options:

Assess Exploitability — Not Just Vulnerability

Security scanners often flag known CVEs without determining if they’re actually exploitable in your setup. You can use this to your advantage by verifying whether the risky components are even in use.

Here’s a quick guide to the known Log4j 1.x vulnerabilities and when they’re actually exploitable:

CVE ID	Exploitable When...
CVE-2019-17571	Only in the unlikely case the application launches SocketServer, e.g.: java -jar log4j.jar org.apache.log4j.net.SocketServer
CVE-2020-9488	If the app uses SMTPAppender
CVE-2021-4104	If the app uses JMSAppender
CVE-2022-23302	If the app uses JMSAppender
CVE-2022-23305	If the app uses JDBCAppender

To determine if a vulnerability applies to your setup, you can inspect the log4j.properties or log4j.xml file.

Since you already notified the producer of the application and they are working on a solution, I believe this is the right approach. In the coming years you'll see many vulnerabilities, like Tomcat's CVE-2025-24813, that are not exploitable in almost any environment, but cause panic to the system administrator community.

Note: I am not encouraging developers to use EOL libraries. These libraries have a much higher risk of undisclosed vulnerabilities, since nobody is reporting them and nobody is accepting the reports.

Upgrade to a Newer Logging Backend Using the Log4j 1.x Bridge

If you want to modernize the logging system without modifying the application code (since you only have a WAR file), you can use the Log4j 1.x Bridge. This allows applications built with Log4j 1.x to log through the Log4j 2.x backend.

While not a long-term solution for full migrations, it’s often a practical and low-effort approach for third-party applications where source code isn’t available.

How to Set It Up:

1. Remove the old log4j.jar from the WAR file.
2. Add the following Log4j jars:
   • log4j-1.2-api.jar(the bridge)
   • log4j-api.jar (Log4j 2 API)
   • A Log4j API implementation, in your case log4j-core.jar
3. Provide a Log4j 2 configuration file, in your case log4j2.xml, placed in the classpath (e.g., inside WEB-INF/classes).

Note

The bridge supports automatic conversion of some Log4j 1.x configurations.
If you set the system property log4j1.compatibility=true, it can interpret Log4j 1.x configuration files (like log4j.properties) at runtime.

However, for best results and to unlock the full power of Log4j Core, we recommend to switch to a native Log4j 2 configuration format.

[perry2of5]

Some people have been known to recommend Reload4j 1.2.18 as a replacement for log4j 1.2.17

[lalo-mx]

Some people have been known to recommend Reload4j 1.2.18 as a replacement for log4j 1.2.17

https://reload4j.qos.ch/

Initiated by Ceki Gülcü, the original author of Apache log4j 1.x, the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues. Reload4j is a binary compatible, drop-in replacement for log4j version 1.2.17. By drop-in, we mean that you can replace log4j.jar with reload4j.jar in your build with no source code changes, no recompilation, nor rebuild being necessary.

The reload4j project offers a clear and easy migration path for the thousands of users who have an urgent need to fix vulnerabilities in log4j 1.2.17.

[ppkarwasz]

Reload4j is a valid temporary replacement for Log4j 1, and I can certainly recommend it for that purpose. While it introduces some breaking changes compared to Log4j 1.2.17, it is 99% binary compatible with it, making it a suitable choice for immediate mitigation.

For completeness, there are other maintained forks of Log4j 1:

• Versions of Log4j 1 available in the JBoss Enterprise Maven Repository, such as 1.2.17.redhat-00008.
• Versions available in the Atlassian Maven Repository, like 1.2.17-atlassian-18.

Although the release notes for these versions are not publicly available, it’s likely that they address some, if not all, of the known vulnerabilities in the official 1.2.17 release. If you're an Atlassian or Red Hat customer, it’s worth reaching out to their technical support for more information.