T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:337
- Finding
- Overbroad Database Session Termination Procedure## Vulnerability Details **File Location**: `SKILL.md`, lines 337-340 **Vulnerability Type**: Unsafe production database operation **Risk Level**: Medium ```sql SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle' AND query_start < now() - interval '10 minutes'; ``` ### Technical Analysis The runbook instructs responders to terminate every database session classified as idle for more than ten minutes. It does not restrict the operation to the affected application, database, user, tenant, or incident. It also does not exclude privileged accounts, operational sessions, protected workloads, or the responder's own backend. An idle connection may still belong to a healthy application connection pool or operational process. Terminating all matching sessions can therefore disrupt unrelated workloads and increase the incident's blast radius. The procedure lacks a preview query, authorization gate, confirmation step, maintenance-window requirement, and post-operation recovery instructions. The related command at `SKILL.md:152`, `SELECT pg_terminate_backend(pid);`, is also invalid as written because it provides neither a concrete PID nor a source relation. Under incident pressure, a responder may attempt to repair it by adding an insufficiently constrained query. ### Attack Path 1. A database incident or apparent connection-pool exhaustion triggers use of the runbook. 2. A responder connects with a role authorized to call `pg_terminate_backend`. 3. The responder executes the supplied statement without first identifying which applications own the matching sessions. 4. PostgreSQL terminates all accessible sessions matching the broad idle-time condition. 5. Connection pools reconnect simultaneously, transactions or operational workflows are interrupted, and unrelated services may experience errors or a connection storm. This is primarily an unsafe operational failure path rather than a privilege-escala ...[truncated 637 chars]
- Remediation
- ## Remediation Suggestions - Begin with a read-only preview that displays each candidate's PID, database, user, application name, client address, state-change time, and query. - Require explicit filters for the affected database, application, and service account. - Exclude the current backend with `pid <> pg_backend_pid()`. - Exclude database administrators, replication processes, monitoring users, and other protected operational accounts. - Prefer application-level pool recycling or targeted termination of individually reviewed PIDs. - Require incident-commander or database-owner approval before terminating multiple sessions. - Record selected PIDs and the reason for termination in the incident timeline. - Apply a small batch limit, monitor reconnection behavior, and stop if error rates or connection attempts rise. - Add verification and recovery procedures for application connectivity, pool health, transaction failures, and database load.