Skip to main content
Older versions of Internet Explorer will not support certain site features. Chrome, Safari, Firefox, and Edge will provide the best experience.

Information on Log4J vulnerability and the Smart Suite environment


The following contains questions regarding the Apache Log4J vulnerability - CVE-2021-44228 as it relates to the Smart Suite environment.  Please contact Spok Support for any additional questions your organization may have.

Q:  What version of Log4j is Smart Suite 7.2-1 using?

A: The 7.2-1 release updates Log4j 1.2.16 and 1.2.17 to Log4j 2.17.1. This upgrade is limited to Spok-owned code and is enabled via a short-term solution provided by Apache called the Log4j 1.2 Bridge.


Q:  What version of Log4j is Smart Suite 7.1 using? 

A:  Smart Suite 7.1 is using Log4j 1.2.16 and 1.2.17 

Q:  What version of Log4j is Smart Suite 5.x using? 

A:  Smart Suite 5.x (currently end of life) is using Log4j 1.2.x 

Q:  Will Spok provide mitigation for Smart Suite 5.x?

A:  No.  Spok strongly encourages customers to upgrade to the latest supported version of Smart Suite.  Please speak to your Spok Sales Representative to discuss options.  Smart Suite 5.x has been end of life since November 2020 (see Product Lifecycle Dates).  Spok no longer provides updates to End of Life software, please review the Spok Lifecycle Policy document for more information.

Q:  Is that Log4j version impacted by CVE-2021-44228? 

A:  No, CVE-2021-44228 only impacts Log4j version 2.x. 

Q:  We have found some 2.x Log4j jar files in our Oracle Patching directories, does this mean we are at risk? 

A:  No, these files are staging files delivered as part of normal Oracle Patching.  Because Smart Suite does not use this version of Log4j, they are not utilized in your environment. 

Q:  Can I remove these 2.x Log4j files from my Smart Suite system? 

A:  No.  Spok has published an updated Q4 ’21 Oracle quarterly patch update for Smart Suite 7.1 to remove files associated with 2.x Log4j versions from the Database & WebLogic staging directories. Please reach out to Spok Support to have it applied. Any 2.x Log4j files that exist in directories not managed by Spok are not in scope of this patch and will need to be reviewed by the customer on an individual basis.  

Q:  I applied the updated Q4 ’21 Oracle quarterly patch. Can I re-run my scan now?

A:  Yes. Oracle recommends that security scanners are updated to specifically review the Manifest.MF file to detect the third-party version for CVE mapping (Oracle Support Doc ID 2827793.1)

Q: I already updated to the Q4 ’21 Oracle Quarterly patch. Will the fixes be incorporated into the Q1 ’22 patches when they become available?

A:  Yes, Spok will include the solution to remove files associated with 2.x Log4j versions from the Database & WebLogic staging directories in the Q1 ’22 Oracle Quarterly Patch. This patch is planned to be released in February ’22.

Q:  Can I simply update Log4j to the latest on my Smart Suite Servers? 

A:  No.  Log4j is delivered as part of the Smart Suite solution and will need to be updated as part of an upcoming release (see next question). 

Q:  What is Spok’s plan to move to the latest patched version of Log4j? 

A:  Spok is working on a plan to remove older versions of Log4j in order to utilize a supported Log4j version in an upcoming release of Smart Suite, with the goal of making it available to customers targeting late Q2/early Q3 of 2022*.   Security scans will show log4j 1.x versions until this time.

Q:  Is Spok at risk of the following Log4J version 1.x vulnerabilities: CVE-2022-23302, CVE-2022-23305, CVE-2022-23307, CVE-2019-17571, CVE-2020-9488, CVE-2021-4104?

A:  No, Spok has confirmed that Smart Suite does not enable any of the components that would need to be utilized for these vulnerabilities to be applicable:  JMSSink, JDBCAppender, Apache Chainsaw.

*Available timelines of any product may change but Spok will keep our customers apprised as availability dates become more defined.

For the most up-to-date information regarding Spok's response to the Log4J vulnerability, visit