CVE-2022-23305

What it actually does

CVE-2022-23305 is a SQL injection vulnerability in Log4j 1.x-style JDBCAppender behavior, including affected reload4j code before the fixed commit. JDBCAppender accepts a raw SQL statement in logging configuration and expands PatternLayout converters such as %m directly into that SQL. If attacker-controlled data is logged into the message field or other interpolated layout fields, crafted input can alter the SQL statement executed by the logging subsystem. Depending on the database permissions granted to the logging connection, this can allow unauthorized data reads, data modification, deletion, stored procedure execution, or database-side denial of service. The issue only applies when JDBCAppender is configured and the logging SQL pattern includes attacker-influenced values; it is not present in default logging configurations that do not use JDBCAppender.

Why it matters to the business

Applications using vulnerable Log4j 1.x or reload4j JDBCAppender configurations may allow external users to turn ordinary logged input, such as form fields, URLs, usernames, or HTTP headers, into database commands. The operational consequences can include compromise or destruction of application data, exposure of sensitive records, interruption of services that rely on the database, and potential regulatory or contractual reporting obligations. Although this vulnerability is configuration-dependent and is not listed in CISA KEV, it has a high CVSS score and a high EPSS score, so internet-facing applications that log untrusted input to a database should be treated as urgent. Log4j 1.x has been end-of-life since 2015, increasing long-term business risk because additional unfixed issues may remain.

How an attack unfolds

An attacker first identifies an application that logs user-controlled values through Log4j 1.x or an affected reload4j JDBCAppender configuration. The vulnerable configuration contains a SQL insert or similar statement where PatternLayout converters, especially the message converter %m, are concatenated into the SQL text rather than bound as parameters. The attacker sends a crafted value in a field likely to be logged, such as a login name, search string, URL parameter, User-Agent, Referer, or other HTTP header. When the application writes the log event, JDBCAppender expands the attacker-controlled message into the configured SQL statement. The database then executes the modified SQL. Successful exploitation depends on the configured SQL template, quoting context, database engine, and privileges of the logging database account, but impact can range from adding extra rows to dumping, altering, or deleting data. If the logging database account has excessive privileges, exploitation may extend to broader database compromise.

How to fix it

Remove Log4j 1.x and migrate to a supported logging framework wherever possible. For reload4j users, upgrade to a version containing commit 07225cff489eacef093939951c1edd80af14fbce or later. If using Apache Log4j, migrate to Log4j 2.x, where JDBCAppender was reintroduced with proper parameterized SQL query support beginning in 2.0-beta8; use a current supported Log4j 2 release rather than an early beta. As an immediate mitigation, disable or remove JDBCAppender configurations, especially any appender using PatternLayout values such as %m inside SQL text. If database logging must remain, use parameterized inserts or a logging component that binds values safely rather than concatenating SQL. Restrict the logging database account to the minimum required privileges, preferably insert-only into the intended log table, with no permissions to read sensitive tables, update application data, delete data, execute stored procedures, create objects, or access administrative functions. Review logging patterns to avoid recording raw untrusted input where unnecessary.

How to confirm the fix worked

Inventory application dependencies and runtime classpaths for Log4j 1.x or reload4j and confirm whether org.apache.log4j.jdbc.JDBCAppender is present and configured. Search configuration files such as log4j.properties, log4j.xml, and application-specific logging configuration for JDBCAppender, setSql, <param name="sql">, or SQL templates containing PatternLayout converters such as %m, %p, %c, %t, %x, %X, or %d. Confirm upgraded reload4j code includes commit 07225cff489eacef093939951c1edd80af14fbce or a release that incorporates it. Validate that no active configuration concatenates log messages directly into SQL. In non-production testing, submit benign SQL metacharacter strings into fields known to be logged and confirm the application logs safely without SQL errors, additional database statements, or malformed rows. Review database permissions for the logging account and verify least privilege is enforced.

Typical attack path

1. Find an application using Log4j 1.x-style logging or reload4j with JDBCAppender enabled.
2. Identify inputs that are likely to be logged, such as authentication fields, request parameters, request paths, error messages, or HTTP headers.
3. Submit SQL metacharacters and database-specific payloads in those inputs to test whether log writes trigger SQL syntax errors or behavioral changes.
4. Refine the payload to escape the configured logging SQL value context and append unintended SQL clauses or statements.
5. Cause the application to log the payload, resulting in JDBCAppender executing attacker-modified SQL against the logging database.
6. Use the database privileges available to the logging connection to read, modify, delete, or disrupt data.

How to detect it

To determine whether exploitation has already occurred, focus on applications that used Log4j 1.x or affected reload4j with JDBCAppender enabled. Review application logs for attacker-controlled fields containing SQL syntax, quote-breaking attempts, comments, stacked-query separators, or database-specific functions shortly before database errors or unusual database activity. Review database audit logs for statements executed by the logging database user that deviate from the expected log insert pattern, including SELECT, UPDATE, DELETE, DROP, ALTER, CREATE, UNION, EXEC, stored procedure calls, or multi-statement executions. Correlate suspicious SQL activity with web access logs by timestamp, source IP, request path, query string, and headers such as User-Agent and Referer. Look for database syntax errors generated by logging inserts, unexpected spikes in failed log writes, malformed rows in log tables, new database objects, privilege changes, or unusual data access from the logging account. Because exploitation payloads are application- and SQL-template-specific, absence of a fixed IOC does not prove absence of exploitation; behavioral review of database statements from the logging connection is the most reliable approach.

• org.apache.log4j.jdbc.JDBCAppender
• log4j.appender.JDBC
• log4j.appender.*=org.apache.log4j.jdbc.JDBCAppender
• setSql(
• <param name="sql"
• %m
• SQLSyntaxErrorException
• java.sql.SQLException
• You have an error in your SQL syntax
• ORA-00933
• ORA-00936
• ERROR: syntax error at or near
• Unclosed quotation mark after the character string
• ';--
• ' OR '1'='1
• " OR "1"="1
• UNION SELECT
• ; DROP TABLE
• ; DELETE FROM
• xp_cmdshell
• pg_sleep(
• SLEEP(
• WAITFOR DELAY

What your security team should do

• Prioritize internet-facing and high-trust applications that use Log4j 1.x or reload4j and write logs to a database through JDBCAppender.
• Immediately disable JDBCAppender or replace it with a safe, parameterized logging mechanism if upgrade cannot be completed quickly.
• Upgrade reload4j to a version containing commit 07225cff489eacef093939951c1edd80af14fbce or later, and plan migration away from Log4j 1.x-era components to supported logging libraries.
• Search source repositories, deployment artifacts, containers, and configuration management for JDBCAppender usage and SQL templates containing PatternLayout converters.
• Audit the logging database account and reduce privileges to insert-only access to the intended log table wherever possible.
• Review database logs and application logs for SQL errors or unusual statements originating from logging connections, especially around unauthenticated request activity.
• Add regression tests or configuration checks that fail builds when JDBCAppender is configured with concatenated SQL.
• Treat any confirmed exploitation as a database compromise scenario and perform data integrity, confidentiality, and access review based on the logging account’s privileges.