SQL Injection Isn't Dead: Smuggling Queries At The Protocol Level

The talk opens with a prepared-statement request handler that looks safe against SQL injection, then argues that the real attack surface sits lower, in the binary wire protocols applications use to talk to databases. The speaker treats the idea as request smuggling moved down to that layer, and compares how PostgreSQL, MySQL and MongoDB frame their messages with type or opcode fields and length prefixes.

The central finding is an integer truncation bug in several client libraries. A length computed as a 64-bit value is cast down to 32 bits, so an oversized query wraps to a small number. The server then reads attacker-supplied bytes as a fresh message, which can carry extra statements such as inserts. Alignment is handled with an alternating byte pattern that succeeds within two attempts. Vulnerable Go, .NET and Rust drivers were identified. Harbor, a container registry, was exploitable in its default configuration before version 2.11, and a demo showed an injected admin account. Java and JavaScript were not exploitable mainly because their runtimes cannot hold strings large enough to trigger the overflow.

The speaker notes that body-size limits usually block such payloads, but they can be bypassed through unprotected endpoints, compressed input, WebSockets or server-side generation of large values. The main takeaway is that integer overflows still matter in memory-safe languages, so developers should validate lengths in code rather than rely on upstream limits. The talk closes by suggesting further research into other protocols with fixed-width length fields and new ways to deliver large payloads, with a warning against testing live targets without consent.