CVE-2022-23305

Overview

Apache Log4j is a widely used Java-based logging framework that allows applications to output structured logging information in a variety of formats and transports. Among the optional components included with Log4j 1.x is JDBCAppender, which writes log events directly into a relational database using SQL statements.

‍

A critical SQL injection vulnerability (CVE-2022-23305) affects all Log4j 1.x versions when JDBCAppender is enabled. JDBCAppender accepts a full SQL statement as a configuration parameter, embedding values generated from PatternLayout tokens such as %m for the log message. Because user-controlled input frequently flows into log messages, attackers can inject malicious SQL fragments that the JDBCAppender inserts directly into the configured SQL statement without validation or parameterization.

‍

Per OWASP: A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands..

‍

This vulnerability only affects Log4j 1.x when specifically configured to use JDBCAppender, which is not enabled by default. Log4j 1.x has been end-of-life since 2015 and receives no official fixes.

‍

Details

Module Info

• Product: Apache Log4j
• Affected packages: log4j
• Affected versions: >= 1.2, <= 1.2.17
• GitHub repository: https://github.com/apache/logging-log4j1
• Published packages: https://central.sonatype.com/artifact/log4j/log4j
• Package manager: Maven
• Fixed In: NES for Apache Log4j v1.2.18

‍

Vulnerability Info

The vulnerability is rooted in unsafe SQL construction within JDBCAppender. Administrators configure a complete SQL template string, and Log4j substitutes PatternLayout values - including the raw log message - directly into the SQL command without escaping or parameterization.

‍

If an attacker can influence application fields, headers, or payloads that become part of a logged message, they may inject SQL control characters or fragments that alter the structure of the SQL query. This can allow:

• unauthorized data access
• data modification or deletion
• privilege escalation
• full database compromise

Steps To Reproduce

• Establish a database environment and configure a legacy logging appender to insert log entries into a table using a basic string substitution pattern.
• Input a crafted string containing SQL control characters into a logged field to prematurely terminate the intended insertion command and append a secondary instruction.
• Observe the database state to confirm that the secondary instruction was executed, demonstrating that the framework failed to treat the log content as inert data.

Mitigation

Apache Log4j 1.x has been end-of-life since 2015 and no longer receives community updates. Users of the affected component should apply one of the following mitigations:

‍

Users of Log4j 1.x should apply the following mitigations:

• Upgrade affected applications to supported versions of Log4j
• Leverage a commercial support partner like HeroDevs for post-EOL security support
• Remove or disable JDBCAppender from Log4j configurations
• Upgrade to Log4j 2.x, which uses parameterized SQL and safer logging semantics
• Apply filtering or sanitation controls on log message content

‍