Quarkus is not affected by the Log4J Vulnerability
As many of you have heard, the Java community has been rocked by a widespread vulnerability in the Apache Log4J 2 logging library. You can find more details about this vulnerability in CVE-2021-44228
Since Quarkus, its extensions, and dependencies do not use the log4j version 2 core library, it is NOT susceptible to this vulnerability. In most cases, no corrective action is required for any Quarkus backed projects you may have. Quarkus does expose the log4j API jar which in itself is not vulnerable. This is purely a compatibility and translation layer, which maps calls to a different logging backend (JBoss Logging). Therefore, any direct usage of the log4j API is not impacted.
False Positives in Security Scans
Still tools that do security scans are not smart enough to discern between a transitive dependency and what actually ends up bundled and/or configured in your application.
Thus we do see reports from such tools falsely claiming Quarkus or some of its extensions in its ecosystem are affected although in practice they are not.
Examples of such finds are Camel NSQ, Camel Corda and Vert.x which in their transitive dependencies include a log4j-core.jar but it is never used nor in any form activated when using Quarkus.
You will see us do updates in Quarkus and Quarkus extensions to reduce these false positives. As a user and consumer of Quarkus, your application is not exposed to the log4j vulnerability.
Red Hat Product Security Bulletin
You will find mention in Red Hat’s product security bulletin that “Red Hat Integration Camel Extensions for Quarkus” is affected. It gets classified this way because during Red Hat’s productized build the log4j-core.jar got included in the generated Maven repository zip file due to the transitive nature of Maven dependencies. Meaning that if you use Camel Quarkus you are not affected by the log4j vulnerability but Red Hat product technically “shipped” the log4j-core.jar thus it is marked as affected.
The Camel team is doing an update to have log4j removed from this Maven repository zip file. Something you as a user of Quarkus or Camel Quarkus will not be affected by.
Recommendations
While Quarkus itself does not use or enable usage of the Log4j core implementation library, it is always possible for an application built on Quarkus or any other general-purpose Java based framework to bypass the default provided logging facilities with custom code.
As an added precaution, we do recommend auditing your application dependencies and/or setting the log4j2.formatMsgNoLookups system property to true. The latter will prevent any unintentional inclusion of this vulnerability. A simple way to do this is to add -Dlog4j2.formatMsgNoLookups=true to the Quarkus command line.
However, the best action is that if for whatever reason you do have log4j-core on your classpath and configured to log, that you ensure it is upgraded to version 2.16 or higher.
In the wake of this vulnerability we’ve seen other similar issues show up - none as severe as the log4j vulnerability but we are actively monitoring it and if things change we will upgrade this blog and our announcement topic in the official Quarkus Github Discussions.
We applaud the Java and security communities and in particular the Log4J 2 contributors for their swift response to this critical issue.
We especially send warm thoughts and appreciation to the OSS Repository Hosting by Sonatype enabling the swift publishing for projects that truly are affected by this vulnerability.
