HNHacker News
TopNewBestAskShowJobs

opoka

1 karma · joined January 28, 2026

submissionscomments
opoka··on The Hazardous Interface: SQL Injection Is a Protocol Defect (2026) [pdf]
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··on The Hazardous Interface: SQL Injection Is a Protocol Defect (2026) [pdf]
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.