- Artifact: log4j:log4j:1.2.17 Original JDK Target Java 1.4 (Class file major/minor version 48.0). Built to run on JDK 1.4 through JDK 8. When executing directly under Java 21 without upgrading, strong Java Platform Module System (JPMS) encapsulation blocks reflection into internal JDK APIs unless explicit command-line flags are configured.
Vulnerabilities & Security Risks
End-of-Life (EOL) since August 2015 with severe unpatched vulnerabilities:
CVE-2019-17571 (CVSS 9.8): Remote Code Execution (RCE) via untrusted deserialization in SocketServer.
CVE-2021-4104: Deserialization vulnerability when configured to use JMSAppender.
CVE-2022-23302: Deserialization vulnerability when configured to use JMSSink.
CVE-2022-23305 (CVSS 9.8): SQL Injection in JDBCAppender.
JVM Command-Line Flag Options (Workarounds for Legacy Log4j 1.2.17 on Java 21)
If you choose not to upgrade dependencies immediately and run the unpatched log4j:log4j:1.2.17 artifact on Java 21, you must pass JVM flags to bypass encapsulation restrictions:
--add-opens=java.base/java.lang=ALL-UNNAMED — Permits reflection into java.lang internals needed by legacy Log4j utilities.
--add-opens=java.base/java.util=ALL-UNNAMED — Grants access to internal collection reflection routines.
-Dsun.util.logging.disableWindowWarning=true — Suppresses legacy reflection warnings on headless/GUI appenders.
Important Note: Passing --add-opens flags resolves Java 21 runtime IllegalAccessException or InaccessibleObjectException errors, but it does not patch or fix any of the severe security CVEs present in Log4j 1.2.17.
Recommended Strategy without Code Rewrite
Upgrade to Log4j 2.x by using the log4j-1.2-api bridge module (org.apache.logging.log4j:log4j-1.2-api) alongside the Log4j 2 core engine. This completely eliminates the need for --add-opens JVM workaround flags and remediates all 1.x vulnerabilities.
Will Upgrade to Log4j 2.x Require Rewriting Code Calls?
NO. Code calls do not need to be rewritten. The log4j-1.2-api bridge intercepts existing org.apache.log4j.* package imports and transparently routes all logging calls directly to the modern Log4j 2 engine. You only need to update your build script dependencies and migrate your configuration file (from log4j.properties/.xml to log4j2.xml).
Top comments (0)