CWE-619, Dangling Database Cursor ('Cursor Injection'), covers cursors that are not closed properly. A cursor left open can become reachable by other users while keeping the privileges it was first given. It applies to SQL and database server code.
How it happens
A cursor is a handle to a query result. If code opens one and then fails before closing it, the handle may hang around. MITRE's own example of how this arises is an unhandled exception: the error path skips the cleanup, and the cursor stays alive.
Whether this matters depends on the cursor's role. A cursor created in a privileged context and left dangling carries that context with it.
What an attacker gains
The record lists confidentiality and integrity impact: reading application data and modifying application data. MITRE also notes that SQL injection attacks are commonly possible, depending on the cursor's role.
How to find it
The record has no listed detection methods, so rely on review. Look for every place a cursor is opened and trace each exit path, especially exception handlers and early returns. Any path that reaches the end of the routine without closing the cursor is a candidate.
How to fix it
MITRE gives two rules:
- Close cursors immediately after access to them is complete.
- Make sure cursors are closed if exceptions occur.
In most application languages that means a finally block or a context manager, so cleanup runs on every path. In database procedure code, use the exception handler to close the cursor as well.
Quick check
What is the most common way a cursor ends up dangling?
An unhandled exception. The error path skips the close call, so the cursor stays open.
