Log4j Vulnerability - CVE-2021-44228

The purpose of this page is to provide accurate information to VersaFile clients on the impact and updates of the log4j vulnerability on Business partner applications and VersaFile products.

Note: We will continue to update this webpage as we have further information and tips.

IBM Components:

  1. IBM WebSphere Application Server (WAS) – Vulnerability Identified
    1. Interim Fix (IF) released PH42762
  2. IBM WebSphere Liberty
    1. Not affected except ​​​​​​for WebSphere Application Server Liberty – using the zosConnect-1.0 or zosConnect-1.2 feature: Interim Fix (IF) released PH42762
  3. IBM Content Collector (ICC) for Files – Vulnerability Identified
    1. Update to 4.0.1 FP 13​​​​​​​
    2. Reference: Vulnerability in Apache Log4j affects Content Collector for File Systems
  4. IBM Content Collector for SAP (ICC4SAP)
    1. ​​​​​​​ICC4SAP is not affected 
    2. Reference: Content Collector for SAP Applications is not affected by, or vulnerable to CVE-2021-44228.
  5. FileNet Content Platform Engine (CPE) / Content Search Services (CSS)​​​​​​​
    1. ​​​​​​​​​​​​​​From IBM: The IBM FileNet Content Manager Content Process Engine (CPE) does not now, and never has, included any version of log4j 2.x. Therefore CPE is not vulnerable to the Log4Shell CVE. CPE did use Log4j version 1 in older releases (5.5.5 and earlier). In these older versions CPE uses log4j 1.2.17 for logging. This 1.2.17 version of log4j continues to be distributed with CPE due to 3rd party dependencies, however this version of log4j is not vulnerable to the Log4Shell exploit. Use of log4j was stopped in version 5.5.6 of CPE. The log4j logging mechanism is replaced by the JAVA utility logging (JUL) in 5.5.6 and later.
  6. Watson Explorer (WEx)
    1. Security Bulletin: Vulnerability exists in Watson Explorer (CVE-2021-44228)
    2. Ticket open with IBM. Information pending
  7. IBM Content Navigator (ICN)
    1. on-prem: Deployment packages log4j release 1.x for IBM Content Manager usage, which is not susceptible to the vulnerability detailed in CVE-2021-44228. 
    2. container: V3.0.9 and V3.0.10 deployment packages log4j 2.x for CMOD configuration only and is impacted by CVE-2021-44228.  An upgrade of IBM Content Navigator Standalone Container or Business Automation Navigator to the following build levels will fully mitigate the vulnerability:  ICN – ga-309-icn-la008, ga-3010-icn-la004  / BAN – V21.0.2 IFix6 /
    3. Task Manager – 3010 TM LA004, 309 TM LA008, 307 TM LA101. Task Manager container 3.0.7 build (Not ICN Standalone container build). They are separate deployments. If you have deployed TM container then you will need to upgrade as specified in the technote. – Vulnerability Identified on specific versions
    4. Reference: What is the impact of CVE-2021-44228 on my IBM Content Navigator deployment?
    5. Official Release: ICN Container is vulnerable to log4j for specific versions
  8. IBM Enterprise Records (IER)  Vulnerability Identified on specific versions​​​​​​​
    1. Upgrade to v5.2.1.6
    2. Enterprise Records is not affected by, or vulnerable to CVE-2021-44228 because the software does not use Log4j version 2.x.​​​​​​​
      1. Official Statement: IER is not affected
  9. Content Management Interoperability Services (CMIS)
    1. ​​​​​​​From IBM: In IBM Content Management Interoperability Services (IBM CMIS) 3.0.6 onwards, log4j file is not used.  Therefore, IBM CMIS is not vulnerable to this vulnerability. CMIS is not impacted by CVE-2021-44228
  10. IBM Content Manager (CM8)
    1. IBM Content Manager (CM 8) only uses log4j 1.x, so the vulnerability does not apply. https://www.ibm.com/support/pages/node/6525854
  11. IBM Case Manager (ICM)
    1. IBM Case Manager is not affected or vulnerable to CVE-2021-44228.
    2. Reference: Is IBM Case Manager affected by or vulnerable to CVE-2021-44228?
  12. IBM Business Automation Workflow (BAW)
    1. Please see the notes below on the known Business Automation Workflow, IBM Integration Designer, IBM Process Designer components impacted by CVE-2021-44228:
      1. Process Federation Server fix for this vulnerability will be shipped in JR64456
      2. The vulnerability fix for Business Automation Workflow on containers is in progress. Further update will be added to this document.
      3. CVE-2021-44228  describes a vulnerability in the Apache Log4j 2.X Java library dubbed Log4Shell. Some Business Automation Workflow on premise components use log4j 1.X. There is only one application that uses Log4j 2.X. This application [IBM_BPM_KC_CI_] is used to access IBM Documentation offline and is impacted by CVE-2021-4428. The following steps can remediate the impact:
        1. install APAR JR64096. 
          1. * If the APAR is not available for your Business Automation Workflow fix level, go to step B)
          2. The application  [IBM_BPM_KC_CI_] will be removed from current and new deployment environment.
        2. manually uninstall the application [IBM_BPM_KC_CI_]
          1. * Complete this step if JR64096 is not available for your Business Automation Workflow environment
          2. * Complete this step if  [IBM_BPM_KC_CI_] is still running with JR64096 installed
          3. From WebSphere Application Server admin console, select
            1. Applications > Application Types > WebSphere enterprise application
            2. and locate the application IBM_BPM_KC_CI_ to apply uninstall action
            3. After this change, stop the whole deployment environment then restart the deployment environment
      4. Business Automation Workflow custom applications
        1. IBM Business Automation Workflow allows building and running custom applications on the platform. Each of these applications may bring its own vulnerable version of log4j-core-2.x with it and use it. Customers must review all their applications log4j usage
        2. For Business Automation Workflow Advanced type of applications created with IBM Integration Designer,  the app is available in the file system of the runtime server in the installedApps directory and can be reviewed there
        3. For Business Automation Workflow Standard applications created using Process Designer, the development tool can be used for review
      5. For WebSphere Application Server, see Security Bulletin: Vulnerability in Apache Log4j affects WebSphere Application Server (CVE-2021-44228) and Advice on responding to CVE-2021-44228 for additional information
    2. Reference: Is Business Automation Workflow affected by CVE-2021-44228?
    3. Ticket open with IBM. Information pending
  13. Content Manager OnDemand (CMOD) – Vulnerability Identified on specific versions and components
    1. IBM Content Manager OnDemand (CMOD) Versions,,, and use log4j 2.13.0 and therefore are impacted. In Content Manager OnDemand Version 10.5, the following components use log4j 2.x:  Full Text Search Exporter, Content Manager OnDemand REST Services and the Content Manager OnDemand Web Enablement Kit. There are three options to remove the Apache log4j <=2.14.1 vulnerability.​​​​​​​ https://www.ibm.com/support/pages/node/6525888
  14. ​​​​​​​IBM Enterprise Content Management System Monitor (ESM) – Vulnerability Identified
    1. ​​​​​​​ESM is also impacted by the security vulnerabilities related to Log4j (CVE-2021-442228)
    2. To mitigate these vulnerabilities, the following actions have to be taken on the ESM server and each ESM agent:
      1. ​​​​​​​stop the ESM server or agent process/service
      2. at the end of the file “/karaf/etc/system.properties” add the following line:
        1. ​​​​​​​log4j2.formatMsgNoLookups=true
        2. This is a single line of text without any indentation. The line is followed by a line break
      3. save the changes
      4. start the ESM server or agent again
    3. For container environments we recommend a different approach, as the changes described above would not be persistent in case of a new container deployment. In container deployments, the environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” should be set to “true”. This has to be added to the start-up-call of the container as “-e LOG4J_FORMAT_MSG_NO_LOOKUPS=true”.
    4. In InstallAnywhere installations the environment variable can also be set for the environment of the account the ESM process is running under. On Unix/Linux be sure the variable is exported. This is an alternative for editing the system.properties file.
  15. Datacap
    1. ​​​​​​​​​​​​​​Ticket open with IBM. Information pending
      1. ​​​​​​​IBM support updated that Datacap does not use Log4j. The engineering team is working on the official statement
    2. Official statement: Datacap is not vulnerable

Pending information for:

  1. SQL


Additional Information:

​​​​​​​IBM Communication on log4j CVE: An update on the Apache Log4j CVE-2021-44228 vulnerability – IBM PSIRT Blog

VersaFile Products:


TRex core product does not use log4j.

However, there are three current connectors that include log4j as API dependencies.

  • IBM FileNet P8 CE Connector (l4j version 1.2.17)
  • IBM FileNet P8 PE Connector (l4j version 1.2.17)
  • Apache Tika Connector (l4j version 1.2.17)

While we are awaiting updates from the vendors of the affected products, the attack vectors on the log4j can be minimized by implementing firewall rules to only allow connections from trusted servers/clients.

IBMs Response for the FileNet P8 API issue:

CPE did use Log4j version 1 in older releases (5.5.5 and earlier). In these older versions CPE uses log4j 1.2.17 for logging. This 1.2.17 version of log4j continues to be distributed with CPE due to 3rd party dependencies, however this version of log4j is not vulnerable to the Log4Shell exploit.


docuflow uses log4j internally for log generation and we are currently regression testing with the latest log4j update that was released.

docuflow does implement IBM FileNet P8 CE API (l4j 1.2.17) for connections to FileNet systems. As IBM releases fixes we will apply the updates to the FileNet middle ware connection code.

