CVE-2025-68161: 
Apache Solr vulnerability analysis and mitigation

CVE-2025-68161 is a TLS hostname verification bypass vulnerability in the Socket Appender component of Apache Log4j Core. Affecting versions 2.0-beta9 through 2.25.2, the flaw causes the Socket Appender to skip hostname verification of peer TLS certificates even when the verifyHostName configuration attribute or log4j2.sslVerifyHostName system property is explicitly set to true. This enables man-in-the-middle (MitM) attacks against log traffic. The vulnerability was disclosed on December 18, 2025, and was discovered by Samuli Leinonen (oss-security). It carries a CVSS v3.1 base score of 4.8 (Medium) and a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory).

The root cause is classified under CWE-297 (Improper Validation of Certificate with Host Mismatch) and CWE-295 (Improper Certificate Validation). The bug resides in the SSLSocketManager class within log4j-core, where the hostname verification logic was not correctly implemented — the verifyHostName flag was accepted as configuration but never enforced during TLS handshake (GitHub PR #4002). Exploitation requires two preconditions: the attacker must be positioned to intercept or redirect network traffic between the Log4j client and the log receiver, and must possess a server certificate issued by a CA trusted by the Socket Appender's trust store (or the default Java trust store). The fix, merged December 15, 2025, corrects hostname verification in SslSocketManager and adds SNI hostname validation (GitHub PR #4002, oss-security).

A successful exploit allows an unauthenticated network-adjacent attacker to intercept or redirect log messages transmitted via the Socket Appender over TLS, compromising the confidentiality and integrity of log data. Sensitive information present in log streams — such as authentication tokens, session identifiers, application errors, or business data — could be exposed or tampered with. Availability is not directly impacted, but log integrity loss could hinder incident detection and response. The vulnerability affects a broad ecosystem of downstream products including IBM Db2, IBM App Connect Enterprise, IBM Cloud Pak for Business Automation, Oracle GoldenGate, Splunk AppDynamics agents, and SAP S/4HANA (IBM Advisory, Oracle CPU Jan 2026).

There is no evidence of active in-the-wild exploitation at this time, and no weaponized exploit kits have been identified. The Apache security page for CVE-2025-68161 serves as the primary public reference, and no standalone PoC exploit code has been published beyond the fix itself (Apache Security). The EPSS score is approximately 0.028% (0.000280), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by the requirement for network positioning and a valid CA-trusted certificate, making opportunistic mass exploitation unlikely.

1. Reconnaissance: Identify target applications using Apache Log4j Core versions 2.0-beta9 through 2.25.2 with the Socket Appender configured to send logs over TLS to a remote log receiver (e.g., a Syslog or custom TCP log server).
2. Network Positioning: Gain a man-in-the-middle position on the network path between the Log4j client and the log receiver — for example, via ARP spoofing, DNS poisoning, BGP hijacking, or rogue Wi-Fi access point on the same network segment.
3. Obtain a Trusted Certificate: Acquire or generate a TLS server certificate issued by a Certificate Authority (CA) that is trusted by the Socket Appender's configured trust store or the default Java trust store. This could be a certificate from a public CA (if the default Java trust store is used) or a certificate from an internal CA (if a custom trust store is configured).
4. Intercept TLS Handshake: Stand up a rogue TLS server (e.g., using openssl s_server or a custom proxy) that presents the trusted certificate. Because Log4j does not verify the hostname, the TLS handshake will succeed even though the certificate's CN/SAN does not match the intended log receiver's hostname.
5. Capture or Tamper with Log Traffic: Relay, record, or modify the intercepted log messages. Sensitive data in log streams (tokens, credentials, stack traces, business data) can be exfiltrated, or log entries can be injected/suppressed to cover attacker activity (oss-security, GitHub PR #4002).

• Network: Unexpected TLS connections to the log receiver originating from an IP address not matching the configured log server; duplicate TCP sessions to the log receiver port from different source IPs; unusual latency or packet loss on the log forwarding path suggesting traffic interception.
• Logs: Absence of expected log entries at the central log receiver despite the application appearing healthy; log entries arriving out of sequence or with unexpected content modifications; TLS handshake errors or certificate warnings in application logs if the rogue certificate is partially rejected.
• Configuration: Presence of verifyHostName=true in Log4j Socket Appender configuration combined with a Log4j Core version prior to 2.25.3, indicating the setting is silently ignored.
• Process/System: Unexpected ARP table changes or DNS resolution anomalies on hosts running Log4j-instrumented applications, which may indicate network-level MitM positioning.

Primary remediation: Upgrade Apache Log4j Core to version 2.25.3 or later, which correctly enforces TLS hostname verification in the Socket Appender (Apache Security, GitHub PR #4002).

Alternative workaround: Configure the Socket Appender to use a private or restricted trust root (custom trust store containing only the specific CA for your log receiver), which limits the set of certificates an attacker could present to impersonate the log server (oss-security).

Vendor patches: Multiple downstream vendors have released updates — Oracle addressed this in the January 2026 and April 2026 Critical Patch Updates (Oracle CPU Jan 2026, Oracle CPU Apr 2026); IBM has issued advisories for Db2, App Connect Enterprise, Cloud Pak for Business Automation, and other products (IBM Advisory); Splunk addressed it in AppDynamics agents in March 2026 (Splunk Advisory).

The vulnerability received moderate attention in the security community, largely due to the high-profile nature of the Log4j library following the Log4Shell incident. Security researchers on Mastodon and Bluesky noted the irony of a new Log4j TLS flaw given the library's history (infosec.exchange). Security news outlets including SecurityOnline, GBHackers, and CyberSecurityNews covered the disclosure, emphasizing that the flaw silently ignores a security configuration that administrators believe is active. The Apache project characterized the severity as "moderate" and released the fix promptly. HeroDevs published a blog noting that Log4j 2.17.x users on older branches remain affected and highlighted the availability of Never-Ending Support (NES) for those unable to upgrade (HeroDevs Blog).