Log4Shell: Do Apache Log4j CVE-2021-44228, CVE-2021-45046, or CVE-2021-45105 affect Azul's JVMs?


Do Apache Log4j CVE-2021-44228, CVE-2021-45046, or CVE-2021-45105 affect Azul's JVMs?



These CVEs do not affect the JDK directly, and while there have been related vulnerabilities which have affected JDK versions in 2009, 2017, and 2018, versions since then have been secure against those issues.

However, the new CVEs are reported against Apache Log4j, which is a logging framework used almost everywhere in Web Application frameworks. You will need to take steps to find and secure any environment which uses Log4j. 

A safe long-term strategy that mitigates all three of the recent CVEs is to upgrade to Log4j 2.17.0 everywhere. It's possible that deploying this update may cause issues with your web services, so it would be wise to take the time to run through an Integration Test cycle first. Get the latest Log4j here:

If you're unable to upgrade, please review the mitigation techniques suggested by Log4j that are appropriate for your environment and versions, documented here:

Here are some additional sites we feel provide particularly good, trustworthy information. The LunaSec article in particular provides a lot of helpful information about how to determine if you are vulnerable and possible options to consider for mitigation for environments where an upgrade is difficult.

Here are some additional details to help you with queries you may have to field internally.

  • Some versions of Log4j can use LDAP and JNDI to lookup and acquire resources over the network, and under certain conditions it allows arbitrary, untrusted code from an LDAP server controlled by a malign actor to execute
  • Apache Log4j is not part of Zulu, but is likely present in your environments as part of any number of application frameworks, including Apache Tomcat or Eclipse Jetty.
  • Similar Remote Code Execution (RCE) vulnerabilities have been reported against versions of Java between 2009 and 2018. Each used a similar mechanism, loading code over JNDI, but each had a separate execution path. Fixes were released to block the particular execution path each time.
  • The present CVE uses the same mechanism, but the execution path which allows the vulnerability to be exploited lies within the vulnerable versions of Log4j rather than the JDK.

Add Comment



Please sign in to leave a comment.

Was this article helpful?
1 out of 1 found this helpful