Log4j was affected by a vulnerability that allowed Remote Code Execution (RCE) attacks. In short, user inputs into a software could lead to a code execution on a remote server. This represents a severe security risk. It was named “Log4Shell” (CVE-2021-44228) and immediately addressed by the Log4j team, who provided a fix. In the following days, additional Log4j vulnerabilities were found. While these do not have the same impact as the first one, they can also cause severe damage. For this reason, it is very important to check systems and always update to the latest versions.
Since Log4j is included in numerous software products, the manufacturers of the products had to and still have to provide updates as well. This is still ongoing, and more Log4j vulnerabilities may emerge in the future.
As a moving target, Log4j still gets a lot of attention, under various aspects:
- New (and luckily still less severe) vulnerabilities are found.
- New initiatives are emerging proactively to check log4 sources, such as Google’s initiative: Improving OSS-Fuzz and Jazzer to catch Log4Shell
- At Greenbone, we are creating even more vulnerability tests to get better test coverage, and deploy them to our products on a daily basis.
We have already received a pretty good CVE coverage for the additional Log4j vulnerabilities that have been published in the last few days, including:
As mentioned earlier, we do not stop here. More local security checks will follow today and tomorrow, once Linux distributions have published their advisories.
We already published some facts about Log4j and how to deal with it in our recent posts:
- log4j Vulnerability Detection Available in Greenbone Feeds
- In-Depth Information About Greenbone’s log4j Vulnerability Test Coverage