2.24.2
12 years ago
28 days ago
Known vulnerabilities in the org.apache.logging.log4j:log4j-core package. This does not include vulnerabilities belonging to this package’s dependencies.
Automatically find and fix vulnerabilities affecting your projects. Snyk scans for vulnerabilities and provides fixes for free.
Fix for freeVulnerability | Vulnerable Version |
---|---|
org.apache.logging.log4j:log4j-core is a logging library for Java. Affected versions of this package are vulnerable to Arbitrary Code Execution. An attacker with access to modification of logging configuration is able to configure In the fixed versions, How to fix Arbitrary Code Execution? Upgrade | [2.0-beta7,2.3.2)[2.4,2.12.4)[2.13.0,2.17.1) |
org.apache.logging.log4j:log4j-core is a logging library for Java. Affected versions of this package are vulnerable to Denial of Service (DoS). Does not protect against uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, PoCIn
In
How to fix Denial of Service (DoS)? Upgrade | [2.0-beta9,2.3.1)[2.4,2.12.3)[2.13.0,2.17.0) |
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:
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 PoCIn config:
In code:
HistoryThis 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. How to fix Remote Code Execution (RCE)? Upgrade | [2.0-beta9,2.3.1)[2.4,2.12.2)[2.13.0,2.16.0) |
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. How to fix Remote Code Execution (RCE)? Upgrade Use this guide to scan your projects for the Log4Shell vulnerability. | [2.0-beta9,2.3.1)[2.4,2.12.2)[2.13.0,2.15.0) |
org.apache.logging.log4j:log4j-core is a logging library for Java. Affected versions of this package are vulnerable to Man-in-the-Middle (MitM). Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender. How to fix Man-in-the-Middle (MitM)? Upgrade | [,2.13.2) |
org.apache.logging.log4j:log4j-core is a logging library for Java. Affected versions of this package are vulnerable to Deserialization of Untrusted Data. When using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code. How to fix Deserialization of Untrusted Data? Upgrade | [,2.8.2) |