Solr application in our analytics already incorporates the updated Log4J version and hence we are not vulnerable to the exploit mentioned your attached VA report. Note that the VA tool was just looking at the Solr version, it doesn’t have the means to check the log4J version update on the Solr, hence it throws up the vulnerability – however the fact that the Log4J version is updated on Solr ensures that it’s not susceptible to this exploit – you can refer to the below documentation from Solr.
https://solr.apache.org/security.html
Hence the Solr package in our analytics is not affected by this vulnerability
In other words, the Solr version doesn’t matter since we are packaging our Solr with an upgraded log4j2 version which is not susceptible to this CVE/Vulnerability.
You can check the log4j version at the below path (on a search node). Below is the output from our lab device the log4j version is 2.17 which has the vulnerability fix (as stated in the mitigation of this CVE) - the Solr version doesn't matter as long as the log4j is updated > 2.16.0)
As can be seen in the above screenshot the Log4j version is 2.17 under the solr library
https://solr.apache.org/security.html
If the log4j version is < 2.16 in your solr library, it indicates that you are on a version which does not incorporate the solr log4j update
You can upgrade your head-end/node to the latest 21.2.3 (Note that 20.2.x and 21.1.x are End-of-
There are no special procedures or exceptions to upgrade to this software version. Please follow the regular instructions outlined here: