How to Fix the Java Log4j Vulnerability

Understanding the Log4j Vulnerability

The Log4j vulnerability (CVE-2021-44228), also known as Log4Shell, is a critical security flaw that allows remote code execution (RCE) in Java-based applications. Attackers can exploit this vulnerability to take control of affected systems, making it one of the most severe security risks in recent years.

This guide will walk you through:

• How to detect if you're vulnerable
• How to patch and mitigate Log4j risks
• Best practices for long-term protection

What is the Vulnerability?

On December 10, 2021, news broke about a critical remote code execution (RCE) vulnerability in the Java library called Log4j, which is part of open-source code maintained by the Apache Software Foundation. It is widely used by enterprise software developers. That means a long list of big-name companies and software providers are affected, including Amazon Web Services (AWS), IBM, Oracle, Cisco, Apple, Minecraft, ConnectWise and many others.

Hackers immediately began scanning the Internet for vulnerable systems and launching hundreds of attempts per minute to exploit the vulnerability. On affected systems, hackers could gain the ability to remotely execute code and compromise or export sensitive data. You can read Apache’s advisory on the vulnerability here.

Step 1: Identify If Your System Is Vulnerable

To determine whether your applications are affected, follow these steps:

1. Check Your Log4j Version
   Run the following command to see if Log4j is installed and identify its version:

   find / -name "log4j-core-*.jar" 2>/dev/null

   Affected versions:
   - Log4j 2.0 to 2.14.1
   - Log4j 1.x may also have risks but requires different mitigation steps.

2. Use Security Scanners
   Several security tools can scan for Log4j vulnerabilities:
   - Log4j Detect (by CISA)
   - Qualys Log4j Scanner
   - Nessus and Rapid7 Scanners
3. Review Application Dependencies
   Many applications use Log4j indirectly via dependencies. Use tools like:
   - Dependency-Check
   - Syft (for containerized environments)
   - Maven or Gradle Dependency Tree

Step 2: Apply Log4j Patches  

Apache has released fixes for Log4j:

• Update to Log4j 2.17.1 (Latest stable version, recommended)
• For Java 6 & 7 Users: Use Log4j 2.3.2 or 2.12.4

How to update:

mvn dependency:purge-local-repository
mvn clean install -Dlog4j.version=2.17.1

Or manually replace Log4j JAR files in your application.

Step 3: Mitigation If You Can’t Patch Immediately

If updating is not feasible right away, apply these temporary fixes:

1. Remove the JndiLookup Class (for older versions)
   zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
2. Set System Properties to Disable JNDI Lookup
   For Java applications, add:
   -Dlog4j2.formatMsgNoLookups=true
   Or set the environment variable:
   export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Step 4: Strengthen Security Posture

To reduce future risks:

• Monitor logs for suspicious activity (/var/log/syslog, application.log)
• Use Web Application Firewalls (WAFs) to block malicious requests
• Enable Allowlisting to control JNDI behavior
• Conduct Regular Security Audits

The HBS incident response team is currently helping clients analyze and remediate their exposure to Log4j. For help with your specific situation, contact the HBS incident response team immediately via our website. This situation is continuing to evolve, and we’ll update this blog as new information becomes available. You also should regularly check CISA’s Apache Log4j Vulnerability Guidance for new information.