The Apache Software Foundation has released a critical security update for its widely used Log4j logging library.
A newly discovered vulnerability, tracked as CVE-2025-68161, allows attackers to intercept or redirect sensitive log data by exploiting a flaw in how the software establishes secure connections.
The issue specifically affects the “Socket Appender” component in Apache Log4j Core. This component is responsible for sending log data over a network to a central server.
| Metric | Data |
|---|---|
| CVE ID | CVE-2025-68161 |
| Vulnerability Type | Missing TLS Hostname Verification |
| Affected Component | Apache Log4j Core |
| Affected Versions | 2.0-beta9 through 2.25.2 |
| Fixed Version | 2.25.3 |
| CVSS Score | 6.3 (Medium) |
Under normal circumstances, when a secure connection (TLS) is used, the software should verify that the server it is connecting to is the correct one by checking the server’s digital certificate’s hostname.
However, security researchers found that Log4j versions 2.0-beta9 through 2.25.2 fail to perform this hostname verification.
This failure occurs even if the administrator has explicitly turned on the verifyHostName setting or the system property log4j2.sslVerifyHostName. Essentially, the software ignores the instruction to double-check the server’s identity.
This oversight opens the door for “Man-in-the-Middle” (MitM) attacks. If an attacker can position themselves between the client application and the log server, they can intercept the traffic.
To succeed, the attacker simply needs a valid certificate issued by a trusted authority. Because Log4j does not verify that the certificate name matches the intended destination, it will mistakenly trust the attacker’s server and send log data to it.
The impact of this flaw is significant because application logs often contain highly sensitive technical details, debugging information, and, in some cases, user data.
If intercepted, this information could help hackers map out an internal network or identify other vulnerabilities to exploit.
The issue was discovered by security researcher Samuli Leinonen and reported through the Apache Log4j Bug Bounty Program.
In response, the Apache team has released Log4j Core version 2.25.3, which fully resolves the issue by enforcing proper hostname verification. Users are strongly advised to upgrade immediately.
If an immediate upgrade is not possible, administrators should restrict the “trust store” to contain only the specific certificates required for their communication, reducing the chance that an attacker’s certificate will be accepted.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.