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.
| Vendor | Product | Versions |
|---|---|---|
| apache | log4j | maven/org.apache.logging.log4j:log4j-1.2-api: >= 2.7, < 2.25.4, maven/org.apache.logging.log4j:log4j-1.2-api: >= 3.0.0-beta1, <= 3.0.0-beta2 |
Downstream vendors/products affected by this vulnerability
| Vendor | Product | Source | Confidence |
|---|---|---|---|
| apache | log4j | cert_advisory | 90% |
| maven | org.apache.logging.log4j:log4j-1.2-api | GHSA | 85% |
Updated affected versions, changed severity to MEDIUM, and marked the vulnerability as actively exploited with an available exploit.
Updated affected versions to include 2.25.3 and 3.0.0-beta2, changed severity to HIGH, and noted that no exploit exists.
Initial creation
