CVE-2022-23305: Apache Log4j SQLI Vulnerability

CVE-2022-23305 Overview

CVE-2022-23305 is a SQL Injection vulnerability in the JDBCAppender component of Apache Log4j 1.2.x. By design, the JDBCAppender accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included in these configurations. This design flaw allows attackers to manipulate SQL queries by entering crafted strings into input fields or headers of an application that are logged, enabling unintended SQL queries to be executed against the backend database.

Critical Impact

Attackers can execute arbitrary SQL queries through log message injection, potentially leading to data exfiltration, data manipulation, or complete database compromise. This vulnerability affects applications using the legacy Log4j 1.x with JDBCAppender configured.

Affected Products

• Apache Log4j 1.2.x (all versions)
• NetApp SnapManager (for Oracle and SAP)
• Broadcom Brocade SANnav
• QOS reload4j
• Oracle WebLogic Server (versions 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0)
• Oracle Business Intelligence (versions 5.9.0.0.0, 12.2.1.3.0, 12.2.1.4.0)
• Oracle Enterprise Manager Base Platform (versions 13.4.0.0, 13.5.0.0)
• Oracle MySQL Enterprise Monitor
• Oracle Communications products (multiple versions)

Discovery Timeline

• 2022-01-18 - CVE-2022-23305 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-23305

Vulnerability Analysis

This SQL Injection vulnerability exists in the architectural design of Log4j 1.x's JDBCAppender component. When applications configure JDBCAppender to log messages directly to a database, the SQL statement template uses PatternLayout converters to insert values. The %m converter, which represents the log message content, is typically included in these SQL templates.

The fundamental issue is that user-controllable data (log messages) is concatenated directly into SQL statements without proper parameterization or sanitization. When an application logs user input—such as HTTP headers, form fields, or other request parameters—attackers can inject malicious SQL syntax that gets executed against the database.

This vulnerability affects applications that meet all of the following conditions: they use Log4j 1.2.x, have explicitly configured JDBCAppender (not the default configuration), and log user-controllable input. The vulnerability does not require authentication and can be exploited remotely over the network.

Root Cause

The root cause is the use of string concatenation for SQL query construction within JDBCAppender rather than prepared statements with parameterized queries. The PatternLayout system was designed for flexible log formatting but was not designed with SQL injection prevention in mind. When the %m pattern (or similar user-influenced patterns) is included in SQL templates, the logged message content is directly embedded into the SQL statement without escaping or parameterization.

Apache Log4j 1.2 reached end of life in August 2015, and this architectural limitation was addressed in Log4j 2.0-beta8 and later, where JDBCAppender was re-introduced with proper support for parameterized SQL queries.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by injecting SQL syntax into any input field, HTTP header, or other data that eventually gets logged through the JDBCAppender. The injected content becomes part of the SQL statement executed against the database.

For example, if an application logs HTTP headers and an attacker controls a header value, they can craft input containing SQL injection payloads. When this data is logged via JDBCAppender, the malicious SQL is executed. Common attack scenarios include injecting into User-Agent headers, authentication fields, or any other logged parameters.

The attack does not require direct access to the application's database—only the ability to submit input that will be logged. This makes it particularly dangerous in web applications where multiple input vectors may be logged for debugging or auditing purposes.

Detection Methods for CVE-2022-23305

Indicators of Compromise

• Database query logs showing unusual or malformed SQL statements containing injection patterns such as '; DROP TABLE, UNION SELECT, or OR '1'='1
• Application logs containing suspicious input patterns in logged fields that resemble SQL syntax
• Unexpected database modifications, data exfiltration, or access to sensitive tables
• Error messages in logs indicating SQL syntax errors from malformed injected queries

Detection Strategies

• Scan application dependencies and configuration files to identify usage of Log4j 1.x with JDBCAppender enabled
• Implement database activity monitoring to detect anomalous SQL query patterns
• Deploy web application firewalls (WAF) with SQL injection detection rules to identify malicious payloads in HTTP requests
• Use software composition analysis (SCA) tools to identify vulnerable Log4j 1.x libraries in the codebase

Monitoring Recommendations

• Enable detailed database query logging to capture and analyze all executed SQL statements
• Monitor application logs for input containing SQL keywords and special characters in logged fields
• Configure alerts for database errors that may indicate failed injection attempts
• Implement centralized logging with correlation capabilities to trace injection attempts across application and database layers

How to Mitigate CVE-2022-23305

Immediate Actions Required

• Upgrade to Apache Log4j 2.x (version 2.17.1 or later recommended) which includes proper parameterized SQL query support
• If immediate upgrade is not possible, disable or remove JDBCAppender configuration from Log4j 1.x deployments
• Migrate to QOS reload4j (patched fork of Log4j 1.x) as an interim solution if Log4j 2.x migration requires significant effort
• Audit all applications to identify those using Log4j 1.x with JDBCAppender configurations

Patch Information

Apache Log4j 1.2 reached end of life in August 2015, and no official patches will be released for this version. The recommended remediation is to migrate to Log4j 2.x, where JDBCAppender was re-implemented with parameterized SQL queries starting in version 2.0-beta8.

For organizations unable to immediately migrate, QOS reload4j provides a drop-in replacement fork of Log4j 1.x with security fixes. Oracle has released patches for affected products in their April 2022 Critical Patch Update and July 2022 Critical Patch Update. NetApp has also published Security Advisory NTAP-20220217-0007 addressing this vulnerability.

Workarounds

• Remove or comment out JDBCAppender configurations from log4j.properties or log4j.xml configuration files
• Implement input validation and sanitization at the application layer before data reaches the logging framework
• Configure database user permissions to limit the potential impact of SQL injection (principle of least privilege)
• Use alternative appenders (FileAppender, ConsoleAppender) that do not execute SQL queries

# Configuration example - Disabling JDBCAppender in log4j.properties
# Comment out or remove JDBCAppender configuration
# log4j.appender.DB=org.apache.log4j.jdbc.JDBCAppender
# log4j.appender.DB.URL=jdbc:mysql://localhost/logs
# log4j.appender.DB.driver=com.mysql.jdbc.Driver
# log4j.appender.DB.user=log_user
# log4j.appender.DB.password=log_password
# log4j.appender.DB.sql=INSERT INTO LOGS VALUES('%m')

# Use FileAppender as a safe alternative
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=/var/log/application.log
log4j.appender.file.MaxFileSize=10MB
log4j.appender.file.MaxBackupIndex=10
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n