CVE-2022-23305

CRITICAL

SQL injection in JDBC Appender in Apache Log4j V1

Title source: CVE List
Search associated code STIX 2.1 vulnerability STIX 2.1 with PoCs

Record summary

CVE-2022-23305 has a selected CVSS score of 9.8 (critical); EIP currently links 3 repository PoCs and 1 lab environment.

Description

By design, the JDBCAppender in Log4j 1.2.x 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. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Description source: CVE List

Exploitation context

Available material

Repository PoCs
3
Lab environments
1

CISA SSVC decision

ExploitationNone
AutomatableYes
Technical impactTotal

CISA Coordinator · SSVC 2.0.3 · Evaluated May 22, 2026 · Source: CVE List

Affected products and versions

3
ProductSourceVersion range

Apache Log4j 1.x

Browse Apache Software Foundation / Apache Log4j 1.x
CVE List1.2.1affected
Before 2.0-alpha1affected

log4j:log4j

Browse Maven / log4j:log4j
GitHub AdvisoryThrough 1.2.17affected

org.zenframework.z8.dependencies.commons:log4j-1.2.17

Browse Maven / org.zenframework.z8.dependencies.commons:log4j-1.2.17
GitHub AdvisoryThrough 2.0affected

Proofs of concept

3

Repository PoCs

GitHublogpresso/CVE-2021-44228-ScannerRepository PoCby logpresso861Not analyzed53 files

1.7 MiB · linked to 5 vulnerabilities

GitHub
PoC details
GitHubAlphabugX/CVE-2022-RCERepository PoCby AlphabugX5Not analyzed3 files

65.5 KiB

GitHub
PoC details
GitHubtkomlodi/CVE-2022-23305_POCRepository PoCby tkomlodi1Not analyzed8 files

4.6 KiB

GitHub
PoC details

Docker lab environments

1
GitHub

Repository root

tkomlodi/CVE-2022-23305_POCCreated Vuln labCVE-2022-23305Dockerfile

1 Dockerfile

View exploit
Analysisdeepseek-v4-pro:cloud ·

Environment assessment

A single-container Docker environment based on maven:3-eclipse-temurin-17 that builds and runs a Spring Boot application. The application uses Log4j 1.2.17 with a JDBCAppender writing to an in-memory H2 database, and exposes an HTTP endpoint that logs a user-supplied query parameter, demonstrating SQL injection via Log4j.

Dockerfile:1-8pom.xml:1-39src/main/java/poc/InjectionController.java:1-42

Lab assessment

Vulnerability lab

The README explicitly states it is a proof-of-concept for CVE-2022-23305, a SQL injection vulnerability in Log4j JDBCAppender. The code and configuration are designed to demonstrate the vulnerability by logging unsanitized user input via JDBCAppender.

README.md:1-3src/main/java/poc/InjectionController.java:24-28
Lab shapeDockerfile
ServicesUnknown
Compose manifests0
Dockerfiles1
Evidence & reasoningComponents · CVE assessment · exercise context · review boundaries
Components

Services and files described by the evidence

Maven build container

builds and runs the Spring Boot application

Uses the official maven:3-eclipse-temurin-17 image, copies source code and pom.xml, sets working directory to /tmp, and executes 'mvn spring-boot:run' to start the application.

Dockerfile:1-8

Spring Boot application

web applicationvulnerable target

A Spring Boot web application with a single endpoint at '/' that accepts a 'param' query parameter, logs it via Log4j, and returns all log entries from the H2 database. The logging uses a JDBCAppender configured in log4j.properties, making it susceptible to SQL injection.

src/main/java/poc/InjectionController.java:1-42src/main/resources/log4j.properties:1-11

H2 in-memory database

log storageSQL injection target

An in-memory H2 database configured via application.properties and schema.sql. It stores log messages in a 'logs' table. The JDBCAppender inserts log entries directly, and the application reads them back to display.

src/main/resources/application.properties:1-5src/main/resources/schema.sql:1-4

Log4j JDBCAppender

logging frameworkvulnerable component

Log4j 1.2.17 configured with a JDBCAppender that writes log messages directly to the H2 database using the SQL statement 'insert into logs values('%m')'. The message includes unsanitized user input, enabling SQL injection.

src/main/resources/log4j.properties:1-11pom.xml:22-26
CVE assessment

How the supplied evidence relates each vulnerability

CVE-2022-23305

Supported by supplied evidence

The environment uses Log4j 1.2.17 with a JDBCAppender that logs unsanitized user input, directly matching the described SQL injection vulnerability. The README and code comments explicitly reference CVE-2022-23305 and provide a working exploit example.

README.md:1-3src/main/java/poc/InjectionController.java:24-28pom.xml:22-26
Exercise context

Requirements and sequence described by the evidence

Prerequisites

  • Docker must be installed to build and run the container.README.md:8-10
  • The application must be built and run, either via Docker or directly with Maven.README.md:7-10
  • The attacker must be able to send HTTP requests to the application's endpoint (e.g., http://localhost:8080/).README.md:11-13

Evidence-described exercise path

  1. Build the Docker image: docker build --tag log4j-poc .README.md:9
  2. Run the container, mapping port 8080: docker run -p 8080:8080 log4j-pocREADME.md:10
  3. Send a request with a SQL injection payload in the 'param' query parameter, e.g., http://localhost:8080/?param=');insert into logs values(':(README.md:12-13
  4. Observe the injected SQL statement reflected in the returned log entries.README.md:14
Safety-review evidence

Behaviors behind the stored safety assessment

No harmful behavior observed

All visible behavior is confined to the containerized lab environment. The application only interacts with its own in-memory H2 database and exposes a single HTTP endpoint on port 8080. There is no evidence of host filesystem access, external network connections, credential theft, persistence, or any behavior beyond demonstrating the SQL injection vulnerability.

Dockerfile:1-8src/main/java/poc/InjectionController.java:1-42src/main/resources/application.properties:1-5
Review boundaries

What the analysis did not establish

  • No Docker Compose file or network configuration is provided; the environment is a single container with no orchestration details.
  • The packet does not include the actual exploit execution or runtime behavior; only static files are analyzed.
  • The Dockerfile does not specify a non-root user, but this is common in development/lab contexts and does not by itself indicate malicious intent.
Model interpretation

This review is limited to the supplied lab evidence packet. It does not assert that the environment runs, reproduces a vulnerability, or is safe to execute. Contract: eip-docker-lab-analysis-v1.

References

8