GitHub user ppkarwasz added a comment to the discussion: log4j-1.2.13.jar
substitution in v.2.17.1
@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 2 jars:
- `log4j-1.2-api.jar`(the bridge)
- `log4j-api.jar` (Log4j 2 API)
- A [Log4j API
implementation](https://logging.apache.org/log4j/2.x/manual/installation.html#impl),
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](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#ConfigurationCompatibility).
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, it’s
> recommended to switch to a native Log4j 2 configuration format.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13141001
----
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
