Upgrade Apache Solr 8.10.1 log4j 2.14.1 version to 2.15 to address critical vulnerability

Question

Recently a critical log4j vulnerability was discovered.

I want to upgrade the log4j as used by my current Solr instance, so I checked here. However, I don't see a log4j.properties file in "/server/resources/" folder. All I see there is:

• jetty-logging.properties
• log4j2.xml
• log4j2-console.xml

None of these files contain a version. So to upgrade, is it safe to download the latest version of log4j and overwrite the existing jars in folder "\solr-8.10.1\server\lib\ext", or what are the recommended steps to upgrade?

Answer 1

The link you're pointing to is for an older version of Solr (6.6 instead of 8.10.1). The correct version is https://solr.apache.org/guide/8_10/configuring-logging.html where it mentions using log4j 2.

The file log4j2.xml (and even `log4j.properties for that matter) configure the logging itself, not the version of log4j. So updating that file is irrelevant.

Here's what the project page recommends:

2021-12-10, Apache Solr affected by Apache Log4J CVE-2021-44228

...

Description: Apache Solr releases prior to 8.11.1 were using a bundled version of the Apache Log4J library vulnerable to RCE. For full impact and additional detail consult the Log4J security page.

...

Mitigation: Any of the following are enough to prevent this vulnerability for Solr servers:

• Upgrade to Solr 8.11.1 or greater (when available), which will include an updated version of the log4j2 dependency.
• Manually update the version of log4j2 on your runtime classpath and restart your Solr application.
• (Linux/MacOS) Edit your solr.in.sh file to include: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
• (Windows) Edit your solr.in.cmd file to include: set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
• Follow any of the other mitgations listed at https://logging.apache.org/log4j/2.x/security.html

What you're proposing (overwrite the existing jars in folder "\solr-8.10.1\server\lib\ext") seems like the second approach, so it should probably work fine. Just make sure this is the correct place that contains the log4j dependency.