A zero-day vulnerability was uncovered in the ubiquitous Log4j library. This dependency is used for event logging purposes (as its name suggests). However, the vulnerability allows for remote access and code execution on affected machines. The fix is to use an updated version of this library (2.15.0 or higher) which prevents this.
We conducted an internal code review at RedLine13 and we do not use Log4j (or related dependencies like Log4php) directly within our systems. JMeter does however use Log4j and thus any server running JMeter is potentially at risk.
We have addressed this in the builds for the various versions of JMeter which we support, by directly updating for this dependency. There is a useful article on CloudFare that describes several effective mitigation strategies. When the Apache Software Foundation releases an “official” update to JMeter that addresses the Log4j vulnerability, we will include that build.
The Log4j issue represents a “zero-day” vulnerability. Something that we make available to all JMeter tests is the ability to use the “Nightly” build. This binary is updated daily, and often will have fixes for issues like this available much sooner than in official releases. This feature was applicable in this case within hours of announcement of the Log4j issue, though using the standard 5.4.1 release from RedLine13 is now preferable because of the above changes we have applied to our JMeter builds.
RedLine13 offers a full-featured free trial that you can sign up for and start testing today.