A flaw was found in Hibernate ORM in versions before 5.3.18, 5.4.18 and 5.5.0.Beta1. A SQL injection in the implementation of the JPA Criteria API can permit unsanitized literals when a literal is used in the SELECT or GROUP BY parts of the query. This flaw could allow an attacker to access unauthorized information or possibly conduct further attacks.

A flaw was found in Hibernate ORM of all versions before and including 5.4.23.Final. A SQL injection in the implementation of the JPA Criteria API can permit unsanitized literals when a literal is used in the SQL comments of the query. This flaw could allow an attacker to retrieve/update/delete unauthorized information if only the attacker already has the table names and column names.

I found a second order SQL Injection that I think is interesting enough to report. On line 27 of Hibernate's InlineIdsOrClauseBuilder, the value we put into the Id column will be reused unsanitized. We do have to activate it as described here: https://in.relation.to/2017/02/01/non-temporary-table-bulk-id-strategies/#inlineidsorclausebulkidstrategy. If the user is able to set their own ids and those ids allow non-alphanumeric characters (My POC needs these: {, }, :, \", \', =) and they are using InlineIdsOrClauseBuilder then the Application is vulnerable to attack. I have provided hibernate-poc-2.zip with a vulnerable hibernate application along with 2 python scripts as POCs. In my POCs I am able to delete all items in the table with a simple id (see hibernate-poc-attack1.py in the zip), and with a slightly more complicated Id I am able to read the first 100 characters of from the

/etc/passwd

file (see hibernate-poc-attack2.py in the zip).

Hibernate Validator before 6.2.0 and 7.0.0, by default and depending how it is used, may interpolate user-supplied input in a constraint violation message with Expression Language. This could allow an attacker to access sensitive information or execute arbitrary Java code. Hibernate Validator as of 6.2.0 and 7.0.0 no longer interpolates custom constraint violation messages with Expression Language and strongly recommends not allowing user-supplied input in constraint violation messages. <a href="https://access.redhat.com/security/cve/CVE-2020-5245">CVE-2020-5245</a> and <a href="https://access.redhat.com/security/cve/CVE-2025-4428">CVE-2025-4428</a> are examples of related, downstream vulnerabilities involving Expression Language intepolation of user-supplied data.

Hibernate Validator before 6.2.0 and 7.0.0, by default and depending how it is used, may interpolate user-supplied input in a constraint violation message with Expression Language. This could allow an attacker to access sensitive information or execute arbitrary Java code. Hibernate Validator as of 6.2.0 and 7.0.0 no longer interpolates custom constraint violation messages with Expression Language and strongly recommends not allowing user-supplied input in constraint violation messages. CVE-2020-5245 and CVE-2025-4428 are examples of related, downstream vulnerabilities involving Expression Language intepolation of user-supplied data.

A flaw was found in hibernate-validator's 'isValid' method in the org.hibernate.validator.internal.constraintvalidators.hv.SafeHtmlValidator class, which can be bypassed by omitting the tag ending in a less-than character. Browsers may render an invalid html, allowing HTML injection or Cross-Site-Scripting (XSS) attacks.

IssueDescription:

It was discovered that the implementation of org.hibernate.validator.util.ReflectionHelper together with the permissions required to run Hibernate Validator under the Java Security Manager could allow a malicious application deployed in the same application container to execute several actions with escalated privileges, which might otherwise not be possible. This flaw could be used to perform various attacks, including but not restricted to, arbitrary code execution in systems that are otherwise secured by the Java Security Manager.