CVE-2021-44228 and Jitsi components


Some of the Jitsi components load a version of log4j which is affected by CVE-2021-44228. According to our review, jigasi and older jitsi-videobridge instances configured to use callstats may be affected, while all other jitsi components and jigasi instances with no callstats configuration are not affected.


Jigasi instances with callstats enabled should be updated to 1.1-216.

Jitsi-videobridge instances older than 2.1-504 (May 2021) with callstats enabled should be updated to 2.1-504 or newer.

Affected components

None of the jitsi projects use log4j directly, however some of them load it as a transitive dependency via jitsi-stats → callstats-java-sdk.


Jicofo loads it only at the test phase due to the jitsi-videobridge dependency, and thus it is not affected.


When callstats is not enabled, jitsi-videobridge is not affected.

When callstats is enabled:
Versions before 2.1-504-g2f7fcb978 (May 2021) may be affected.

Versions between 2.1-504 and 2.1-594-g56e0dae00 (inclusive) are not affected because they use incompatible versions of log4j, resulting in a failure to load the affected log4j-core classes:
[INFO] ± org.jitsi:jitsi-stats:jar:1.0-7-g2a9b765:compile
[INFO] | - io.callstats:callstats-java-sdk:jar:5.2.1:compile
[INFO] | ± org.apache.logging.log4j:log4j-api:jar:2.3:compile
[INFO] | ± org.apache.logging.log4j:log4j-core:jar:2.13.2:compile

Versions v2.1-595-g3637fda42 (Dec 10, 2021) and newer are not affected, because they include a new version of log4j:
[INFO] ± org.jitsi:jitsi-stats:jar:1.0-9-g4ce7952:compile
[INFO] | ± io.callstats:callstats-java-sdk:jar:5.3.1:compile
[INFO] | | ± org.apache.logging.log4j:log4j-api:jar:2.15.0:compile
[INFO] | | ± org.apache.logging.log4j:log4j-core:jar:2.15.0:compile


When callstats is not enabled, jigasi is not affected.

When callstats is enabled jigasi versions prior to 1.1-216-ga2399b9 (Dec 10, 2021) may be affected.


We are in the process of releasing a new version of jigasi to all our deployments. There are no other running systems affected by the issue.


A new debian stable version of jigasi has been released. A new debian stable release of the jitsi-meet package will be released soon. New docker images will be released soon.


Thanks for lightning-fast reactivity! We all appreciate the work the team does. Thank you!

1 Like

The new stable is out with the updated jvb version. jitsi-meet-release-notes/ at master · jitsi/jitsi-meet-release-notes · GitHub


related advisories have been published:


New Docker images have just been published: Release stable-6726: release · jitsi/docker-jitsi-meet · GitHub


Thank you so much for your hard work!

@damencho, do you know how easy is to exploit this in a system using jvb 2.1-538 with call stats enabled? Like, what would a user have to do?

Another question, a sign of exploitation would be a log like this:

2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://]. javax.naming.CommunicationException: [Root exception is Connection refused (Connection refused)]

That was taken from this blog: Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package | LunaSec

We are not sure, how easy it is. Personally, looking at the callstats logs, I do not see any information coming from clients to be printed. This is my assumption, and we worked yesterday on the issue without any assumptions, so we can protect everybody 100%.


Thank you so much for the quick reply! And also thank you for your work remediating this vulnerability.

1 Like

Dear Team,
Have you seen the next CVE related to log4j v2?
Second Log4j Vulnerability (CVE-2021-45046)
Could we expect an another update soon?
Many thanks!


I used this as a workaround:

zip -q -d /usr/share/jitsi-videobridge/lib/log4j-core-2.*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

to remove Jndilookup.class from any log4j-core-2.*.jar file

Then restart the server.

Note: The log4j version 2.15, distributed with jitsi, is vulnerabile.


CVE-2021-45046 does not affect the jitsi components, because they don’t use any of the related features in PatternLayout (jvb, jigasi). We’re in the process of updating to 2.16.0 in any case.


@Boris_Grozev , thank you.

Are callstats enabled by default in a standard installation (i.e. following the self-hosting guide)? Also, where can I verify if callstats are enabled in my installation for jigasi / jitsi-videobridge respectively?

No, in order to enable it you need to create an account on callstats and it is paid service for monitoring webrtc calls.

1 Like

I’m sure you’re focused on the log4j problem which occupies us all at the moment.
I see that my jitsi instance is now on 2.15 but the latest recommandation is to update on 2.17.

Is there a roadmap about that ?

Log4j was removed from the dependencies chore: Remove all use of log4j. by bgrozev · Pull Request #1786 · jitsi/jitsi-videobridge · GitHub
If you want, you can update to the latest from unstable.

I’m using the Debian-like packages, and log4l is still not fixed there!
Is the fix scheduled there soon?

And more importantly, is there a plan to make a proper Debian package? Having an embedded copy of log4j in videobidge is really bad practice. The Debian packages liblog4j* have been fixed almost immediately upon CVE disclosure. Videobridge really should use this, rather than ship its own copy, which is not updated!

Yep, log4j was dropped in jvb in latest packages. You can update to unstable if you need it.
The source code repo is not shipping the lib, but is using the maven repo, this cannot happen for binary packages though. As we ship reproducible builds, with all dependencies. For reproducible builds you cannot download different library versions between runs.


@damencho, do you have a timing estimate on when a stable version is estimated to be released? I see the last unstable version appears to be built on Dec 28th. We have issues with security compliance not allowing log4j 2.15 or 2.16 to be used and they are not pleased about an unstable version as a workaround. Thanks kindly and appreciate all the hard work to dig out from this mess!