CVE-2025-68161

4.8 MEDIUM

📋 TL;DR

This vulnerability in Apache Log4j Core allows man-in-the-middle attackers to intercept or redirect encrypted log traffic when TLS hostname verification fails, even when configured to verify. It affects systems using Log4j's Socket Appender with TLS connections.

💻 Affected Systems

Products:
  • Apache Log4j Core
Versions: 2.0-beta9 through 2.25.2
Operating Systems: All operating systems running Java
Default Config Vulnerable: ✅ No
Notes: Only affects systems using Socket Appender with TLS connections. The verifyHostName configuration must be set to true for the vulnerability to be relevant.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Sensitive log data containing credentials, PII, or system information is intercepted by attackers, leading to data breaches or further system compromise.

🟠

Likely Case

Log data interception allowing attackers to gather intelligence about system operations, user activities, or application behavior.

🟢

If Mitigated

Minimal impact with proper network segmentation and certificate pinning, though risk remains if traffic can be intercepted.

🌐 Internet-Facing: MEDIUM - Requires both traffic interception capability and trusted certificate presentation, but internet-facing systems are more exposed to interception attempts.
🏢 Internal Only: LOW - Internal networks typically have better segmentation and monitoring, making interception more difficult but still possible with insider threats.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ✅ No
Complexity: MEDIUM

Exploitation requires both network interception capability and ability to present a trusted certificate, making it more complex than simple remote exploits.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 2.25.3

Vendor Advisory: https://lists.apache.org/thread/xr33kyxq3sl67lwb61ggvm1fzc8k7dvx

Restart Required: Yes

Instructions:

1. Download Log4j Core 2.25.3 from Apache repository. 2. Replace existing Log4j Core JAR files with new version. 3. Restart all applications using Log4j. 4. Verify configuration still works correctly.

🔧 Temporary Workarounds

Restrict Trust Store

all

Configure Socket Appender to use a private or restricted trust root to limit trusted certificates

Configure log4j2.xml with custom trustStore and trustStorePassword parameters

🧯 If You Can't Patch

  • Implement network segmentation to isolate log traffic from potential interception points
  • Use certificate pinning or implement additional encryption layer for log transport

🔍 How to Verify

Check if Vulnerable:

Check Log4j version in application classpath: java -cp "log4j-core-*.jar" org.apache.logging.log4j.core.Version

Check Version:

java -cp "log4j-core-*.jar" org.apache.logging.log4j.core.Version

Verify Fix Applied:

Verify version shows 2.25.3 or higher and test TLS connections with invalid hostnames to confirm rejection

📡 Detection & Monitoring

Log Indicators:

  • Unexpected certificate validation failures
  • Log traffic interruptions
  • Connection resets during TLS handshake

Network Indicators:

  • Unusual outbound connections from logging systems
  • TLS handshakes with unexpected certificates

SIEM Query:

source="log4j" AND (event="TLS_ERROR" OR event="CERTIFICATE_VALIDATION")

🔗 References

📤 Share & Export