Incomplete cleanup occurs when an application fails to properly remove or clear temporary files, database connections, cached data, or other resources after…
Incomplete cleanup occurs when an application fails to properly remove or clear temporary files, database connections, cached data, or other resources after they are no longer needed. This weakness can expose sensitive information left behind in temporary storage, exhaust system resources, or leave the application in an inconsistent state that attackers can exploit.
Applications often create temporary resources—session files, cache entries, uploaded file copies, database connections, or in-memory buffers—to handle requests or operations. If the code does not explicitly clean up these resources when they are no longer needed, they accumulate or persist longer than intended. This is especially problematic in error paths: when an exception occurs or a request is interrupted, cleanup code may be skipped entirely. Additionally, developers sometimes assume that operating systems or frameworks will automatically clean up after them, but this assumption often fails for application-level resources like database connections or sensitive data in memory.
Incomplete cleanup can lead to information disclosure if temporary files containing passwords, API keys, or user data are left on disk or in shared memory. Resource exhaustion—where connections, file handles, or memory are never released—can cause denial of service by making the application unresponsive or crashing it. In multi-user environments, one user's temporary data may be accessible to another if cleanup is incomplete. Long-lived sessions or cached credentials that are not properly cleared can also enable session hijacking or privilege escalation.
import tempfile
import sqlite3
def process_user_data(user_id):
# Create a temporary file without cleanup
temp_file = tempfile.NamedTemporaryFile(mode='w', delete=False)
temp_file.write(f"user_id={user_id},password=secret123")
temp_file.close()
# Database connection never closed
conn = sqlite3.connect(':memory:')
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
return cursor.fetchall()Why it's vulnerable:
The temporary file is created with delete=False but never explicitly removed, leaving sensitive data on disk. The database connection is never closed, leaking a resource that could accumulate across multiple calls.
import tempfile
import sqlite3
import os
def process_user_data(user_id):
# Use context manager for automatic cleanup
with tempfile.NamedTemporaryFile(mode='w', delete=True) as temp_file:
temp_file.write(f"user_id={user_id}")
temp_file.flush()
# Work with temp_file here
# File is automatically deleted when exiting the context
# Use context manager for database connection
with sqlite3.connect(':memory:') as conn:
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
return cursor.fetchall()
# Connection is automatically closed<?php
function process_upload($file_path) {
// Create a temporary copy
$temp_copy = tempnam(sys_get_temp_dir(), 'upload_');
copy($file_path, $temp_copy);
// Process the file
$data = file_get_contents($temp_copy);
// Temporary file is never deleted
// Database connection opened but never closed
$mysqli = new mysqli("localhost", "user", "pass", "db");
$result = $mysqli->query("SELECT * FROM files");
return $data;
}
?>Why it's vulnerable:
The temporary file created by tempnam() is never deleted, accumulating on disk. The MySQLi connection is never explicitly closed, potentially exhausting available connections.
<?php
function process_upload($file_path) {
// Create a temporary copy with guaranteed cleanup
$temp_copy = tempnam(sys_get_temp_dir(), 'upload_');
try {
copy($file_path, $temp_copy);
$data = file_get_contents($temp_copy);
// Use connection with explicit cleanup
$mysqli = new mysqli("localhost", "user", "pass", "db");
$result = $mysqli->query("SELECT * FROM files");
$mysqli->close();
return $data;
} finally {
// Ensure temporary file is always deleted
if (file_exists($temp_copy)) {
unlink($temp_copy);
}
}
}
?>Check your system's temporary directory (/tmp on Linux, %TEMP% on Windows) for unexpectedly large numbers of old files or files with sensitive-looking names. Monitor database connection pools or file descriptor counts for steady growth over time without corresponding decreases, which may indicate leaked resources. Review application logs for repeated connection timeout or "too many open files" errors.
