Update 21 December 2021
We’ve just released SonarQube 8.9.6 LTS and 9.2.4 (Latest) to eliminate confusion and avoid false-positive from vulnerability scanning tools in regards to: CVE-2021-45046, CVE-2021-44228 and CVE-2021-45105.
In these new versions, the Elasticsearch component is updated to its latest bugfix version, 7.16.2, which updates the packaged Log4J dependency to 2.17.
Note: Although our security researchers have not found the previous SonarQube LTS (8.9.3, 8.9.4 or 8.9.5) or Latest (9.2.1,9.2.2 or 9.2.3) to be susceptible to any of the CVE’s in relation to Log4j at this time, this update has been done from an abundance of caution and we invite you to update to the latest version.
Update 16 December 2021
- The SonarQube Log4J test dependency is updated to 2.16. This dependency is not used outside of unit testing, nor is it included in the SonarQube distribution. It is not susceptible to the CVEs being reported. Nonetheless, we have upgraded it to eliminate confusion.
- The Elasticsearch component is updated to its latest bug fix version, 7.16.1, which removes the potentially problematic components of Log4J. Additionally, it should be noted that SonarQube programmatically adds the
log4j2.formatMsgNoLookups=trueJVM property on starting up Elasticsearch.
More explanations from Elasticsearch here.
Note that the LTS and the Latest are the only two supported versions. All other versions are past EOL. Please update to one of the two supported versions as soon as you can.
Update 15 December 2021
SonarSource CTO Andrea Malagodi asked me to post this statement:
To be clear, at this time our security researchers have not found SonarQube LTS (8.9.3 or 8.9.4) or latest (9.2.1 or 9.2.2) to be susceptible to any of the CVE’s in relation to Log4j (CVE-2021-45046 and CVE-2021-44228).
Since the situation is evolving and new findings are coming out, we wanted to share an update that we hope will put to rest any concerns you may have.
In SonarQube there are two instances of Log4J:
- One is used by SonarQube’s unit tests and is not used outside of unit testing or included in the SonarQube distribution. This test dependency is not susceptible to the CVEs being reported. Nonetheless, we plan to update it.
- The other is packaged with Elasticsearch.
We are working closely with Elasticsearch and yesterday’s releases, 9.2.2 and 8.9.4 LTS, apply the mitigation they recommended at the time (
log4j2.formatMsgNoLookups=trueJVM property ).
Given the newly reported CVE-2021-45046 , we are working to adopt Elasticsearch’s forthcoming update and issue new releases with those changes as soon as possible.
The situation is clearly still developing and we remain focused on addressing the issue as thoroughly and quickly as possible and on providing you with relevant updates as soon as we can.
Update 14 December 2021
As stated earlier, current supported versions of SonarQube are not vulnerable to this attack. Nonetheless, out of an abundance of caution and to alleviate fears, we’ve released updates to the Latest and the LTS that update Log4J to a non-vulnerable version and that add the JVM property by default.
Please see the official announcement for details: SonarQube 8.9.4 LTS and 9.2.2 released
If you have any concerns, you should upgrade to the newly-released 8.9.4 LTS or 9.2.2 (latest) immediately. No other versions are supported, and as such have not been examined w/r/t the Log4J vulnerability.
We will not be releasing Log4J patches to any other versions, nor will we be examining/testing other versions for vulnerability to the Log4J exploit. Thus, we cannot answer your questions about other versions. If you’re worried, you should upgrade to a supported version immediately.
Update 13.12.2021 We can also confirm that SonarCloud was not directly susceptible to this vulnerability, but out of an abundance of caution we have deployed a new version of SonarCloud that updates Log4J to a non-vulnerable version.
Original statement 10 December 2021
Concerning the reported Log4J vulnerability (CVE-2021-44228), we can confirm that the SonarQube application itself does not rely on Log4J directly and that SonarQube LTS 8.9.x and SonarQube 9.2.1 are not directly susceptible to this vulnerability.
SonarQube includes a component from ElasticSearch that contains a Log4J component. At this time, we cannot affirm that there is no risk from this component. We recommend that you add the following property in
sonar.properties or through an environment variable and then restart your SonarQube instance. This will effectively mitigate any risk there might be:
We are monitoring the situation and will provide a fix - if one is necessary - once it is available.