No. Apache says Log4j 1.x reached end of life on 5 August 2015, and that none of the security issues it lists will be fixed. The project recommends upgrading to Log4j 2. Many Java applications still carry Log4j 1 inside older jars, so it is worth searching for.
What the Apache project says
The Apache Logging Services page states that Log4j 1 is no longer maintained and recommends that users move to Apache Log4j 2. It also says the issues listed on its security page will not be addressed in the 1.x line.
Log4j 1 and Log4j 2 are different code bases with different package names. Log4j 2 is not a patch for Log4j 1. It is a replacement that you adopt.
Why it keeps appearing
Log4j 1.x usually enters a project as a transitive dependency, brought in by an older library or a vendor product. You may never have chosen it. It also hides inside fat jars and war files, where the original coordinates are gone.
| Where it hides | How to spot it |
|---|---|
| Maven or Gradle dependency tree | Search for log4j:log4j (the 1.x coordinates) |
| Fat or shaded jars | Look for org/apache/log4j classes inside the archive |
| Vendor installed software | Check the lib folder of the product |
| Container images | List jars inside the image layers |
The 2.x line uses the group org.apache.logging.log4j. If you see only the older log4j:log4j group, you have 1.x.
Replace it, step by step
- Find every use with a dependency tree report:
mvn dependency:treeorgradle dependencies. - Identify who brings it in. If a library of yours needs it, check for a newer version of that library.
- Move your own code to Log4j 2 or another logging library. If you use only the logging API, the change is mostly import statements and a new configuration file.
- If a bridge is needed for a library you cannot change, use a maintained bridge from the Log4j 2 project and verify it in tests.
- Exclude the old artifact in your build so it cannot return through another dependency.
- Rebuild and scan the final artifact, not just the source.
What to do when you cannot change a vendor product
Ask the vendor for a version that no longer ships Log4j 1. Until then, limit who can write to its configuration and logs, and keep it off untrusted networks. Our post on finding Log4j everywhere before you patch describes the inventory approach in more detail.
Try it yourself
Open the demo and look for how direct and transitive dependencies are separated, because that is where Log4j 1 usually hides.
Click through it at your own pace, or open it full screen.
Quick check
Is Log4j 1.x affected by the Log4Shell flaw?
Log4Shell is a Log4j 2 issue. That does not make 1.x safe. It has its own listed issues that Apache says will not be fixed.
Can I just rename the jar?
No. The classes are different. You need to migrate the code or use a supported bridge.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists the logging libraries in your builds, including those pulled in transitively, and reachability analysis helps show which findings your code can actually hit. Start with the free scan.
Sources
Last reviewed: 19 October 2026.
