Did you know a logging library could make your app vulnerable to severe security attacks like SQL Injection? Most developers worry about vulnerabilities in the main application code, but sometimes issues lurk in the places you trust the most. CVE-2022-23305 is a perfect example, targeting Log4j 1.2.x when used with its lesser-known JDBCAppender. In this post, we’ll break down how this vulnerability works, show real code snippets, reference the official details, and most importantly—teach you how to stay safe.
What Is CVE-2022-23305?
Log4j is one of the most popular Java logging frameworks. In older version 1.2.x, it offers an appender called JDBCAppender. This component is intended to write log messages directly into a database by running SQL queries. The consequence? If not configured securely, user input can end up directly inside SQL statements. This opens up the classic and deadly door for SQL Injection—but now inside your logger!
Only affects Log4j 1.x when using JDBCAppender.
- The dangerous part is using SQL statements in the config that include user-controlled content (e.g., %m for message).
- Attackers can supply crafted input via web forms or headers, and it ends up as part of an SQL statement inside your log table.
Where’s the Problem in the Code?
Here is an example configuration for Log4j’s JDBCAppender—something you might find in a real-world app:
log4j.appender.DB=org.apache.log4j.jdbc.JDBCAppender
log4j.appender.DB.URL=jdbc:mysql://localhost:3306/logging
log4j.appender.DB.driver=com.mysql.cj.jdbc.Driver
log4j.appender.DB.user=db_user
log4j.appender.DB.password=db_pass
log4j.appender.DB.sql=INSERT INTO logs (message) VALUES ('%m')
log4j.appender.DB.layout=org.apache.log4j.PatternLayout
The line of concern is
log4j.appender.DB.sql=INSERT INTO logs (message) VALUES ('%m')
Whenever a message is logged, %m is replaced by the log message verbatim.
Let’s say your application logs incoming query parameters
logger.info(request.getParameter("username"));
Suppose an attacker sends this value as the username
admin'); DROP TABLE users; --
The SQL statement in JDBCAppender would then be
INSERT INTO logs (message) VALUES ('admin'); DROP TABLE users; --')
This will execute two statements: the INSERT and a DROP TABLE, deleting your users table! All because the untrusted input from a web form made its way into an SQL statement without any filtering.
Exploit Code Example
For educational purposes, here’s a very simple Java code sample showing how logging user input via JDBCAppender can go wrong:
String userInput = request.getParameter("email");
// Looks harmless, right?
logger.info(userInput);
But with the log4j properties from earlier, if someone submits
'); DELETE FROM important_data; --
Your logs table statement becomes
INSERT INTO logs (message) VALUES (''); DELETE FROM important_data; --')
Everything in important_data vanishes!
Why Did This Happen?
- Log4j 1.x’s JDBCAppender didn’t support parameterized queries. It just performed string replacement.
No default protection.
By contrast, Log4j 2.x (as of version 2.-beta8) uses prepared statements and parameter bindings, which prevent attackers from injecting new SQL commands through user input.
Systems logging user input to a database with the JDBCAppender.
- Environments where attackers can control logged fields (such as login requests, form data, API headers, etc).
Apache Log4j 1.x will not receive fixes (it’s unsupported).
If you *must* stay with Log4j 1.x (which you shouldn’t), do not log user input using JDBCAppender, or at the very least, carefully sanitize messages before logging or use a different logging backend.
References
- Apache Official CVE Page – CVE-2022-23305
- Log4j Security Vulnerabilities
- JDBCAppender Log4j 1.x Documentation (Archive)
Always use loggers and libraries that support secure formats and parameterized queries.
If your legacy app uses Log4j 1.x and logs directly to a database, you should treat this as a critical risk—upgrade or mitigate right away.
Timeline
Published on: 01/18/2022 16:15:00 UTC
Last modified on: 07/25/2022 18:21:00 UTC