8.3
/ 10
HIGH
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Description
Hibernate ORM versions 5.6.15 and below suffer from a remote SQL injection vulnerability...
Basic Information
ID
PACKETSTORM:220500
Published
May 6, 2026 at 00:00
Affected Product
Affected Versions
# CVE-2026-0603 Hibernate ORM Injection / Second-Order SQL Injection
★ CVE-2026-0603 Hibernate SQL Injection PoC ★
https://github.com/user-attachments/assets/2e7c3a89-e26f-48cd-af0b-8b82d32ce71f
<br>
# Overview
> **CVE-2026-0603** is a **Second-Order SQL Injection** vulnerability in **Hibernate ORM**, a widely used Java ORM framework.
> When a user-supplied string primary key containing a malicious SQL payload is used in a bulk DELETE or UPDATE operation, Hibernate inserts the value directly into the WHERE clause without sanitization, causing **unintended mass deletion or modification of database records**.
<br>
# Affected Versions
| Category | Version |
|---|---|
| **Vulnerable** | Hibernate ORM **5.2.8 ≤ version ≤ 5.6.15** |
| **Patched** | No official patch **(5.6.x EOL)** |
<br>
# Impact
- Mass deletion of records across multiple tables
- Mass modification of records across multiple tables
- Potential exfiltration of sensitive data from the database
<br>
# Environment
```bash
docker build -t cve-2026-0603-hibernate-vuln .
docker run --rm -it -p 8080:8080 --name hibernate-vuln cve-2026-0603-hibernate-vuln
```
<br>
# PoC
After starting the vulnerable environment, follow the steps below to reproduce the attack.
## Step 1. Register with a malicious username
```bash
username: ' or '1' = '1
```
## Step 2. Trigger update or delete
Click the update or delete button on the registered account.
## Step 3. Confirm all user data is affected
Verify that the DELETE or UPDATE query was applied to all rows, not just the registered account.
For DELETE, all records across both tables are removed.
For UPDATE, all records are modified with the attacker-supplied values.
<br>
# Mitigation
- Remove the `InlineIdsOrClauseBulkIdStrategy` setting from `application.yml`
- If `InlineIdsOrClauseBulkIdStrategy` must be used, apply strict **whitelist-based input validation** on any user-supplied primary key values to reject SQL control characters
<br>
# Analysis
- KR: https://www.skshieldus.com/security-insights/reports/eqst-orm-injection-explained
- EN:
★ CVE-2026-0603 Hibernate SQL Injection PoC ★
https://github.com/user-attachments/assets/2e7c3a89-e26f-48cd-af0b-8b82d32ce71f
<br>
# Overview
> **CVE-2026-0603** is a **Second-Order SQL Injection** vulnerability in **Hibernate ORM**, a widely used Java ORM framework.
> When a user-supplied string primary key containing a malicious SQL payload is used in a bulk DELETE or UPDATE operation, Hibernate inserts the value directly into the WHERE clause without sanitization, causing **unintended mass deletion or modification of database records**.
<br>
# Affected Versions
| Category | Version |
|---|---|
| **Vulnerable** | Hibernate ORM **5.2.8 ≤ version ≤ 5.6.15** |
| **Patched** | No official patch **(5.6.x EOL)** |
<br>
# Impact
- Mass deletion of records across multiple tables
- Mass modification of records across multiple tables
- Potential exfiltration of sensitive data from the database
<br>
# Environment
```bash
docker build -t cve-2026-0603-hibernate-vuln .
docker run --rm -it -p 8080:8080 --name hibernate-vuln cve-2026-0603-hibernate-vuln
```
<br>
# PoC
After starting the vulnerable environment, follow the steps below to reproduce the attack.
## Step 1. Register with a malicious username
```bash
username: ' or '1' = '1
```
## Step 2. Trigger update or delete
Click the update or delete button on the registered account.
## Step 3. Confirm all user data is affected
Verify that the DELETE or UPDATE query was applied to all rows, not just the registered account.
For DELETE, all records across both tables are removed.
For UPDATE, all records are modified with the attacker-supplied values.
<br>
# Mitigation
- Remove the `InlineIdsOrClauseBulkIdStrategy` setting from `application.yml`
- If `InlineIdsOrClauseBulkIdStrategy` must be used, apply strict **whitelist-based input validation** on any user-supplied primary key values to reject SQL control characters
<br>
# Analysis
- KR: https://www.skshieldus.com/security-insights/reports/eqst-orm-injection-explained
- EN: