Is xenforo vulnerable to log4j?

As best as we can establish currently Redis doesn't actually use Log4j by itself. I have seen mention of Redis being affected in some of the websites reporting on this but it's not clear why. It might be because of the Redis Java client Jedis, but I presume that's not relevant to most XF users.
ElasticSearch is impacted, and I know if you send malformed queries they can get logged so there is probably a pile of logging happening which is vulnerable.

While XenForo shouldn't be exploitable in standard configuration, applying migrations is still a very good idea.
That will certainly be our recommendation.

However, I'm not certain applications are as affected as feared.

Java JDK 8 update 121 implemented JNDI protections by default.


My understanding is this should mitigate the issues entirely as long as those values have been kept at their default of false. Elasticsearch 7.0 and up has bundled OpenJDK so they should be fine as-is.

With JDK 8u121 being released in January 2017 there is hope that a good chunk of servers are already running a build newer than that.

Our recommendations will be three-fold:
  • Implement jvm.options fix
  • Update Java to JDK 8u121 or higher
  • Update to Elasticsearch 6.4 or above (note the jvm.options fix won't work in older versions because they use an older version of Log4j)
Even with those jndi protections, log4j could end up leaking the server running elasticsearch's IP via arbitrary DNS queries if using a vulnerable version of log4j and formatMsgNoLookups isn't set to false.
Cloudflare just sent this out:

Hello there,

As you may know, a zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) was made public on December 9, 2021 that results in remote code execution (RCE).

For all organizations using Log4j, they should update to version 2.15.0 as soon as possible. The latest version can be found at the Log4j download page.

Customers subscribing to our paid PRO and BUSINESS plans and using our WAF are automatically receiving help with mitigating this vulnerability.

As a Cloudflare FREE user, it is important to us that your site is protected from high severity vulnerabilities. For this reason we are actively deploying mitigation rules on your zones to block any malicious exploit attempts. No action is required from you to turn the new rules on.

For more information please see our blog.

The Cloudflare Team
  • Like
Reactions: HWS

For those who are looking for a JRE/JDK version to mitigate the problem, please don't! CVE-2021-44228 creates a large attack surface depending on the imagination of the attacker and an RCE is just one of them. I would strongly advise you to avoid having a false conclusion by relying on a JVM feature targeting a certain attack vector; there are more vectors. Simply either bump log4j-core to 2.15.0 or set log4j2.formatMsgNoLookups=true system property.
Log4j developer comments
It is really a nasty vulnerability.

A huge part of the issue is log4j will apply variable substitution rules on arguments, so any data passed to the logging system is a threat vector.

The following is affected;
logger.log("{} foo", "bad string");
Just as if you did this;
logger.log("bad string" + " foo");
CloudFlare's log4j mitigation write up says
If you are using log4j v2.10 or above...set the property log4j2.formatMsgNoLookups=true

In addition to Elasticsearch versions 6.4 and above, it appears many versions below 6.4 include log4j 2.11.1, which would quality for the formatMsgNoLookups mitigation method. Check for the existence of /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar on your server running Elasticsearch. The XenForo PSA gives clear instructions on where and how to add the correct formatMsgNoLookups line, but the PSA should be updated to not exclude Elasticsearch 6.3 and below from the versions that can use the mitigation.
Apparently Elasticsearch itself may not actually be vulnerable to RCE since they use the Java Security Manager:

Though there is still the potential for information leaks.

Only Elasticsearch 6.8 and 7.16 will see official fixes for this.
Just to make sure, I am on ES 7.4, I just have to put that 1 line into that 1 piece of file and restart the service? That's about it to fix the issue?

Workaround for Elasticsearch 6.4 and above​

You are able to control the behaviour of Log4j via the /etc/elasticsearch/jvm.options file. Notably, the current recommendation is to add the following line to the end of that file:


You'll then want to restart the elasticsearch server service for that change to take effect.
Top Bottom