Beyond Log4Shell: Two Overlooked Log4j Vulnerabilities That Still Linger

Red Dog Security

— 3 min read
Beyond Log4Shell: Two Overlooked Log4j Vulnerabilities That Still Linger

While the infamous Log4Shell (CVE-2021-44228) and its related flaws dominated headlines in December 2021, two other critical vulnerabilities—Denial-of-Service (DoS) and data leakage—remained largely overlooked. Officially acknowledged only in September 2022, these issues were quietly absorbed into the original set of CVEs, leaving them unpatched and underreported as distinct threats.

While the infamous Log4Shell (CVE-2021-44228) and its related flaws dominated headlines in December 2021, two other critical vulnerabilities—Denial-of-Service (DoS) and data leakage—remained largely overlooked. Officially acknowledged only in September 2022, these issues were quietly absorbed into the original set of CVEs, leaving them unpatched and underreported as distinct threats.

Log4j Vulnerabilities: A Recap of the CVEs

  • CVE-2021-44228 (Log4Shell, CVSS 10.0)
    Remote Code Execution (RCE) via JNDI lookup in logged data.
  • CVE-2021-45046 (CVSS 10.0)
    Exploits Context Lookup patterns (e.g., $${ctx:loginId}) to inject malicious JNDI payloads.
  • CVE-2021-44832 (CVSS 6.6)
    Allows attackers with configuration file write access to execute code via JDBC Appender.
  • CVE-2021-45105 (CVSS 5.9)
    Uncontrolled recursion in Context Lookup can trigger a StackOverflowError, crashing the application.

Patch Timeline Highlights

  • Initial patches for CVE-2021-44228 and 45046 were rapidly deployed, followed by Amazon Corretto’s hotpatch agent for live JVMs.
  • Later updates (v2.16+) disabled JNDI by default—but left other lookup methods active.

The Hidden Vulnerabilities

1. Denial-of-Service (Unpatched)

  • Root Cause:
    Recursive string interpolation (e.g., ${java:${lower:r}}) exhausts Java’s stack memory, crashing the JVM.
  • Example Exploit:

javaCopyEdit// Payload:
${${::-${::-$${::-j}}}

  • Key Details:
    This payload works even with default configurations, unlike CVE-2021-45105, which required custom patterns.
  • Impact:
    No user feedback is required—attackers can crash systems blindly.

2. Data Leakage (Unpatched)

  • Root Cause:
    Versions prior to 2.15 allow non-JNDI lookups (e.g., ${env:AWS_SECRET_ACCESS_KEY}) even after JNDI is disabled.
  • Exploitable Scenarios:
    • Log4j ≤ 2.14.1, or any version with JNDI manually removed.
    • Lookup patterns embedded in configuration files (e.g., PatternLayout).
  • Potentially Leaked Data:
    • Environment variables (${env:VAR})
    • System properties (${sys:user.dir})
    • Java runtime information (${java:version})

Vendor Response & Mitigation

Apache’s Position (as of Sept 2022):

  • Declared these issues as already covered under CVE-2021-44228 and CVE-2021-45046.
  • No new CVEs issued.
  • Removed guidance for removing JndiLookup.class, recommending full upgrades instead.

Current Fixes:

  • Log4j v2.16.0+ (Java 8+), v2.12.3+ (Java 7), v2.3.2+ (Java 6):
    Disable all lookups in log entries by default.
⚠️ Warning: Lookups still work in config files—restrict write access to these files immediately.

Actionable Recommendations

Upgrade Immediately
Use Log4j v2.16+ or backported versions for older Java environments.

Audit Configuration Files

  • Replace patterns like ${ctx:...} with %X or %mdc.
  • Block write access to all Log4j configuration files.

Monitor Logs for Lookup Patterns
Watch for suspicious entries such as ${date:...}, ${env:...}, especially in SaaS/cloud-hosted environments.

Legacy Systems

  • Hotpatch agents (e.g., Corretto) do not address these lookup-based issues.
  • If upgrades are impossible, manually disable lookups:

bashCopyEdit# Temporary fix—remove all Lookup classes:
zip -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/*Lookup.class

Conclusion

While Log4Shell’s RCE risk has been broadly mitigated, these quietly persistent flaws continue to pose real threats:

  • DoS via recursive lookups in unpatched systems.
  • Data exposure via environment and system variable lookups in configuration files.
Final Note: Apache no longer treats config-file lookups as vulnerabilities—but attackers haven’t stopped exploiting them.

Found this useful?
Share with your DevOps and AppSec teams—before the next blind attack hits.

Read more