T09 · Insecure Skill Coding Practices
- Location
scripts/manage.py:49- Finding
SQL Injection Through Unquoted Database Index Identifiers
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a database migration helper, but it can run destructive database changes automatically without sufficient review controls.
Review this carefully before installing. Use it only on disposable or backed-up databases unless it is changed to validate in an isolated database, quote SQL identifiers safely, generate reports by default, and require explicit approval before writing migration files or dropping indexes.
scripts/manage.py:49SQL Injection Through Unquoted Database Index Identifiers
scripts/manage.py:26Pending Migration Validation Executes Untrusted SQL Against the Target Database
scripts/manage.py:63Generated Cleanup Migration Can Overwrite Existing Files or Follow Symbolic Links
scripts/manage.py:7Legitimate Indexes Are Automatically Dropped Based Only on Name Fragments
This is a true security and safety issue because the declared behavior understates materially destructive actions: generating new migration files, dropping indexes, and not actually applying pending migrations as advertised. In a database administration context, behavior-description mismatch is especially dangerous because operators may authorize execution expecting validation or routine migration application, while the skill can silently perform schema-altering actions that affect integrity, availability, and recovery procedures.
The validation phase reads each pending migration and runs it with executescript() on the live target database connection, which means untrusted migration SQL is actually executed rather than parsed or sandbox-checked. Although the code rolls back afterward, migration scripts can still trigger dangerous side effects such as PRAGMAs, DDL behavior, resource exhaustion, or partial/non-transactional effects depending on SQLite semantics, making 'validation' effectively code execution against production state.
The script goes beyond analysis and automatically generates DROP INDEX statements, writes them as a migration file, and immediately executes them. This creates an unsafe path where heuristically identified index names are treated as redundant and deleted without review, enabling accidental performance degradation or disruption if naming patterns match legitimate indexes.
The skill appears capable of reading and writing files but does not declare any tool scope or permission boundaries. For a schema-management skill that can generate migration files, missing explicit scoping increases the risk of unintended filesystem access, privilege creep, and misuse by downstream agents or operators who cannot accurately assess what the skill is allowed to do.
The skill description does not clearly warn that it can modify the target database and create cleanup migrations, despite operating in a high-impact schema-management context. Without an explicit warning, users may invoke it in production or against sensitive databases without understanding that it can perform destructive or hard-to-reverse changes such as dropping indexes, which can impair performance or break application assumptions.
The code is presented as index analysis, but the subsequent logic performs destructive cleanup by dropping indexes. This mismatch is dangerous because operators or upstream automation may invoke the tool expecting read-only diagnostics, while it actually mutates schema state and can remove important indexes unexpectedly.
The script writes a migration file and applies destructive schema changes with no user-facing warning, dry run, or confirmation step. In the context of a schema-management skill, this is especially risky because users may reasonably expect controlled migration workflows, and silent index deletion can cause operational outages or hard-to-diagnose performance regressions.
No suspicious patterns detected.