It is highly recommended that customers ensure firewall rules only allow inbound connections from trusted servers. Typically these would only include connections from the SAP environments and any servers required for integration calls to the middleware. This will mitigate external attack vectors and is a standard best practice.

We have fully tested and communicated the “log4j patching” steps to all our customer’s versions of docuflow with log4j 2.16.0


Intellego ConnectX, For Invoices and Financials is built on .NET and the vulnerability wouldn’t be applicable here. Log4j is only relevant for java projects; there is a similar logging framework in .NET (log4net) but it does not have the same vulnerability.

Intellego ConnectX is a Java release, and uses Log4J Version 1.2.9 and is not vulnerable to to CVE-2021-44228, a subsequent notice was announced under CVE-2021-4104 (which is similar to CVE-2021-44228) but is more difficult to exploit. This only applies to configurations using JMSAppender and is controlled by settings in the log4j.properties.  Intellego does not ship with the log4j.propertie  This means the customer will only be vulnerable if they enable JMSAppender intentionally.  It is advised to check your environments and avoid using JMSAppender in this case.

Log4j Vulnerability

Subscribe for updates.

Receive alerts, tips, and other updates directly to your email.

Other Resources:

IBM id Sign-in Template refresh

Collector for SAP Applications (ICCSAP) affected by, or vulnerable to CVE-2021-44228?
Log4j is used by IBM Watson Explorer to log system events for diagnostics.

Manager (CM 8) impacted by the log4J security vulnerabilities related to CVE-2021-44228?

Manager OnDemand (CMOD) Version 10.5 impacted by the log4j security vulnerabilities related to CVE-2021-44228?

This Post Has 2 Comments

  1. Greg C

    Please confirm that all prior versions of Intellego also built on .NET.

    1. Chris Lehner

      Hi Greg,

      Thanks for reaching out to us.

      There are older versions of Intellego that run on Java. It uses log4j.1.2.9.jar

      We do not provide the log4j.properties along with the software, however if a customer intentionally set the appender to use JMSAppender in their log4j configuration, then they will be vulnerable. If just FileAppender is used, then they are not affected.

      Hope this was helpful,

Comments are closed.