Log4j’s “Silent” Security Gap: New Advisories Warn of Data Loss and TLS Bypasses

The Apache Log4j 2 ecosystem is facing a fresh wave of security concerns as four new vulnerabilities have been disclosed, highlighting critical flaws in how the library handles data sanitization and internal configuration. These vulnerabilities, primarily categorized as “silent” failures, can lead to unrecorded security events, log injection, and even the complete bypass of encrypted connection safeguards.

Security administrators are urged to review their configurations as the Apache Software Foundation releases Log4j Core 2.25.4 to address these risks.

The XML Sanitization Trap (CVE-2026-34480 & CVE-2026-34479)

A significant portion of the new advisories focuses on XmlLayout, a component used to format log events into XML. In versions up to and including 2.25.3, the layout “fails to sanitize characters forbidden by the XML 1.0 specification… producing invalid XML output”.

The danger of this vulnerability lies in its “silent” nature. Depending on the underlying implementation, the results can be catastrophic for log integrity:

• Built-in JRE StAX: Forbidden characters are written without warning, creating malformed documents that downstream log-processing systems may simply drop.
• Alternative Implementations (e.g., Woodstox): An exception is thrown during the logging call itself, ensuring “the log event is never delivered to its intended appender”.

This issue is mirrored in CVE-2026-34479, which affects the Log4j 1-to-Log4j 2 bridge, potentially causing similar event loss for organizations still transitioning from legacy systems.

The Syslog Configuration Blind Spot (CVE-2026-34478)

The discovery of CVE-2026-34478 highlights a different kind of silent failure: a vulnerability to log injection through CRLF sequences in the Rfc5424Layout. This flaw was introduced by undocumented renames of critical security attributes in versions 2.21.0 through 2.25.3.Administrators who believed they were using secure settings were caught in two distinct traps:

• Broken Newlines: The newLineEscape attribute was silently renamed, causing newline escaping to stop functioning for TCP-framed logs.
• Encryption Downgrade: The useTisMessageFormat attribute was also renamed, which resulted in TLS-framed connections being “silently downgraded to unframed TCP (RFC 6587), without newline escaping”.

The TLS Hostname Bypass (CVE-2026-34477)

Rounding out the advisories is CVE-2026-34477, a flaw involving hostname verification in TLS configurations. Researchers found that the verifyHostName attribute was “silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value”.

This means that even if an administrator explicitly enabled hostname verification, a network-based attacker could perform a man-in-the-middle attack. This flaw specifically impacts users of SMTP, Socket, or Syslog appenders where TLS is configured via a nested <Ssl> element.

Remediation and Action Plan

The common thread across these advisories is the failure of the system to warn the user when security-critical functions fail or are ignored. To secure your logging infrastructure, the following steps are recommended:

• Upgrade Immediately: Move all log4j-core and log4j-1.2-api dependencies to version 2.25.4.
• Audit Syslog Layouts: If you use Rfc5424Layout with TCP or TLS, verify that your configuration attributes match the new documented names post-upgrade.
• Migrate from the Bridge: As the Log4j 1-to-Log4j 2 bridge is now deprecated and will be removed in Log4j 3, teams should begin plans to eliminate reliance on the bridge entirely.