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).