Security

What is Dangling Database Cursor ('Cursor (CWE-619)?

Learn how dangling database cursors can leave your application data vulnerable. Get real-world code examples and framework-specific fixes to prevent CWE-619.

SP
Shreya Pillai July 29, 2026 5 min read Security
AI-friendly summary

What it is: Dangling Database Cursor ('Cursor Injection') (CWE-619) is a vulnerability that occurs when database cursors are not properly closed, leaving them accessible to other users.

Why it matters: This can lead to unauthorized access and modification of application data due to uncontrolled cursor usage.

How to fix it: Ensure that all database cursors are closed immediately after use, even if exceptions occur during their operation.

TL;DR: Dangling Database Cursor (‘Cursor Injection’) (CWE-619) is a vulnerability where unclosed database cursors can be accessed by unauthorized users, leading to potential data breaches. Ensure proper cursor management practices to prevent this issue.

Field Value
CWE ID CWE-619
OWASP Category Not directly mapped
CAPEC None known
Typical Severity High
Affected Technologies database management systems
Detection Difficulty Moderate
Last Updated 2026-07-29

What is Dangling Database Cursor (‘Cursor Injection’)?

Dangling Database Cursor (‘Cursor Injection’) (CWE-619) is a type of vulnerability that occurs when a database cursor is not properly closed after use, leaving it accessible to other users with the same privileges. As defined by the MITRE Corporation under CWE-619, and classified by the OWASP Foundation as Not directly mapped.

Quick Summary

Dangling Database Cursor (‘Cursor Injection’) poses significant risks to application security by allowing unauthorized access to sensitive data through improperly closed database cursors. This vulnerability can lead to severe consequences such as unauthorized read or modification of application data. Jump to: Overview · How It Works · Business Impact · Attack Scenario · Detection · Fixing · Framework-Specific Fixes · Ask AI · Best Practices · FAQ · Related Vulnerabilities

Jump to: Quick Summary · Dangling Database Cursor (‘Cursor Injection’) Overview · How Dangling Database Cursor (‘Cursor Injection’) Works · Business Impact of Dangling Database Cursor (‘Cursor Injection’) · Dangling Database Cursor (‘Cursor Injection’) Attack Scenario · How to Detect Dangling Database Cursor (‘Cursor Injection’) · How to Fix Dangling Database Cursor (‘Cursor Injection’) · Framework-Specific Fixes for Dangling Database Cursor (‘Cursor Injection’) · How to Ask AI to Check Your Code for Dangling Database Cursor (‘Cursor Injection’) · Dangling Database Cursor (‘Cursor Injection’) Best Practices Checklist · Dangling Database Cursor (‘Cursor Injection’) FAQ · Vulnerabilities Related to Dangling Database Cursor (‘Cursor Injection’) · References · Scan Your Own Site

Dangling Database Cursor (‘Cursor Injection’) Overview

What: Dangling Database Cursor (‘Cursor Injection’) is a security vulnerability where database cursors are left open after use, making them accessible to unauthorized users.

Why it matters: This can lead to unauthorized access and modification of application data due to uncontrolled cursor usage.

Where it occurs: Primarily in applications that manage database connections without proper handling of cursors.

Who is affected: Any system or application using databases where cursors are not properly managed.

Who is NOT affected: Systems implementing robust cursor management practices, ensuring all cursors are closed immediately after use.

How Dangling Database Cursor (‘Cursor Injection’) Works

Root Cause

The root cause of this vulnerability lies in the failure to close database cursors properly after they have been used. This leaves the cursors accessible by other users who may exploit them for unauthorized access or modification of data.

Attack Flow

  1. The attacker identifies an unclosed cursor.
  2. The attacker gains access to the unclosed cursor and uses it to read or modify application data.
  3. The attacker exploits the vulnerability to perform actions that should be restricted based on user permissions.

Prerequisites to Exploit

  • An open database cursor must exist.
  • The attacker needs to have sufficient privileges to access the unclosed cursor.

Vulnerable Code

DECLARE cursor_name CURSOR FOR SELECT * FROM sensitive_table;
OPEN cursor_name;
-- Other operations

This code does not include a proper mechanism for closing the cursor after use, leaving it open and accessible by other users.

Secure Code

DECLARE cursor_name CURSOR FOR SELECT * FROM sensitive_table;
OPEN cursor_name;
-- Other operations
CLOSE cursor_name;

The secure version ensures that the cursor is closed immediately after its usage, preventing unauthorized access.

Business Impact of Dangling Database Cursor (‘Cursor Injection’)

Confidentiality: Unauthorized users can read sensitive data through unclosed cursors.

  • Example: An attacker reads confidential user information from a database table.

Integrity: Unauthorized modification of application data is possible due to uncontrolled cursor usage.

  • Example: An attacker modifies financial transaction records through an open cursor.

Availability: While not directly impacting availability, unauthorized access can disrupt normal operations by altering critical data.

Business Consequences:

  1. Financial loss from unauthorized transactions or data breaches.
  2. Compliance issues with regulatory requirements for data protection.
  3. Damage to reputation and trust among users due to security incidents.

Dangling Database Cursor (‘Cursor Injection’) Attack Scenario

  1. The attacker identifies an unclosed database cursor in the application’s codebase.
  2. The attacker gains access to the unclosed cursor through a vulnerability or misconfiguration.
  3. Using the open cursor, the attacker reads sensitive data from the database.
  4. The attacker modifies critical records using the unauthorized access provided by the open cursor.

How to Detect Dangling Database Cursor (‘Cursor Injection’)

Manual Testing

  • Review code for proper cursor management practices.
  • Ensure cursors are closed immediately after use and handle exceptions properly.

Automated Scanners (SAST / DAST)

Static analysis can identify unclosed database cursors, while dynamic testing can confirm their accessibility by unauthorized users.

PenScan Detection

PenScan’s scanner engines such as ZAP and Wapiti can detect unclosed cursors in the application codebase.

False Positive Guidance

A false positive may occur if a cursor is closed properly but appears open due to timing issues. Ensure that cursors are always closed immediately after use to avoid this.

How to Fix Dangling Database Cursor (‘Cursor Injection’)

  • Close database cursors immediately after they have been used.
  • Handle exceptions during cursor operations to ensure proper closure even in error conditions.
  • Implement robust cursor management practices throughout the application codebase.

Framework-Specific Fixes for Dangling Database Cursor (‘Cursor Injection’)

Java

try (ResultSet rs = stmt.executeQuery("SELECT * FROM sensitive_table")) {
    // Process result set
}

Using try-with-resources ensures that the ResultSet is closed automatically after use, preventing dangling cursors.

Node.js

const { Pool } = require('pg');
const pool = new Pool();

pool.query('SELECT * FROM sensitive_table', (err, res) => {
    if (err) throw err;
    // Process result set
    res.rows.forEach(row => console.log(row));
    res.release();  // Explicitly release the cursor after use.
});

Releasing the cursor explicitly ensures it is closed and not left open.

Python/Django

with connection.cursor() as cursor:
    cursor.execute("SELECT * FROM sensitive_table")
    rows = cursor.fetchall()
    # Process result set

Using a context manager to manage the cursor ensures automatic closure after use.

How to Ask AI to Check Your Code for Dangling Database Cursor (‘Cursor Injection’)

Review the following Python code block for potential CWE-619 Dangling Database Cursor (‘Cursor Injection’) vulnerabilities and rewrite it using try-with-resources:

cursor.execute("SELECT * FROM sensitive_table")
rows = cursor.fetchall()
Copy-paste prompt

Review the following Python code block for potential CWE-619 Dangling Database Cursor ('Cursor Injection') vulnerabilities and rewrite it using try-with-resources: [paste code here]

Dangling Database Cursor (‘Cursor Injection’) Best Practices Checklist

✅ Close database cursors immediately after they have been used. ✅ Handle exceptions during cursor operations to ensure proper closure even in error conditions. ✅ Implement robust cursor management practices throughout the application codebase. ✅ Use try-with-resources or similar constructs to manage cursors automatically. ✅ Regularly review and audit code for proper cursor handling.

Dangling Database Cursor (‘Cursor Injection’) FAQ

How does a dangling database cursor occur?

A dangling database cursor occurs when a cursor is not properly closed after use, leaving it accessible by other users with the same privileges.

What are the potential impacts of a dangling database cursor vulnerability?

It can lead to unauthorized access and modification of application data due to uncontrolled cursor usage.

Can you provide an example of vulnerable code for CWE-619?

Vulnerable code does not properly close cursors after use, leaving them open and accessible by other users.

How can I detect dangling database cursors in my application?

Use automated scanners to identify unclosed cursors or manually review the code for proper cursor management practices.

What is the best practice to prevent CWE-619?

Ensure that all cursors are closed immediately after use and handle exceptions properly to avoid leaving cursors open.

How can I fix a dangling database cursor issue in my application?

Close cursors as soon as they are no longer needed, even if an exception occurs during their usage.

What is the impact of CWE-619 on business operations?

It can result in unauthorized data access and modification, leading to financial loss and reputational damage.

CWE Name Relationship
402 Transmission of Private Resources into a New Sphere (‘Resource Leak’) ChildOf

References

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Dangling Database Cursor (‘Cursor Injection’) and other risks before an attacker does.