MarkLogic & the Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
11 May 2023 01:01 PM
Important MarkLogic Security update on Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
A flaw in Log4j, a Java library for logging error messages in applications, is the most high-profile security vulnerability on the internet right now and comes with a severity score of 10 out of 10. At MarkLogic, we take security very seriously and have been proactive in responding to all kinds of security threats. Recently a serious security vulnerability in the Java-based logging package Log4j was discovered. Log4j is developed by the Apache Foundation and is widely used by both enterprise apps and cloud services. The bug, now tracked as CVE-2021-44228 and dubbed Log4Shell or LogJam, is an unauthenticated RCE ( Remote Code Execution ) vulnerability allowing complete system takeover on systems with Log4j 2.0-beta9 up to 2.14.1.
As part of mitigation measures, Apache originally released Log4j 2.15.0 to address the maximum severity CVE-2021-44228 RCE vulnerability. However, that solution was found to be incomplete (CVE-2021-45046) and Apache has since released Log4j 2.16.0. This vulnerability can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath. Components/Products using the log4j library are advised to upgrade to the latest release ASAP seeing that attackers are already searching for exploitable targets.
MarkLogic Server does not use log4j2 within the core server product.
However, CVE-2021-44228 has been determined to impact the Managed Cluster System (MLCMD) in AWS.
Note: log4j is included in the MarkLogic Server installation, but it is only used by MLCMD on AWS. For MarkLogic Server installations not on AWS, you can simply remove the log4j files in the mlcmd/lib directory (
AWS Customers can use the following workaround to mitigate exposure to the CVE.
The versions that are affected by the Log4Shell vulnerability are
Earlier versions of MLCMD use a log4j version that is not affected by this vulnerability.
How to check log4j version used by MarkLogic Managed Cluster System in AWS
If the log4j jar files returned are between 2.0-beta9 and up to 2.14.1 then the system contains this vulnerability.
An example response from a system containing the CVE:
In the above case, the log4j dependencies are running version 2.14.1 which is affected.
The following workaround can be executed on a running MarkLogic service, without stopping it.
1. ssh into your EC2 instance, you must have sudo access in order to make the changes necessary for the fix.
2. Download and extract the Log4j 2.17.1 dependency from apache.
3. Move the relevant log4j dependencies to the
4. Remove the old log4j dependencies
AMIs for MarkLogic versions 10.0-6 through 10.0-7.3 were shipped with the SumoCollector libraries. These libraries are not needed nor are they executed by MarkLogic Server. Starting with MarkLogic version 10.0-8, the SumoCollector libraries are no longer shipped with the MarkLogic AMIs.
It is safe to remove those libraries from all the instances that you have launched using any of the MarkLogic AMIs available in Market place. You can remove the SumoCollector directory and all it's files under /opt.
Additionally, if you have created any clusters using the Cloud Formation templates (managed cluster feature), we would suggest that you delete the SumoCollector directory under /opt if exists. Once MarkLogic releases new AMIs, you can update the stack with new AMI ID and perform a rolling restart of nodes so that the permanent fix would be in place.
For the impacted MarkLogic versions listed above running on platforms besides AWS, the log4j jars are included in the MarkLogic installation folder but are never used. The steps listed in the workaround above can still be applied to these systems even though the systems themselves are not impacted.
MarkLogic Java Client
The MarkLogic Java Client API has neither a direct nor indirect dependency on log4j. The MarkLogic Java Client API does use the industry-standard SLF4J abstract interface for logging. Any conformant logging library can provide the concrete implementation of the SLF4J interface. By default, MarkLogic uses the logback implementation of the SLF4J interface. The logback library doesn't have the vulnerability that exists in the log4j library. Customers who have chosen to override logback with log4j may have the vulnerability. Such customers should either revert to the default logback library or follow the guidance provided by log4j to address the vulnerability: https://logging.apache.org/log4j/2.x/security.html
MarkLogic Data Hub & Hub Central
The MarkLogic Data Hub & Hub Central are not affected directly by log4j vulnerability, Datahub and Hub Central used Spring boot and spring has an option to switch default logging to use log4j, which Data Hub does not.
MarkLogic Data Hub Service
For MarkLogic Data Hub Service customers, no action is needed at this time. All systems have been thoroughly scanned and patched with the recommended fixes wherever needed.
MarkLogic Content Pump (MLCP)
MLCP versions 10.0-1 through 10.0-8.2 and versions prior to 9.0-13.6 used an older version of log4j-1.2.17 that is not affected by the primary vulnerability discussed in this article (CVE-2021-44228), but mlcp versions prior to 10.0-8.2 are affected by the critical vulnerability CVE-2019-17571.
MLCP v10.0-8.2 & MLCP v9.0-13.7 specific workaround for CVE-2021-44832
The following workaround can be executed on a host with mlcp
1. Download and extract the Log4j 2.17.1 dependency from apache.
2. Move the relevant log4j dependencies to the
2. Remove the old log4j dependencies
The 1.0.0 Pega connector installer briefly runs MLCP 10.0-6.2 via gradle as part of the setup. MLCP 10.0-6.2 uses the old 1.2 log4j jar. The actual connector does not use log4j at runtime. We have released Pega Connector 1.0.1 which uses MLCP 10.0-8.2 with forced dependencies to log4j 2.17.1.
MarkLogic-supported client libraries, tools
All other MarkLogic-supported client libraries, tools, and products are not affected by this security vulnerability.
Verified Not Affected
The following MarkLogic Projects, Libraries and Tools have been verified by the MarkLogic Engineering team as not being affected by this vulnerability
MarkLogic Open Source and Community-owned projects
If you are using one of the MarkLogic open-source projects which have a direct or transient dependency on Log4j 2 up to version 2.14.1 please either upgrade the Log4j to version 2.16.0 or implement the workaround in prior releases (<2.16.0) by removing the JndiLookup class from the classpath. Please refer: https://logging.apache.org/log4j/2.x/security.html
Contact and Links
MarkLogic is dedicated to supporting our customers, partners, and developer community to ensure their safety. If you have a registered support account, feel free to contact firstname.lastname@example.org with any additional questions.
More information about the log4j vulnerability can be found at