Log4j 2.17.x: Five Unpatched CVEs Now Resolved with NES for Apache Log4j 2

Apache Log4j 2 is one of the most widely deployed Java logging frameworks in existence. It is also end-of-life on versions prior to the latest upstream releases, which means the millions of applications still running on Log4j 2.17.x have no upstream channel for security fixes. Today, HeroDevs is changing that.

We are launching NES for Apache Log4j 2: a secure, drop-in replacement for Apache Log4j 2.17.x that delivers ongoing security coverage for organizations that cannot or should not migrate on an upstream timeline. The first release, version 2.17.2-log4j-2.17.3 (released May 4, 2026), resolves five CVEs with no upstream fix available for this version line.

‍

Why Log4j 2 still needs support

The Log4Shell vulnerability (CVE-2021-44228) put Apache Log4j on every security team's radar in late 2021. Upstream patching moved quickly at the time, but Log4j 2's version support policy has not stood still. The Apache Logging project focuses active maintenance on its most recent releases. Organizations running Log4j 2.17.x in long-lived Java environments, particularly those embedded in application servers, third-party products, or large monolithic stacks, face a familiar problem: new CVEs arrive against a version line the upstream project has moved past.

The five CVEs resolved in this launch illustrate exactly that gap. All five affect Log4j 2.17.x. None have an upstream fix available for that version line. Until today, the only options were to accept the risk or attempt a potentially disruptive upgrade.

‍

Five CVEs resolved at launch

The table below summarizes the vulnerabilities resolved in NES for Apache Log4j 2, version 2.17.2-log4j-2.17.3.

‍

What each fix addresses

CVE-2025-68161 and CVE-2026-34477: TLS hostname verification not enforced in network appenders

These two CVEs describe the same attack surface from different angles, and together they close a long-standing gap in how Log4j 2 handles TLS for its socket-based appenders (SocketAppender, SyslogAppender, SmtpAppender).

CVE-2025-68161 (CWE-297, CVSS v3.1: 4.8, vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) identified that SslSocketManager never set SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") before completing the TLS handshake. The result: the JVM validated the certificate chain against the configured trust store, but never verified that the certificate was actually issued for the intended host. Any certificate signed by a trusted CA, for any host, was accepted. A network-positioned attacker holding such a certificate could silently intercept or forge the entire log stream. The verifyHostName attribute and the log4j2.sslVerifyHostName system property were both no-ops.

CVE-2026-34477 (CWE-297, CVSS v4.0: 6.3, vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N) is the follow-on: even after the CVE-2025-68161 fix wired up the system property path, the XML configuration attribute <Ssl verifyHostName="true"> remained silently ignored due to a mismatched factory method call introduced in the Log4j 2.12+ API. Both paths are now fully enforced in NES for Apache Log4j 2.

‍

CVE-2026-34479 and CVE-2026-34480: Invalid XML characters in XML layout output

Applications that log user-controlled input and use Log4j1XmlLayout or XmlLayout to ship structured log records downstream can produce XML output containing characters that are illegal per the XML 1.0 specification. Control characters in particular (those in the ranges \u0001–\u0008, \u000B–\u000C, \u000E–\u001F) are not valid XML but may appear in log messages from application exceptions, malformed HTTP input, or binary protocol data.

Both CVE-2026-34479 (CWE-116, CVSS v3.1: 7.5 High, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, affecting log4j-1.2-api versions 2.7 through 2.25.3) and CVE-2026-34480 (CVSS v4.0: 6.9 Medium, affecting log4j-core versions up to 2.25.3) share the same failure mode. When those characters reach a downstream XML parser (a SIEM ingestion pipeline, an audit log processor, a centralized log aggregator), the parser rejects the malformed document. Depending on the StAX implementation in use, the result is either silently malformed output that conforming parsers reject as a fatal error, or an exception thrown during the logging call that drops the event entirely. Either way: dropped log records or a crashed parsing process, a denial of service against the logging infrastructure itself. NES for Apache Log4j 2 replaces these characters with their Unicode replacement equivalents before they reach the layout output.

‍

CVE-2026-34481: Non-finite floating-point values produce malformed JSON

CVE-2026-34481 (CWE-116, CVSS v4.0: 6.3 Medium, vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N) affects JsonTemplateLayout in versions 2.14.0 through 2.25.3. Its internal JsonWriter wrote non-finite floating-point values (NaN, Infinity, -Infinity) as bare tokens directly into JSON output. These values are not legal JSON per RFC 8259, which requires that numeric values be finite. Any downstream JSON consumer that strictly validates its input will reject or fail on the resulting log document. The practical impact is the same as the XML layout issues: dropped records, parser errors, or monitoring blind spots. NES for Apache Log4j 2 writes these values as quoted strings, preserving the information while producing valid JSON.

‍

Who should use NES for Apache Log4j 2

NES for Apache Log4j 2 is the right fit when:

• Your application depends on Log4j 2.17.x and migration to a later version is gated by dependency constraints, vendor certification, or release schedule.
• Your security and compliance posture requires a documented, patched version of every logging dependency in your stack, and "accept the risk" is not an option.
• You are operating in a regulated environment (HIPAA, FedRAMP, SOC 2, PCI DSS) where unpatched known CVEs in production dependencies create audit findings.
• You need ongoing security coverage, not a one-time patch: NES delivers continued security remediation as new CVEs are disclosed against affected Log4j 2 versions.

NES for Apache Log4j 2 is a drop-in replacement distributed as Maven packages. Switching requires a repository configuration change, not a code change. Installation and configuration details are in the NES for Apache Log4j 2 documentation. For a full list of what changed in this release, see the 2.17.3 release notes.

‍

Taking action

Log4j 2 is not a solved problem. The five CVEs resolved in this launch were all disclosed against a version line the upstream project had moved past. They affected TLS integrity, audit log reliability, and JSON pipeline correctness, quietly, without user interaction required. The fix was only available to organizations on current upstream versions or through NES.

If your organization runs Apache Log4j 2.17.x and needs a path to staying secure without an emergency migration, NES for Apache Log4j 2 is available today. Get a quote, explore the product documentation, or review the full release notes to see exactly what is covered.