XWiki not affected by the security issue in Log4J

14 Dec 2021 5 min read

Written by

The XWiki Team

You have probably seen many reports now about a vulnerability found in Log4J 2 up until 2.14.1 1. This issue is affecting a wide variety of projects in the Java world.

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” in the name*, those are actually APIs (which are not vulnerable, only the implementation is) and from which the log is redirected to slf4j 1 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 redirects to slf4j) in XWiki 3.1 (2011).

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)

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 3 and Jetty, 2 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 3, 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.

Similarly, the XWiki recommended apps are not using Log4J either. Like in the case of libraries that 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 implementation with the standard build setup. But even if an extension manages to be deployed with log4j-core declared as a dependency, XWiki Extension Manager won’t install this dependency, so none of them should be able to bring this vulnerability to an XWiki instance.

Additional checks and scans have been performed on our XWiki Cloud service and we have not found the presence of the Log4J module on the virtual machines providing this service.

We have also performed additional checks on our whole infrastructure and services in order to make sure we are not exposed to attacks exploiting this vulnerability, allowing us to protect our own data as well as our clients' data.

Additionally, in order to more generally protect your infrastructure from this critical vulnerability, and in case this has not yet been done, we recommend that you scan your servers for the presence of the log4j-core*.jar in order to identify if other applications could be exposed.

If you have any additional questions, please don't hesitate to contact us.

You may also be interested in: