T09 · Insecure Skill Coding Practices
- Location
SKILL.md:146- Finding
Destructive Database Operations Lack Mandatory Execution Safeguards
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 39, 146–147, and 371
Vulnerability Type: Unsafe execution of destructive database operations
Risk Level: MediumVulnerable Code Snippet
yaml tools: ["read", "write", "exec"]sql DROP TABLE TRUNCATEThe skill also states that its core functionality requires command execution capability.
Technical Analysis
The skill requests
execaccess and explicitly supports irreversible or destructive database operations, includingDROP TABLEandTRUNCATE. The only documented protection is a general warning to use these operations cautiously. No enforceable control requires:- Explicit confirmation immediately before execution
- Verification of the target host, database, schema, and environment
- Production-environment blocking
- Backup or recovery-point validation
- A dry run or SQL-only generation mode
- Use of a least-privilege database account
- Transactional or migration-based execution where supported
Because the skill is driven by natural-language instructions, an ambiguous request, operator error, or malicious instruction embedded in processed content could cause the Agent to execute destructive SQL through its command-execution capability.
Attack Path
- The Agent loads the skill with
execaccess. - Database credentials are made available through environment variables.
- A user request, copied document, or untrusted task content instructs the Agent to reset, clear, recreate, or remove a database object.
- The Agent interprets the instruction as authorization to issue
DROP TABLEorTRUNCATE. - The Agent invokes a database client through
execand connects using the available credentials. - The destructive statement executes without a mandatory approval gate, target verification, or backup check.
- Data or schema objects are permanently removed within the permissions of the configured data ...[truncated 720 chars]
- Remediation
View remediation
Remediation Suggestions
- Default to generating SQL for review rather than executing it.
- Require explicit, operation-specific confirmation immediately before every destructive command.
- Display the exact SQL and the resolved host, port, database, schema, and affected objects before requesting confirmation.
- Reject implicit confirmation inherited from an earlier message or included in untrusted task content.
- Block destructive operations against production targets by default and require a separate, auditable override.
- Require verification of a recent recoverable backup or snapshot before execution.
- Use dedicated least-privilege accounts that cannot drop or truncate objects unless the task specifically requires those permissions.
- Add allowlists for permitted databases, schemas, and operation types.
- Prefer reviewed migration tooling and reversible changes where possible.
- Record the approved SQL, target identity, approving user, execution time, and result in an audit log without exposing credentials.
- Abort if the target environment cannot be identified reliably or if the estimated affected scope differs from the approved scope.
