Hi,
according to the docs Before You Upgrade | SonarQube Docs => Migration Path
this should be straight 8.9.0 (first 8.9.x LTS version) to 8.9.5 (most recent 8.9.x LTS version).
i.e. i myself updated today from 8.9.1 to 8.9.5 without any problems.
Gilbert
Hi @alevenelli,
To augment Gilbert’s excellent answer, I just want to say that in this within-version situation, you should be good to just copy your configuration file from one to the other and go.
HTH,
Ann
Could you explain why log4j-api-2.11.1.jar is still part of the image?
$ docker run -it --rm --entrypoint /bin/bash sonarqube:8.9.5-community
Unable to find image 'sonarqube:8.9.5-community' locally
8.9.5-community: Pulling from library/sonarqube
8572bc8fb8a3: Already exists
702f1610d53e: Already exists
8c951e69c28d: Already exists
9588b35368ad: Pull complete
66a6213f95b1: Pull complete
Digest: sha256:7dcdbe5916baa346ce039ca67c58794e0a0d7380976cbef37725ec0cd5330455
Status: Downloaded newer image for sonarqube:8.9.5-community
bash-5.0# find /opt/sonarqube/ -name "*log4j*.jar"
/opt/sonarqube/elasticsearch/lib/elasticsearch-log4j-7.16.1.jar
/opt/sonarqube/elasticsearch/lib/log4j-api-2.11.1.jar
Please read the previous answers. The vulnerablity only affects log4j-core (and you’re looking at log4j-api).
Thanks @ganncamp unfortunately, removing the class is no longer an acceptable resolution per our organization’s SOC.
We are actually an enterprise customer, I will likely go that route to voice our concerns (Enterprise Support). We are likely going to have to shutdown our Sonarqube installation until the elastic dependency can be upgraded to include log4j 2.16.0.
Regardless of whether or not the mitigations are in place, its just not worth the risk for an organization. Apologies for the directness, but I am sure other companies using Sonarqube that deal with PHI/PII/HIPAA data are in the same boat.
Elastic updated the log4j library today to 2.17 and released 7.16.2:
Hopefully this will put an end to the false positive reports of vulnerability scanners once a new sonarqube version is released.
Ps.: looks like they have not built the release as of now, fingers crossed they push it out the door soon.
upgrade from v9.2.2 to v9.2.3 throws me errors in log file.
ES log file
2021.12.19 07:33:32 WARN es[stderr] java.lang.NoClassDefFoundError: Could not initialize class Log4jHotPatch
2021.12.19 07:33:32 WARN es[stderr] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2021.12.19 07:33:32 WARN es[stderr] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
2021.12.19 07:33:32 WARN es[stderr] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2021.12.19 07:33:32 WARN es[stderr] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
2021.12.19 07:33:32 WARN es[stderr] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
2021.12.19 07:33:32 WARN es[stderr] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:535)
APP log file
Exception in thread “Attach Listener” Agent failed to start!
2021.12.19 07:33:40 INFO app[o.s.a.SchedulerImpl] Process[ce] is up
2021.12.19 07:33:40 INFO app[o.s.a.SchedulerImpl] SonarQube is up
Everything seems up be up and running with all data and not sure what to make of it.
Wondering if anyone else is having issues?
Opened Support case
ElasticSearch 7.16.2 has been released with Log4j 2.17
Elastiscsearch and Logstash 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not trigger false positives in vulnerability scanners.
We are using SQ Enterprise Edition * Ver 8.9.1 (build 44547) and for the moment we can’t upgrade because we need to fix some stuff manually in our database but we were able to upgrade the log4j* (core and api jars ) from version 2.11.1 to 2.17.0 and our webserver is operational. I also applied the property sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true in the sonar.properties file ,if there is something else I should consider please let me know 
.Thanks
Any updates on CVE-2021-45105 ?
Hi,
Sonarsource Jira has still status ‘unreleased’ but https://binaries.sonarsource.com/ has already
Sonarqube 8.9.6 and 9.2.4 with the update to Elasticsearch 7.16.2 which uses log4j 2.17.0
Gilbert
Hi all,
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.
Andrea
Hi All
On latest 9.2.3 Developer edition we are still seeing log4j 2.11.1 old version.
Hello, what about SonarQube version 9.1? Do I need to upgrade it to 9.2 or downgrade it back to 8.9.3?
Dennis…
Do you mean log4j-api-2.11.1? That one is safe (so far).
It is only log4j-core that contains the vulnerable class.
I was referring to all the discussion about “[CVE-2021-45046, [CVE-2021-44228 ], and CVE-2021-44228”.
All the discussion states 8.9 and 9.2 are okay, but no mention about 9.1
There’s no mention to it because it’s not supported. 
The only supported versions are LTS (8.9.x) and the latest 9.2 release.
A post was split to a new topic: SonarQube doesn’t start with an error message about Eleasticsearch
Hi,
Do you have more info about the CVE-2021-44832 vulnerability? CVE-2021-44832: A Medium Severity Was Found in Log4j
so upgrade to log4j 2.17.1?
thanks
Vincent
Not a sonarsource employee, but:
In order to exploit CVE-2021-44832 you already have to have a bad actor on your network and/or your server with the configuration file is badly configured. You will have way worse things to worry about and mitigate than this theoretical exploit (aka your network is totally owned).
This was a badly assigned CVE from security researchers hungry to hop onto the log4j bandwagon and grab some fame imo…
Where I work we will upgrade from 2.17.0 possibly in a few months in the next regular maintenance/module dependency upgrade period. Unless a real security vulnerability pops up.