Hi HN. We analyzed 1,374 CVEs across MySQL, PostgreSQL, MariaDB, MongoDB, and SQLite.
Key findings:
- Interface Hazards (design-transferred risks) outnumber Implementation Defects 3:1
- 79% of SQL injection occurs downstream of the database engine
- ORMs—built specifically to fix this—still fail at 88%
The formal proof (Section 1.1) shows string concatenation is non-composable with parsing. Injection isn't a bug to patch; it's a mathematical property of the interface.
Section 1.2 makes the comparison to W^X: operating systems enforce code/data separation at the hardware level. Databases violate it at the application level. We regressed.
Full methodology is auditable via API. Data and code in the repo.
Happy to answer questions.
fiedzia•1w ago
> ORMs—built specifically to fix this—still fail at 88%
How so? The only way to do anything dangerous using any orm I've used was when I needed to do something orm doesn't support and I had to extend it, operating at a text layer (custom db syntax or non-standard sql extension). 99% of sql users wouldn't event know how to get there.
opoka•1w ago
The 88% figure isn't failure rate in normal operation — it's the Interface Hazard rate when ORMs fail.
You're correct that ORMs work correctly 99.9% of the time. That's exactly the point. The paper argues that "correct 99.9% of the time" isn't a security model.
When we analyzed ORM-related CVEs, 88% were Interface Hazards: vulnerabilities that exist because the string layer underneath is still reachable. Custom SQL extensions (like you mention), raw query escapes, edge cases in query generation. The ORM does its job until it doesn't — and when it doesn't, the hazard manifests identically to not having an ORM at all.
The existence of any ORM CVEs proves the thesis: mitigation layers cannot fix a broken protocol. They reduce attack surface, they don't eliminate the hazard. A type-safe interface would make these CVEs impossible by construction — there would be no string layer to escape to.
opoka•1w ago
Key findings:
- Interface Hazards (design-transferred risks) outnumber Implementation Defects 3:1 - 79% of SQL injection occurs downstream of the database engine - ORMs—built specifically to fix this—still fail at 88%
The formal proof (Section 1.1) shows string concatenation is non-composable with parsing. Injection isn't a bug to patch; it's a mathematical property of the interface.
Section 1.2 makes the comparison to W^X: operating systems enforce code/data separation at the hardware level. Databases violate it at the application level. We regressed.
Full methodology is auditable via API. Data and code in the repo.
Happy to answer questions.
fiedzia•1w ago
How so? The only way to do anything dangerous using any orm I've used was when I needed to do something orm doesn't support and I had to extend it, operating at a text layer (custom db syntax or non-standard sql extension). 99% of sql users wouldn't event know how to get there.
opoka•1w ago
You're correct that ORMs work correctly 99.9% of the time. That's exactly the point. The paper argues that "correct 99.9% of the time" isn't a security model. When we analyzed ORM-related CVEs, 88% were Interface Hazards: vulnerabilities that exist because the string layer underneath is still reachable. Custom SQL extensions (like you mention), raw query escapes, edge cases in query generation. The ORM does its job until it doesn't — and when it doesn't, the hazard manifests identically to not having an ORM at all.
The existence of any ORM CVEs proves the thesis: mitigation layers cannot fix a broken protocol. They reduce attack surface, they don't eliminate the hazard. A type-safe interface would make these CVEs impossible by construction — there would be no string layer to escape to.