12 Cybersecurity Vendors Susceptible To The Log4j Vulnerability

Vulnerable Log4j code can be found in products from prominent identity vendors like CyberArk, ForgeRock, Okta and Ping Identity, as well as SMB-focused security companies like Fortinet, SonicWall, and Sophos.

Caught In The Crosshairs

The critical vulnerability disclosed last week in Java logging package Log4j left cybersecurity vendors scrambling to assess their potential exposure. Vulnerable code can be found in products from prominent identity and access management vendors like CyberArk, ForgeRock, Okta and Ping Identity, as well as security firms who serve the SMB community through the channel like Fortinet, SonicWall, and Sophos.

“We have been continuously monitoring for Log4Shell [formal name for the Log4j vulnerability] exploit attempts in our environment and have been urgently investigating the implications for our corporate and production systems,” Rapid7 wrote in a blog post Tuesday. “Log4Shell has kept the security community extremely busy for the past several days, and we are no exception.”

Cybersecurity companies with affected versions of Log4j code have been hard at work since Friday developing workarounds, patches and updated versions of their products that eliminate the risk of exploitation. But permanent or even temporary fixes still remain elusive for many of the vulnerable products.


Broadcom determined as of Tuesday that some or all versions of its CA Advanced Authentication, Symantec PAM Server Control, Symantec SiteMinder, and VIP Authentication Hub products are affected by the Log4j vulnerability. The company said its Symantec Endpoint Protection Manager offering may be affected, while exposure in the Symantec Web Security Service reporting feature has been remediated.

SiteMinder customers are urged to either configure the offering to continue using the existing Log4j versions in a secure manner or upgrade the existing Log4j version in their environment to Log4j 2.15.0. Upgrading to 2.15.0 will help reduce the likelihood of vulnerability scanning tools continuing to identify the older Log4j instances.

Symantec PAM Server Control customers are directed to stop the WildflyService, make changes to the <WILDFLY_INSTALL_DIRECTORY> and restart the service. Impact to the remaining products can be addressed by setting the system environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” to ”true” and restarting the impacted components or services, according to Broadcom.


CyberArk’s Privileged Threat Analytics (PTA) and Remote Access (Alero) Connector are both susceptible to the Log4j vulnerability and require customers to take action to stay safe. The Newton, Mass.-based privileged access management vendor directs customers to pursue an available workaround for the PTA offering and implement an available fix for the Remote Access Connector.

The company was able to apply mitigations to SaaS-based versions of its Privilege Cloud and Remote Access (Alero) offerings as well as its Secure Web Sessions (SWS) version of the Identity offering, all of which were exposed to the Log4j vulnerability. Due to the publication of exploit code on various sites, CyberArk strongly recommends that customers apply the provided updates as soon as possible.


ForgeRock said its Autonomous Identity analytics offering utilizes Log4j, and the company said it is actively working on a patched version for this product and will share more information when available. The San Francisco-based identity provider said RSA’s SecurID authentication module also uses the Log4j library and directed users to not use the module until RSA provides a fixed version of this library.

ForgeRock said customers are responsible for checking for any use of Log4j in their servlet container and any custom code (including Marketplace contributions) that they have deployed. The company also directed customers to follow the advice from Apache by upgrading their Log4j version to 2.15.0 or by implementing one of their mitigations.


Twelve Fortinet products are affected by the Log4j vulnerability, meaning that attackers who control log messages or log message parameters can execute arbitrary code. Fixed were made Friday for three of the susceptible products – FortiCASB, FortiConverter Portal, and FortiCWP.

Fortinet said FortiEDR Cloud is no longer exploitable given the precautionary measures put in place Friday, while additional precautionary mitigations being investigated for FortiInsight and FortiMonitor even though both products were determined to be not exploitable. The Sunnyvale, Calif.-based vendor said a fix is scheduled for version 2.3.4 of FortiIsolator remote browser isolation product.

No remediation information has been provided for the other five impacted tools: FortiAIOps, FortiPortal, FortiPolicy, FortiSIEM, and ShieldX.


F-Secure has found that its Policy Manager, Policy Manager Proxy, Endpoint Proxy, Elements Connector, and Messaging Security Gateway are affected by the Log4j vulnerability. Only the Policy Manager Server component is susceptible to the Log4j exploit, with standalone installations of Policy Manager Console not impacted, according to Helsinki, Finland-based F-Secure.

In most cases, F-Secure said it has automatically patched the Messaging Security Gateway vulnerability. However, some customers may have set the system so that they apply the patches manually. In this case, F-Secure said the administrator will receive an email informing them of the patch availability, and they should immediately apply the patches.

For the remaining products, F-Secure said it has created a security patch that users need to deploy themselves, and both Windows and Linux versions of the products should be considered impacted. This patch needs to be reapplied after new installations or upgrades until fixed installers become available.


Certain versions of Okta’s RADIUS Server Agent and On-Prem MFA Agent are susceptible to the Log4j vulnerability, meaning that an attacker with control over log messages or log message parameters could execute arbitrary code. Customers are urged to upgrade to Okta RADIUS Server Agent version 2.17.0 or Okta On-Prem MFA Agent version 1.4.6, where the vulnerability has been fixed.

