New Vulnerability in Log4J - CVE-2021-44228

by Tiago Henriques.

Friday, a new critical vulnerability in a software library in Log4J was discovered. This logging library is used across many different Java-based platforms and powers different parts of the internet.

At Coalition, our mission is to solve cyber risk. We continuously scan the internet to identify infrastructure assets vulnerable to different cyber security risks. Since the Log4j vulnerability was released, we quickly implemented a detection capability for the new vulnerability. We have run the new scanner on all Coalition cyber security insurance Policyholders and Coalition Control users. Additionally, we will contact all entities using vulnerable versions of the Log4j library or software that relies on Log4j.

What is Log4J?

Log4J is an open-source logging framework that developers use to record actions and activities within their applications. It is used by platforms such as: Minecraft, VMWare, Elasticsearch, Apple, Cloudflare, Amazon Web Services, and Tesla, along with various Apache platforms such as Struts, Druid, ActiveMQ, Flume, Hadoop and Kafka, among many others.

What does this mean for me?

Don't panic. If you are a Coalition policyholder, log into your Coalition Control account and check for a notification for you to remediate issues. Additionally, we are publishing and regularly updating the next section with platforms that are vulnerable to CVE-2021-44228.

Check whether you are running any of the vulnerable software internally in your network as Coalition Control only has visibility to assets exposed to the internet. After you have your list of assets, it is time to mitigate the issue.

Mitigation techniques

The following is a list of Log4J mitigations. The preferred method will offer maximum protection.


Update to Log4J 2.16.0

This completely removes the affected JNDI component. As a result, this mitigation provides maximum protection against Log4J attacks.

Acceptable, but not preferred

Update to Log4J 2.15.0.

This release disabled the JNDI component by default. This means that the vector could be re-enabled at a later date. This mitigation option provides less protection and does allow for  the component to be re-enabled. There is a chance that future software vulnerabilities could enable a vector to re-enable this component.

Temporary only

Taken from the Log4J Bulletin:

Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all patternlayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. for releases>=2.0-beta9 and <=2.10.0, the mitigation is to remove jndilookup class from classpath: zip -q -d log4j-core-*.jar org apache logging log4j core lookup jndilookup.class.< i>

This method should only be used if none of the above mitigation methods are available to you. In some cases it is possible to remove the mitigations by restarting the affected software or operating system. Please consider this a temporary measure while working toward an upgrade to 2.16.0 of Log4j.

If you have a WAF in front of your web applications, make sure to deploy rules for filtering. Services like Cloudflare and AWS, and Google CloudArmor already have available pre-built rules. These won't stop every attack but will still be useful against more basic attacks.

Vulnerable Platforms

This section contains a list of platforms Coalition has identified as potentially vulnerable to CVE-2021-44228. For your major vendors not on this list, you should contact them and ask them the following questions:

  • Do you use any software that relies on Log4J ?
  • Have you executed any mitigations for CVE-2021-44228 ?
  • Did you do any investigation to confirm you have not been a victim to exploitation of CVE-2021-44228 ?

Known vulnerable platforms:

  • Okta RADIUS Server Agent, Okta On-Prem MFA Agent
  • Apache Struts, Solr, Druid, ActiveMQ, Flume, Hadoop, Kafka,Dubbo,Flink,Spark, Tapestry, Wicket
  • Redhat OpenShift Container Platform 4, OpenShift Container Platform 3.11, OpenStack Platform 13 (Queens), OpenShift Logging.
  • Grails
  • Ghidra
  • Minecraft
  • VMWare Horizon, VCenter, HCX, NSX-T Data Center, Unified Access Gateway, WorkspaceOne Access, Identify Manager, VRealize Operations, VRealize Operations cloud proxy, VRealize log insight, VRealize Automation, VRealize Lifecycle Manager, Telco Cloud Automation, Site Recovery Manager, Caron Black Cloud Workload Appliance, Carbon Black EDR Server, Tanzu GemFire, Tanzu Greenplum, Tanzu Operations Manager, Tanzu Application Service for VMs, Tanzu Kubernetes Grid Integrated Edition, Tanzu Observability by Wavefront Nozzle, Healthwatch for Tanzu Application service, Spring Cloud Services for Vmware Tanzu,Spring Cloud Gateway for Vmware Tanzu, Spring Cloud Gateway for Kubernetes, API Portal for VMWare Tanzu, Single Sign-on for VMWare Tanzu Application Service, App Metrics, Vmware vCenter Cloud Gateway, VMWare Tanzu SQL with MySQL for VMs, Vrealize Orchestrator

Potentially vulnerable — can use log4j or embeds log4j

  • Apache Tomcat
  • Dropwizard
  • Elastic Kibana
  • Hibernate
  • JavaServer Faces
  • Oracle ATG Web Commerce
  • Spring Framework

A more extensive list being updated by the cybersecurity community and twitter user @SwitHak which can be found here.


Indicators of compromise (IOCs) are a list of signals we've been detecting that can be used to discover if your organization has already been attacked or compromised by this vulnerability. If you have logs, you can search for these strings to help discover if you've been compromised: