The remaining vulnerability is relevant to a specific configuration of Log4j that DHIS2 does not use. If you apply the fix recommended previously, your DHIS2 instance should be protected from both RVE and DOS attacks.
We will continue to provide updates as more information is made available. Please comment here if you have any questions about what to do to protect your DHIS2 instance.
please double check if this message is still applicable after the recent finding came in, that known mitigations on CVE-2021-44228 won’t work: CVE - CVE-2021-45046
@fhauptmann thank you for being thorough here - if you follow the link in the post above you will find that this update (posted yesterday 14 December) is addressing the CVE-2021-45046 update you reference. I am editing the post to explicitly reference that CVE.
To be explicit, we have evaluated DHIS2’s use of log4j and determined that we are not vulnerable to this particular exploit - DHIS2 does utilize %X to embed a Thread Context Map sessionId in our log4j pattern, however the MCP input is exclusively a base64 hash of a system-generated unique identifier and so cannot be manually crafted by an attacker to inject vulnerable JNDI lookup commands.
We will also be removing all JNDI functionality from log4j (by upgrading to 2.16.0 or higher) shortly in another fleet of patch releases out of an abundance of caution.