“As soon as Okta learned of this vulnerability, we promptly evaluated all cloud-hosted systems and customer premise agents to determine what might be impacted and methodically set about remediating any exposure,” Okta Chief Security Officer David Bradbury wrote in a blog post Saturday.

Ping Identity

All versions of Ping Identity’s PingFederate, PingAccess and PingCentral are potentially vulnerable since the products – along with PingIntelligence - use the Apache Log4j2 component for logging. The Denver-based company said maintenance releases that permanently resolve the issue will be made available as soon as possible, with Ping Identity recommending a series of mitigation steps in the interim.

Users of certain versions of PingFederate and PingAccess are directed to download a zip file, apply an update to their systems, and conduct a service restart after applying the update. PingCentral customers have been instructed to modify the Log4j2.xml configuration file on each server individually, while PingIntelligence customers should append the Dashboard and WebGUI configuration files and restart.

Versions of PingFederate prior to 8.0 use Log4j version 1, which is not affected by this vulnerability, while versions of PingAccess prior to 4.0 use a logging platform unrelated to Log4j, according to the company.


Rapid7 customers using on-premises versions of certain products must take action to fully remediate the Log4j vulnerability in their environments. The Boston-based company strongly urge all customers using vulnerable versions of these products and product components to apply updates immediately since this vulnerability is being actively exploited and could result in highly impactful remote code execution.

The vulnerability impacts all versions of Rapid7’s Logentries logging library as well as certain versions of the company’s InsightOps logging library, InsightOps Data Hub, and Logentries Data Hub in both Linux and Windows. On-premises customers are directed to upgrade or migrate to a version of the product or a new product that isn’t susceptible to the log4j vulnerability.

Rapid7 said it prioritized remediation efforts on the Insight Platform and other hosted web application products such as Logentries. The company said it has remediated the Log4j vulnerability in its deployed application services’ code, meaning that customers of Rapid7’s hosted web solutions do not need to take any action.

RSA Security

RSA Security’s SecurID Authentication Manager 8.6 Patch 1, Archer Security Operations Management (SecOps) Solution, and Elasticsearch join-search plugin are all affected by the Log4j vulnerability. Specifically, RSA said SecurID Authentication Manager 8.6 Patch 1 include a third-party update which contains an embedded version of Log4j that is vulnerable to this attack.

However, this component does not support JNDI lookup of messages or message parameters, plus the JRE used in Authentication Manager 8.6 Patch 1 has mitigations against a Log4j attack. Since this patch contains several other critical security updates, it will remain available for download while RSA determines the suitability of mitigations recommended by the open-source maintainers at Apache.

With Archer SecOps, adversaries would need to deliver the exploit payload via an alert from a SIEM tool, and RSA said clients should block outbound internet access where UCF is hosted. Meanwhile, RSA said Log4j2 is present on the servers as part of the Elasticsearch join-search plugin but poses no risk as it can’t be executed from there. Clients should block outbound internet access from their Elasticsearch cluster.


SonicWall determined Sunday after review that version 10.x of its Email Security appliances appears to be impacted by the Log4j vulnerability. The Milpitas, Calif.-based platform security vendor said is working on a HotFix to remediate the issue, which SonicWall said will be released shortly.

Although Log4j is part of other SonicWall products such as the Secure Mobile Access (SMA) 1000 series and the WAN Acceleration (WXA) offering, neither had has vulnerable versions of the code in place. Four others SonicWall products – NSM, Analyzer, Analytics, and GMS – remain under review for exposure to Log4j.


The Sophos Mobile EAS Proxy is affected by the Log4j vulnerability. The Oxford, U.K.-based platform security vendor said customers need to download and install version 9.7.2 on the same machine where the proxy is currently running. The Standalone EAS Proxy Installer version 9.7.2 was made available Monday on the Sophos website.

Updated were deployed Friday morning to Sophos Cloud Optiv to patch a Log4j vulnerability in the product. Sophos said it performed host forensics and log analysis in the Cloud Optix environment and determined that the vulnerability was not successfully exploited prior to fixes being deployed.

Similarly, a Log4j vulnerability in Sophos Email has been patched, and the company has determined that the vulnerability was not successfully exploited prior to fixes being deployed based on host forensics and log analysis. Although other products such as Sophos Central, Sophos Mobile and Reflexion use Log4j, they weren’t impacted by the vulnerability since those tools aren’t running an exploitable configuration.

VMware Carbon Black

While the Carbon Black suite of endpoint products do not directly use the Log4j library and have its vulnerabilities, the VMware subsidiary said there are portions of the version 1 of VMware Carbon Black Cloud Workload Appliance and version 7.6 of the VMware Carbon Black EDR Server that are impacted and may require attention.

The VMware Carbon Black Cloud Workload appliance 1.1.1 security patch released Tuesday addresses the Log4j vulnerability, and customers must ensure the appliance root password is not expired to do the upgrade. A patch has also been released for the VMware Carbon Black EDR Server following temporary workarounds for each.