Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
도구/GitHubGitHub/eqstlab/cve-2026-0603
Vulnerability AnalysisExploitationWeb Application ExploitationPenetration TestingLearning & EducationDatabase Security
GitHubeqstlab/cve-2026-0603

CVE-2026-0603

Hibernate ORM Second-Order SQL Injection

저장소 보기
111일 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
요청한 언어로 콘텐츠를 사용할 수 없습니다. 영어 버전을 표시합니다.

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


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.


Affected Versions

도구 다운로드
CategoryVersion
VulnerableHibernate ORM 5.2.8 ≤ version ≤ 5.6.15
PatchedNo official patch (5.6.x EOL)

Impact

  • Mass deletion of records across multiple tables
  • Mass modification of records across multiple tables
  • Potential exfiltration of sensitive data from the database

Environment

root@kitploit:~
docker build -t cve-2026-0603-hibernate-vuln .
docker run --rm -it -p 8080:8080 --name hibernate-vuln cve-2026-0603-hibernate-vuln

PoC

After starting the vulnerable environment, follow the steps below to reproduce the attack.

Step 1. Register with a malicious username

root@kitploit:~
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.


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

Analysis

  • KR: https://www.skshieldus.com/security-insights/reports/eqst-orm-injection-explained
  • EN: https://www.skshieldus.com/en/report?tab=eqst