You have probably seen many reports now about a vulnerability found in Log4J 2 up until 2.14.1. This is affecting a wide variety of projects in the Java world, and here is a report for the XWiki ecosystem.
First, XWiki itself (the WAR we distribute) is not using Log4J but Logback, which means it’s not impacted. If you are wondering why you do see JAR files with “log4j” 2 in the name*, those are actually APIs (which are not vulnerable, only the implementation is) and from which the log is redirected to slf4j and then to Logback. This is true for old versions of XWiki too, since we never used log4j and moved from commons-logging to slf4j/logback (and added the various redirect to slf4j) in XWiki 3.1 (2011).
But the XWiki WAR is only one piece of the XWiki ecosystem, and you generally use other tools with it.
XWiki being a Servlet you need an application server, and you will need to check separately if the one you are using is impacted. Tomcat and Jetty, which are the most commonly used application servers for XWiki are not using log4j by default, so they are not impacted.
The Debian packages provided for XWiki are relying on Tomcat, and they don’t bring anything else, so they are not impacted. The XWiki docker image is not affected either (we ran “docker scan” on them and didn’t find any vulnerability related to Log4J). It is based on the Tomcat 9 base docker image and the XWiki WAR is installed in it. Since both are not impacted, the XWiki docker image is not impacted.
While the embedded version of Solr is safe (like any other library embedded in XWiki because of the redirection of all log through slf4j/logback) the Solr team reported that standalone versions between 7.4.0 and 8.11 are impacted, so you should think about patching or upgrading them shortly especially if they are public facing. That being said, if your Solr instance if not public facing (which, in general, is a very good thing to do since the point is for it to be used by XWiki only in this context) the impact should be low.
Like in the case of libraries which are coming with the XWiki WAR, XWiki extensions are not supposed to come with their own logger implementation, and it’s impossible to build an extension depending on log4j 2 implementation with the standard build setup. But even if an extension manages to be deployed with log4j-core declared as dependency, XWiki Extension Manager won’t install this dependency, so none of them should be able to bring this vulnerability to an XWiki instance.
* If you check the XWiki WAR’s WEB-INF/lib directory, you’ll see the following JAR files:
- log4j-api-2.x.jar: The Log4J 2.x API (not impacted)
- log4j-over-slf4j-1.x.jar: The bridge from Log4J 1.x to SLF4J (not impacted)
- log4j-to-slf4j-2.x.jar: The bridge from Log4J 2.x to SLF4J (not impacted)
Thanks for your support
-The XWiki dev team