Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN378 _____________________________________________________________________ DATE : 10/04/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Apache Log4j Core, Apache Log4j 1 to Log4j 2 bridge, Apache Log4j JSON Template Layout versions prior to 2.25.4, 3.0.0-alpha1 up to and including 3.0.0-beta3. ===================================================================== https://lists.apache.org/thread/5x0hcnng0chhghp6jgjdp3qmbbhfjzhb https://lists.apache.org/thread/gd0hp6mj17rn3kj279vgy4p7kd4zz5on https://lists.apache.org/thread/n34zdv00gbkdbzt2rx9rf5mqz6lhopcv https://lists.apache.org/thread/3k1clr2l6vkdnl4cbhjrnt1nyjvb5gwt https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4 _____________________________________________________________________ CVE-2026-34480: Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters Severity: moderate Affected versions: - Apache Log4j Core (org.apache.logging.log4j:log4j-core) 2.0-alpha1 before 2.25.4 - Apache Log4j Core (org.apache.logging.log4j:log4j-core) 3.0.0-alpha1 through 3.0.0-beta3 Description: Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters. The impact depends on the StAX implementation in use: * JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records. * Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output. Credit: Ap4sh (Samy Medjahed) and Ethicxz (Eliott Laurie) (original reporters) (finder) jabaltarik1 (independently) (finder) References: https://github.com/apache/logging-log4j2/pull/4077 https://logging.apache.org/security.html#CVE-2026-34480 https://logging.apache.org/cyclonedx/vdr.xml https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout https://logging.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-34480 Timeline: 2026-02-16: Vulnerability reported by Ap4sh and ethicxz 2026-03-10: Candidate patch shared internally by Piotr P. Karwasz 2026-03-15: Independent report received from jabaltarik1 2026-03-24: Fix shared publicly by Piotr P. Karwasz as pull request #4077 2026-03-25: Fix verified by reporter 2026-03-28: Log4j 2.25.4 released _____________________________________________________________________ CVE-2026-34479: Apache Log4j 1 to Log4j 2 bridge: Silent log event loss in Log4j1XmlLayout due to unescaped XML 1.0 forbidden characters Severity: moderate Affected versions: - Apache Log4j 1 to Log4j 2 bridge (org.apache.logging.log4j:log4j-1.2-api) 2.7 before 2.25.4 - Apache Log4j 1 to Log4j 2 bridge (org.apache.logging.log4j:log4j-1.2-api) 3.0.0-alpha1 through 3.0.0-beta2 Description: The Log4j1XmlLayout from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records. Two groups of users are affected: * Those using Log4j1XmlLayout directly in a Log4j Core 2 configuration file. * Those using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class. Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4, which corrects this issue. Note: The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the Log4j 1 to Log4j 2 migration guide https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html , and specifically the section on eliminating reliance on the bridge. Credit: Ap4sh (Samy Medjahed) and Ethicxz (Eliott Laurie) (original reporters) (finder) jabaltarik1 (independently) (finder) References: https://github.com/apache/logging-log4j2/pull/4078 https://logging.apache.org/security.html#CVE-2026-34479 https://logging.apache.org/cyclonedx/vdr.xml https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html https://logging.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-34479 Timeline: 2026-02-16: Vulnerability reported by Ap4sh and ethicxz 2026-03-15: Independent report received from jabaltarik1 2026-03-24: Fix shared publicly by Piotr P. Karwasz as pull request #4078 2026-03-25: Fix verified by reporter 2026-03-28: Log4j 2.25.4 released _____________________________________________________________________ CVE-2026-34481: Apache Log4j JSON Template Layout: Improper serialization of non-finite floating-point values in JsonTemplateLayout Severity: moderate Affected versions: - Apache Log4j JSON Template Layout (org.apache.logging.log4j:log4j-layout-template-json) 2.14.0 before 2.25.4 - Apache Log4j JSON Template Layout (org.apache.logging.log4j:log4j-layout-template-json) 3.0.0-alpha1 through 3.0.0-beta3 Description: Apache Log4j's JsonTemplateLayout https://logging.apache.org/log4j/2.x/manual/json-template-layout.html , in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (NaN, Infinity, or -Infinity), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records. An attacker can exploit this issue only if both of the following conditions are met: * The application uses JsonTemplateLayout. * The application logs a MapMessage containing an attacker-controlled floating-point value. Users are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue. Credit: Ap4sh (Samy Medjahed) and Ethicxz (Eliott Laurie) (finder) References: https://github.com/apache/logging-log4j2/pull/4080 https://logging.apache.org/security.html#CVE-2026-34481 https://logging.apache.org/cyclonedx/vdr.xml https://logging.apache.org/log4j/2.x/manual/json-template-layout.html https://logging.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-34481 Timeline: 2026-02-16: Vulnerability reported by Ap4sh and ethicxz 2026-03-10: Candidate patch internally shared by Piotr P. Karwasz 2026-03-24: Fix shared publicly by Piotr P. Karwasz as pull request #4080 2026-03-25: Fix verified by the reporter 2026-03-28: Log4j 2.25.4 released _____________________________________________________________________ CVE-2026-34478: Apache Log4j Core: Log injection in Rfc5424Layout due to silent configuration incompatibility Severity: moderate Affected versions: - Apache Log4j Core (org.apache.logging.log4j:log4j-core) 2.21.0 before 2.25.4 - Apache Log4j Core (org.apache.logging.log4j:log4j-core) 3.0.0-beta1 through 3.0.0-beta3 Description: Apache Log4j Core's Rfc5424Layout https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout , in versions 2.21.0 through 2.25.3, is vulnerable to log injection via CRLF sequences due to undocumented renames of security-relevant configuration attributes. Two distinct issues affect users of stream-based syslog services who configure Rfc5424Layout directly: * The newLineEscape attribute was silently renamed, causing newline escaping to stop working for users of TCP framing (RFC 6587), exposing them to CRLF injection in log output. * The useTlsMessageFormat attribute was silently renamed, causing users of TLS framing (RFC 5425) to be silently downgraded to unframed TCP (RFC 6587), without newline escaping. Users of the SyslogAppender are not affected, as its configuration attributes were not modified. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue. Credit: Samuli Leinonen (finder) References: https://github.com/apache/logging-log4j2/pull/4074 https://logging.apache.org/security.html#CVE-2026-34478 https://logging.apache.org/cyclonedx/vdr.xml https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout https://logging.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-34478 Timeline: 2025-12-25: Vulnerability reported by Samuli Leinonen 2026-03-10: Candidate patch shared internally by Piotr P. Karwasz 2026-03-24: Fix shared publicly by Piotr P. Karwasz as pull request #4074 2026-03-25: Fix verified by reporter 2026-03-28: Log4j 2.25.4 released _____________________________________________________________________ CVE-2026-34477: Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass Severity: moderate Affected versions: - Apache Log4j Core (org.apache.logging.log4j:log4j-core) 2.12.0 before 2.25.4 - Apache Log4j Core (org.apache.logging.log4j:log4j-core) 3.0.0-alpha1 through 3.0.0-beta3 Description: The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the element. Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * An SMTP, Socket, or Syslog appender is in use. * TLS is configured via a nested element. * The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue. Credit: Samuli Leinonen (original reporter) (finder) Naresh Kandula (independently) (finder) Vitaly Simonovich (independently) (finder) Raijuna (independently) (finder) Danish Siddiqui (djvirus, independently) (finder) Markus Magnuson (independently) (finder) Haruki Oyama (Waseda University, independently) (finder) References: https://github.com/apache/logging-log4j2/pull/4075 https://logging.apache.org/security.html#CVE-2026-34477 https://logging.apache.org/cyclonedx/vdr.xml https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName https://logging.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-34477 Timeline: 2025-12-20: Vulnerability reported by Samuli Leinonen 2025-12-30: Candidate patch shared internally by Piotr P. Karwasz 2026-02-25: Independent report received from Naresh Kandula 2026-03-01: Independent report received from Vitaly Simonovich 2026-03-02: Independent report received from Raijuna 2026-03-08: Independent report received from Danish Siddiqui 2026-03-19: Independent report received from Markus Magnuson 2026-03-21: Independent report received from Haruki Oyama 2026-03-24: Fix shared publicly by Piotr P. Karwasz as pull request #4075 2026-03-28: Log4j 2.25.4 released ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================