Log4j is an extremely popular and heavily used open-source Java library that can be used for unauthenticated remote-code execution, making CVE-2021-44228 and CVE-2021-45046 critical vulnerabilities that you must pay attention to.
In other words: if your software uses this library, then there is a good chance that anyone can gain full remote control of your servers and data.
This particular vulnerability is among the worst we’ve seen in the last 5 years, in part because the vulnerability itself is so severe and so easy to trigger. Adding to the severity, this vulnerable library is among the most popular and widely deployed open-source Java libraries on the planet.
The Apache Struts disaster from 2017 (CVE-2017-5638) was a large part of why we launched our startup (mergebase.com): to help companies protect themselves from known-vulnerabilities in open source libraries exactly like these.
This time it’s even worse. Globally, everyone must now urgently scramble to upgrade all applicable software to use Java library log4j version at least 2.15.0 (which was published today). Companies that for whatever reason fail to execute on this upgrade will likely be attacked and exploited within the next few days – assuming they are not already under attack.
We cannot stress how urgent it is for administrators of Java systems to succeed in rolling out this upgrade. Patch this Critical log4j vulnerability in Java CVE-2021-44228 immediately.
There is an easy way to check any server for this vulnerability. At the root of your file system, using an administrator account, download and run our free Log4J-Detector tool: https://github.com/mergebase/log4j-detector
This command can take several hours to complete. Any occurrence of “_VULNERABLE_” in this command’s output indicates with high probability that you are vulnerable to this severe software exploit.
MergeBase can help you patch your vulnerable systems to eliminate this bug. MergeBase can also help you in situations where patching is not possible. We have a patented cyber-security technique for exactly this situation.
Further reading: https://www.lunasec.io/docs/blog/log4j-zero-day/
You might also be interested in this video on securing log4j instantly with run-time protection.