There were three new vulnerabilities for Log4j this week, impacting Apache Log4j 1.x and 2.x: CVE-2022-23302, CVE-2022-23307 and CVE-2022-23305.

Keycloak team is aware of these CVEs, has completed the verification, and was able to conclude that the Keycloak 16.0.1 and earlier releases are not impacted by this. Below, you can find more details:

• CVE-2022-23302: A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSSink in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSSink and to the attacker's JNDI LDAP endpoint.

  • Not Impacted JMSSink is not enabled on Keycloak

• CVE-2022-23307: A flaw was found in the log4j 1.x chainsaw component, where the contents of certain log entries are deserialized and possibly permit code execution. This flaw allows an attacker to send a malicious request with serialized data to the server to be deserialized when the chainsaw component is run.

  • Not Impacted Chainsaw is not configured on Keycloak to read serialized log events

• CVE-2022-23305: By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converted from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed.

  Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs.

  • Not Impacted Keycloak does not make any usage of JDBCAppender.

Similar discussions

• Keycloak is NOT affected by the Log4j remote code injection vulnerability (CVE-2021-44228) #9078