
CVE-2026-0603 — Updated!
Hibernate ORM SQL-Injection zweiter Ordnung
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
Überblick
CVE-2026-0603 ist eine Second-Order SQL Injection-Schwachstelle in Hibernate ORM, einem weit verbreiteten Java-ORM-Framework.
Wenn ein benutzerseitig bereitgestellter String-Primärschlüssel, der eine bösartige SQL-Nutzlast enthält, in einer Bulk-DELETE- oder UPDATE-Operation verwendet wird, fügt Hibernate den Wert direkt in die WHERE-Klausel ein, ohne ihn zu bereinigen, was zu unbeabsichtigter massenhafter Löschung oder Änderung von Datenbankeinträgen führt.
Betroffene Versionen
| Kategorie | Version |
|---|---|
| Anfällig | Hibernate ORM 5.2.8 ≤ Version ≤ 5.6.15 |
| Gepatcht | Kein offizieller Patch (5.6.x EOL) |
Auswirkung
- Massenhaftes Löschen von Datensätzen über mehrere Tabellen hinweg
- Massenhafte Änderung von Datensätzen über mehrere Tabellen hinweg
- Mögliche Exfiltration sensibler Daten aus der Datenbank
Umgebung
docker build -t cve-2026-0603-hibernate-vuln .
docker run --rm -it -p 8080:8080 --name hibernate-vuln cve-2026-0603-hibernate-vuln
PoC
Nach dem Start der anfälligen Umgebung folgen Sie den untenstehenden Schritten, um den Angriff zu reproduzieren.
Schritt 1. Registrierung mit einem bösartigen Benutzernamen
username: ' or '1' = '1
Schritt 2. Update oder Delete auslösen
Klicken Sie auf die Schaltfläche „Update" oder „Delete" beim registrierten Konto.
Schritt 3. Bestätigen, dass alle Benutzerdaten betroffen sind
Verifizieren Sie, dass die DELETE- oder UPDATE-Abfrage auf alle Zeilen angewendet wurde, nicht nur auf das registrierte Konto. Bei DELETE werden alle Datensätze in beiden Tabellen entfernt. Bei UPDATE werden alle Datensätze mit den vom Angreifer bereitgestellten Werten geändert.
Gegenmaßnahmen
- Entfernen Sie die Einstellung
InlineIdsOrClauseBulkIdStrategyausapplication.yml - Falls
InlineIdsOrClauseBulkIdStrategyverwendet werden muss, wenden Sie eine strikte Whitelist-basierte Eingabevalidierung auf alle benutzerseitig bereitgestellten Primärschlüsselwerte an, um SQL-Steuerzeichen abzulehnen