Urgent Log4j server security vulnerability - REQUIRES IMMEDIATE ATTENTION!

Dear All,

A very urgent security issue was made public today in a well-used library that affects many web services (see CVE-2021-44228 - Log4j 2 Vulnerability Analysis - Randori Attack Team).

We have checked and can confirm that this issue also affects the following DHIS2 versions:

  • 2.32 (patch 2.32.5 and above)
  • 2.34 (all patches)
  • 2.35 (all patches)
  • 2.36 (all patches)
  • 2.37 (all patches)

The issue can result in an attacker obtaining control of the server.

Due to the serious nature, and the fact that this vulnerability is public, we urge everyone to take the following mitigations AS SOON AS POSSIBLE:

  • Shutdown your DHIS2 instance
  • Apply the following option to the JAVA_OPTS variable for your DHIS2 environment [1]:


  • Restart your DHIS2 instance

Note: You may not require these mitigation steps if you are using JDK versions greater than 8u191 and 11.0.1. We will confirm in a subsequent post.

Update! You are NOT protected from this vulnerability by only running a recent JDK, the only way to protect yourself is to apply the mitigation or upgrade to the latest patched DHIS2 version.

The above steps will ensure that your DHIS2 instance is secure from anyone trying to exploit the vulnerability.

Our core team is already planning to provide patched .war files for the affected versions as soon as possible, but the mitigation mentioned above should be enough to keep your implementation safe until a patched version is available.


The DHIS2 Security Team

PATCHES NOW AVAILABLE - we are adding the patched releases here as they become available:

These patch releases differ from the previous patches only in the addition of this security hotfix:
2.32: 2.32-eos - SUPERSEDED*
2.35: 2.35.9 - SUPERSEDED*
2.36: 2.36.5 - SUPERSEDED*
2.37: 2.37.1 - https://releases.dhis2.org/2.37/dhis2-stable-2.37.1.war + docker

This is a nominal patch release with the security hotfix included:
2.34: 2.34.8 - SUPERSEDED*



  • If you are using dhis2-tools-ng this is OS dependent, for example in Ubuntu the default file can be found on /etc/default/tomcat9
  • If you have followed the System Administration Guide when installing DHIS2 you should modify the tomcat-dhis/bin/setenv.sh file.

Update! The most recent updates (CVE-2021-45046) online have indicated ongoing concerns beyond the upstream Log4j fix announced previously, but based on the information that we have, DHIS2 should not be affected by these concerns. Read more here


I am running instances on my Windows 10 using docker ‘@dhis2/cli’, so do you think I should run an update for those instances or it doesn’t matter when using docker? Thanks!


Thanks Phill.

It seems none of the version 33 is affected. Or we should update the ‘setenv’ for safeside?


I would add that JVM argument to any java application that is using log4j if possible… especially if it is accessible to the public.

Running within Docker will provide some additional security, but it is possible to break out of VMs.

1 Like

:sweat_smile::sweat_smile: Thanks @ddaley! (:

This would be good info… I have been trying to find out if these fixes were applied to OpenJDK as well. Oracle applied some JNDI/LDAP fixes to that Java 8 version.

Hi @Hannan ,

Indeed, we don’t believe 2.33 is vulnerable to this exploit. There is no need to set the JAVA_OPTS variable, as long as you stay on that version or one of the patches that we plan to release soon.

Thanks, Phill,

We are scheduled to upgrade the instance to version 36.x if there are no conversion issues. So, I will use this java environment variable.

We are using OpenJDK version 9 and might try with Open JDK 11 during this upgrade.



1 Like

Please also be aware that DHIS 2.33 is not supported anymore from our side, and any other seucurity updates won’t be applied to that version.

In regard to this issue, I would suggest just setting the env variable anyways, in no way can it hurt.



Is the vulnerability exploitable without authentication on DHIS2?

1 Like

Hi @SferaDev ,

Yes. Unfortunately it is.

1 Like

Hi Gassim

It sounds like you are running on a windoze 10 workstation, ie not exposing a service on the global internet. In which case you wouldn’t need to be concerned.

If you are exposing this dockerised tomcat to the internet then yes, you would need to run your docker with revised tomcat JAVA_OPTS until a new patched image is released.


1 Like

Dear all,

Please note: I am adding the links for the patch releases (fixing this vulnerability) to the initial post at the top of the page, as they become available.


Wonderful , thanks to the whole team


Good day @phil

Thanks for sharing this important info.

However, please note we are still using 2.29. So, should we update the "setenv’ too?

Warm regards,


Hi @MSP ,

2.29 is not affected by the vulnerability so there is no need for the mitigation.

Of course, for various reasons, including the ability to patch other security issues, it is advisable to have an upgrade plan in place to move to a maintained version (and latest patch).

You could also apply the mitigation as a precaution against the possibility that someone upgrades in the future to a vulnerable patch (for example 2.36.4, instead of 2.36.5).

Kind regards,

1 Like

Thank you @phil for your quick response.

We do have the upgrade plan but could not execute it on time. Hopefully, we will upgrade in Jan 2022.

Thank you and have a good day ahead!

Warm regards,


Yes, thanks! :pray:

1 Like

We are using 2.33.5 in all of our MSF OCB projects (total 57 instances). We have adapted the JVM parameters as suggested. Please share if there are any additional issues / vulnerabilities with v2.33.5

We do not have any plan to upgrade to newer version soon but will do if necessary. Please suggest.

Many thanks in advance.

Médecins Sans Frontières