Log4j 2.15 vulnerability CVE-2021-45046 upgraded to a critical severity arbitrary code execution
Editor’s note (28 Dec 2021 at 7:35 p.m. GMT): The Log4j team released a new security update that found 2.17.0 to be vulnerable to remote code execution, identified by CVE-2021-44832. We recommend upgrading to the latest version, which at this time is 2.17.1. Read more here.
Editor’s note (18 Dec 2021 at 6:55 p.m. GMT): The Log4j situation is rapidly changing and we are updating our blogs as new information becomes available. It is recommended you upgrade to version
2.17.0 or later. This version contains security fixes for two remote code execution vulnerabilities, fixed in
2.15.0 (CVE-2021-44228) and
2.16.0 (CVE-2021-45046) and the latest DoS vulnerability fixed in 2.17.0 (CVE-2021-45105). Read more here.
It has been discovered that Log4j version
2.15.0 is still susceptible to an arbitrary code execution attack, under certain circumstances. Upgrade to version
2.16.0 or later, to protect your applications against CVE-2021-44228 and CVE-2021-45046.
The latest vulnerability disclosed against Log4j 2 (CVE-2021-45046), which was originally disclosed as a low severity denial of service with a CVSS score of 3.7, has now been upgraded to high severity, arbitrary code execution vulnerability with a CVSS score of 9.0. Additionally, this means that Log4j version
2.15.0 which was previously thought to be safe from arbitrary code execution is now exploitable under certain conditions.
A malicious actor is able to bypass the mitigation implemented in version
2.15.0 that limits JNDI lookups to localhost only:
We recommend updating to version
2.16.0, which completely disables JNDI lookups by default. If upgrading is not an option, this issue can be mitigated in prior releases by removing the
JndiLookup class from the classpath (example:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Am I affected by the upgraded vulnerability?
Your application is vulnerable if you are running one of the affected versions of the Log4j package (from
2.12.2) and meet at least one of the following conditions:
- Logging configuration explicitly enables lookups — either by default (if using a version lower than
2.15.0) or manually by using
formatMsgNoLookupsis switched on by default as of version
- Uses a non-default Pattern Layout with Context Lookup where attackers can control input data via Thread Context Map (MDC),
Logger.printf("%s", userInput)function where attackers can control the
IMPORTANT NOTE: You will need to audit both your source code and runtime instances to be able to validate that you do not meet any of the conditions above. This is not an easy task, and if you are in doubt, you should assume that you are potentially vulnerable.
What you need to do now
TAKE ACTION! Upgrade to version
2.16.0 or higher immediately to mitigate this issue. This is the safest version currently available that mitigates both the recently disclosed Log4j vulnerabilities (CVE-2021-44228 and CVE-2021-45046).
Log4j vulnerability timeline (CVE-2021-44228 and CVE-2021-45046)
- July 18th, 2013 – The code that introduces JNDI lookups and the vulnerability has been committed
- November 24, 2021 – Alibaba Security Research team approaches Apache with a private disclosure
- November 29 – Apache begins working on a new release (2.15.0) with a security fix
- December 1 – The first rudimentary exploit attempts noted in the wild
- December 5 – All fixes are merged into the master branch
- December 9 – A GitHub user raises the suspicion that the fix relates to a security vulnerability
- December 9 – A user creates a GitHub issue in the
google/tsunami-security-scanner-pluginsrepository, identifying the RCE vulnerability in Log4j
- December 9 – Issue is leaked unofficially in a tweet by user p0rz9.
- December 9 – PoC was published on Github
- December 10 – Issue “officially” disclosed and given CVE (CVE not yet published to MITRE). Fixed version
- December 10 – CVE Mitre updated, assigned (CVE-2021-44228)
- December 10 – Critical severity added to Snyk SCA (CVE-2021-44228)
- December 13 – Version
1.xmedium severity vulnerability advisory (CVE-2021-4104)
- December 14 – Version
2.15medium severity DoS vulnerability discovered (CVE-2021-45046)
- December 17 – CVE-2021-45046 upgraded to critical severity and recategorized as Arbitrary Code Execution