Researchers have found a critical zero day vulnerability in the Apache Log4J library. Our solution meshStack is NOT affected. Our engineers checked the meshStack services and dependencies and confirmed that our solution does not include affected Log4J modules.
What is the Problem with Log4J?
Apache Log4J is a widely used library for logging errors.
The recently discovered vulnerability CVE-2021-44228 – dubbed Log4Shell or LogJam – was given a CVSS severity level of 10 out of 10. It’s a vulnerability that seems to be easy to exploit and enables attackers to execute code remotly.
The german Federal Office for Information Security (BSI) warns of the Log4J vulnerability with the highest warning level "4/Red". It goes on to say that "the extent of the threat situation cannot currently be conclusively determined." The BSI also warns that the vulnerability is already being actively exploited, for example for cryptomining or other malware.
When are you affected by Log4Shell?
The first important part is, that the vulnerability is located in the log4j-core module. Other libraries like Spring Boot are only using log4j-api by default and are therefore not affected by this vulnerability (see Spring Boot’s blog post on it).
The vulnerability can only be exploited, if your application logs input that was provided by users in any way (e.g. via an API or via a UI). They could provide certain messages that lead to Log4J executing some code from remote which can be used to access your server and execute some malware on it. As long as you and the libraries you are using are not logging any input given by users, you should not be affected by the vulnerability. But especially with the usage of other libraries it might be hard to judge on whether you are actually affected or not. So if you are using the Log4J for logging, you should – regardless of whether you think that messages provided by users are logged – follow the recommendations below.
Current Recommendations
The Apache Foundation recommends to update the library to version 2.15.0 or – if not possible – to follow the instructions on their Log4J security vulnerabilities page to mitigate the risk.