Round 3 - Mitigating CVE-2021-45105 Log4j for your Sitecore SOLR installs

2021, Dec 19

Round 3 - CVE-2021-45105

In my previous posts and previous posts I've shared a PowerShell script that you can use to upgrade log2j in your local Sitecore installs. And yet again there was something not fixed in 2.16.0. To fix these issues they released 2.17.0. You can read more on this post on securityaffairs - Apache releases the third patch to address a new Log4j flaw

Upgrade to log2j 2.17.0

I've tested this version by replacing the Jar files in Solr with Solr 8.8.2 (Sitecore 10.2.0), 8.4.0 (Sitecore 10.0.1) should be fine as well. Other versions might use a different version of Solr. There is one other important dependency (slf4j-api) that I did NOT update because it is already the correct version (slf4j-api-1.7.24.jar). The logs still appeared and I wasn't able to reproduce the jndi lookups anymore, even when I removed the mitigation step (the famous set SOLROPTS=%SOLROPTS% -Dlog4j2.formatMsgNoLookups=true) as described in my previous post.

Updating is quite easy. It requires, again, a PowerShell script to do this.

Use at your own risk

Please use this script at your own risk and tailor it to your needs! The script is not tested against Solr 6.6.2 which uses log2j 1.2.17!

In the script you can specify the exact version of log2j you want upgrade to. For now this is 2.1~7.0, if a newer version is released in the upcoming days/weeks/months you can just fill in the variables and you are all set to run it again.

Executing this script

The script can be found on my GitHub.

Running this script will require Administrator privileges. If you execute this script it will ask you for the drive letter where the solr instances are located. If you have installed Solr on your C drive and D drive you might run this twice. The script does the following things.

  1. Ask you for the drive letter
  2. Searches for Solr instances by looking for files!
  3. Downloads the archive for log2j
  4. Validates the download
  5. Extracts the download
  6. Determines the Servicename
  7. Checks if a service exists, if so it will stop it
  8. Checks the log2j path if upgrade is needed
  9. Updates log2j for Solr if needed
  10. Checks the prometheus-exporter if upgrade is needed
  11. Updates log2j for the prometheus-exporter if needed
  12. Starts the service if it was stopped
  13. Repeat steps 6 - 12 for each instance found.
  14. Removed the downloaded files

If an exception occurs this can be caused by files being in use. This happens if the script could not find a service corresponding with your Solr instance directory name. If you know of any of these situations you can fix those.


Any suggestions or modifications are welcome in the form of a Pull Request.

Have a great day.