You may have heard about it already, the Java world is threatened by Log4Shell. That vulnerability has been unveiled in the open-source logging library log4j version 2. It made the last weekend a bit tedious for lots of devs around the world.
What is Log4Shell
The NIST explained it in detail. In short, CVE-2021-44228 lets logging unsanitized input trigger remote code download and execution, typically a malware.
If you want to dig into the technical stuff, Paul Ducklin explains it very thoroughly in his article on Sophos blog.
Gatling products are not affected by Log4Shell
We said it in the title, Gatling’s products are not affected byCVE-2021-44228. Why? Simply because we use other logging solutions:
- the Gatling open-source project has always used the logback logging library. No Gatling open-source release has ever shipped with log4j.
- Gatling Enterprise, whether it’s self-hosted, purchased through the AWS and Azure marketplaces, or our new Cloud offer, uses logback and not log4j.
- Gatling Cloud uses Keycloak for authentication, and it’s not been impacted either. Don’t get confused here: Keycloak does use log4j, but the very old version 1 that is not affected. You might read that log4j version 1 is outdated and suffers from other vulnerabilities, but those are way less critical as they impact optional features that are not enabled in Keycloak. Still, the Keycloak community will most likely get rid of log4j version 1 in a safe fashion in one of the next releases. We’ll update our servers then.
To all our fellow devs and ops working hard to check and patch all their Java applications: good luck, at least you can rest easy regarding your Gatling projects.
