Second-Order SQL Injection in Hibernate InlineIdsOrClauseBuilder

This 15-file repository is a Dockerized Spring Boot/MariaDB vulnerability laboratory and functional proof of concept for the claimed CVE-2026-0603 Hibernate ORM second-order SQL injection. It builds a Java 17 Spring Boot application using Hibernate ORM 5.6.15.Final and intentionally enables `InlineIdsOrClauseBulkIdStrategy` in `application.yml`. The application models a joined Hibernate inheritance hierarchy: `User` maps to `users_base`, while `UserProfile` maps to `users_profile` using the same string `username` primary key. The exploitable flow is split across normal application actions. `POST /users` persists a user-controlled username, including SQL metacharacters. `DELETE /users/{username}` invokes a JPQL bulk delete, and `PATCH /users/{username}/email` invokes a multi-table JPQL bulk update spanning base and profile fields. Both repository methods are annotated as vulnerable paths because Hibernate's inline-ID bulk strategy can insert the stored primary-key value into generated SQL predicates. The included example username, `' or '1' = '1`, is intended to make that predicate true for all rows, causing broad deletion or modification when the corresponding bulk operation is triggered. Repository structure consists of container setup (`Dockerfile`, `start.sh`), Maven dependency configuration (`app/pom.xml`), Spring Boot application/domain/DTO/controller/repository Java code, Hibernate and MariaDB configuration, and a static HTML/JavaScript interface that registers, lists, edits, and deletes users via the REST endpoints. `start.sh` starts MariaDB, creates the `lab` database and `lab` user, then launches the packaged application. The repository does not provide remote command execution, a reverse shell, persistence, credential theft, or an external callback mechanism; its demonstrated payload capability is database-wide integrity/destruction impact through stored SQL injection.

This repository is a self-contained vulnerable lab rather than a standalone exploit script. It packages a Spring Boot 2.7.18 application with Hibernate ORM 5.6.15.Final and MariaDB inside a Dockerized environment. The structure is small and purpose-built: a Dockerfile provisions Ubuntu, OpenJDK 17, Maven, MariaDB, and curl; start.sh initializes the database and launches the built JAR; the Java application defines a joined-inheritance user model (users_base and users_profile), a JPA repository with custom bulk DELETE and UPDATE queries, and a REST controller exposing those operations over HTTP. The frontend in static/index.html acts as a simple UI that calls the backend API with fetch(). The key exploit-relevant capability is that the repository intentionally exposes vulnerable Hibernate bulk-operation paths. In UserRepository, bulkDeleteByUsername() executes a JPQL DELETE against UserProfile by primary key, and bulkUpdateEmailByUsername() performs a JPQL UPDATE that modifies fields spanning multiple joined tables (users_base.email and users_profile.department). Comments in the code explicitly identify these as vulnerable paths and note that they drive Hibernate into InlineIdsOrClauseBuilder / MultiTableUpdateExecutor behavior. application.yml further confirms this by forcing hibernate.hql.bulk_id_strategy to org.hibernate.hql.spi.id.inline.InlineIdsOrClauseBulkIdStrategy. From an operator perspective, the lab can be interacted with entirely over HTTP on port 8080. POST /users registers a user, GET /users lists users, DELETE /users/{username} triggers the bulk delete path, and PATCH /users/{username}/email with JSON fields newEmail and newDepartment triggers the multi-table bulk update path. The frontend automates these calls but is not required; direct HTTP requests are sufficient. Overall, the repository’s purpose is to provide a reproducible environment for exercising and studying a Hibernate ORM bulk-operation vulnerability path, not merely to detect it.