CVE intelligence and bounded remediation

CVE-2023-31038 — SQL injection in Log4cxx when using the ODBC appender to send log messages to a database

High CVSS 8.8

SQL injection in Log4cxx when using the ODBC appender to send log messages to a database. No fields sent to the database were properly escaped for SQL injection. This has been the case since at least version 0.9.0(released 2003-08-06) Note that Log4cxx is a C++ framework, so only C++ applications are affected. Before version 1.1.0, the ODBC appender was automatically part of Log4cxx if the library was found when compiling the library. As of version 1.1.0, this must be both explicitly enabled in order to be compiled in. Three preconditions must be met for this vulnerability to be possible: 1. Log4cxx compiled with ODBC support(before version 1.1.0, this was auto-detected at compile time) 2. ODBCAppender enabled for logging messages to, generally done via a config file 3. User input is logged at some point. If your application does not have user input, it is unlikely to be affected. Users are recommended to upgrade to version 1.1.0 which properly binds the parameters to the SQL statement, or migrate to the new DBAppender class which supports an ODBC connection in addition to other databases. Note that this fix does require a configuration file update, as the old configuration files…

Severity
High
CVSS
8.8 (3.1)
Published
2023-05-08
CISA KEV
Not currently listed
Ecosystem
software/application
Weaknesses
CWE-89

Affected products

  • apache / log4cxx

Matched remediation archetype

SQL and data-query injection

This catalog composition supplies bounded fallback guidance. Explicitly reviewed curated workflows load with the complete record below.

Check exposure

  • Trace request, message, file, and stored values into SQL, ORM query fragments, filters, sort expressions, and other data-query languages.
  • Inventory database roles, reachable schemas, multi-tenant boundaries, and whether stacked or administrative operations are enabled.
  • Check both direct queries and second-order use of previously stored values.

Remediate safely

  • Use parameterized queries or safe query builders for all values; map identifiers and operators through explicit allowlists.
  • Remove raw query concatenation and give the application account only the tables and operations it requires.
  • Update affected data-access components and add regression tests for query structure preservation with inert edge-case inputs.

Authoritative sources

Complete CVE record and remediation plan

The detailed catalog view below loads this exact record, its source evidence, and the full seven-phase agentic change plan.