Database Tester

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:55 AM UTC
• Version: 1.0.0

Overview

This database-testing skill is not malicious, but it needs Review because its examples can delete or change real database data and alter server-wide MySQL settings without clear safety boundaries.

Install only if users understand that examples must be adapted before execution. Use an isolated non-production database, disposable test records, least-privileged credentials, explicit transactions or snapshots, and DBA-approved procedures for any server-wide settings. Do not run the fixed-id DELETE, deadlock, or SET GLOBAL examples against shared or production systems as written.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:37

Finding

Database Password Exposed Through Command-Line Arguments

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, line 37
Vulnerability Type: Credential exposure through process arguments
Risk Level: Medium

Vulnerable Code:

bash

# MySQL
mysql -h $DB_HOST -u $DB_USER -p$DB_PASS $DB_NAME -e "SHOW TABLES;"

Technical Analysis

The MySQL password is expanded directly into the command-line argument vector through -p$DB_PASS. Depending on the operating system and execution environment, command arguments can be observed through process inspection, shell tracing, CI/CD logs, audit records, terminal history, or monitoring software.

Although the secret originates from an environment variable, expanding it into an argument removes much of the protection gained by keeping it out of the command itself. This issue does not independently create database privileges, but it can disclose credentials carrying all permissions assigned to DB_USER.

Attack Path

1. An operator exports a valid database password as DB_PASS.
2. The operator or agent runs the documented MySQL command.
3. The shell expands $DB_PASS into the MySQL process arguments.
4. A local user, monitoring service, shell trace, or CI logging system captures the command line.
5. The exposed username and password are reused to connect to the database.
6. The attacker performs operations allowed by the compromised database account.

Impact Assessment

A successful disclosure grants access equivalent to the affected database account. Depending on its assigned permissions, this could permit reading sensitive records, modifying or deleting data, executing stored routines, or changing database configuration. The scope is limited by the privileges of DB_USER and database network accessibility.

Remediation

View remediation

Remediation Suggestions

• Do not provide passwords with the MySQL -pPASSWORD command-line form.
• Prefer mysql_config_editor and an encrypted login path:

  bash

  mysql_config_editor set --login-path=db-test --host="$DB_HOST" --user="$DB_USER" --password
  mysql --login-path=db-test "$DB_NAME" -e "SHOW TABLES;"
  

• Alternatively, use a temporary MySQL option file protected with mode 0600, and securely delete it after use.
• Use an interactive password prompt where automation is not required.
• Disable shell tracing around secret-bearing operations and ensure CI systems mask database credentials.
• Provision a dedicated, least-privileged testing account and rotate any credential suspected of appearing in process or build logs.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:89

Finding

Destructive Database Tests Target Fixed Existing Records Without Isolation Safeguards

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 89-91 and 256-260
Vulnerability Type: Unsafe destructive database testing
Risk Level: Medium

Vulnerable Code:

sql

-- CASCADE: Delete parent → verify child behavior
DELETE FROM users WHERE id = 1;
-- Verify: orders for user_id=1 are CASCADE deleted/SET NULL per FK rule

python

def test_cascade_delete(self, db):
    cur = db.cursor()
    cur.execute("DELETE FROM users WHERE id = %s", (1,))
    cur.execute("SELECT COUNT(*) FROM orders WHERE user_id = %s", (1,))
    assert cur.fetchone()[0] == 0  # orders cascade deleted

Technical Analysis

Both examples target the fixed identifier id = 1, which may represent a legitimate user in an existing database. The standalone SQL example is not enclosed in an explicit transaction and does not include a rollback. It can therefore permanently delete the parent row and trigger cascading deletion or modification of related records.

The Python fixture shown elsewhere calls rollback() during teardown, which reduces risk for transactional tables. However, the test still operates on a pre-existing record instead of creating a disposable fixture. Rollback also cannot reliably reverse non-transactional storage-engine changes, independently committed stored-procedure behavior, external callbacks, audit events, or other out-of-transaction side effects.

Attack Path

1. An operator configures the test with credentials for a shared, staging, or production database.
2. The database contains a legitimate user whose identifier is 1.
3. The operator executes the documented cascade test without creating isolated test data.
4. The user row is deleted.
5. Foreign-key actions cascade the deletion or modification to orders and other related records.
6. If no effective rollback occurs, the changes become permanent; external side effects may remain even if the database transaction is rolled back ...[truncated 417 chars]

Remediation

View remediation

Remediation Suggestions

• Explicitly require a dedicated disposable test database and prohibit execution against production or shared environments.
• Create a unique test user and dependent records during test setup rather than assuming that user ID 1 is disposable.
• Record the generated identifier and delete only that fixture.
• Wrap every destructive example in an explicit transaction followed by ROLLBACK.
• Add a fail-closed environment check, such as validating an allowlisted database name and requiring a dedicated test-mode flag.
• Use a least-privileged test account restricted to the disposable schema.
• Confirm that all tested tables use transactional storage and mock or disable external callbacks during database tests.
• Restore a verified snapshot after migration or cascade tests where transaction rollback cannot cover all side effects.

T05 · Unauthorized Access and Privilege Escalation

Note

• Location: SKILL.md:168

Finding

Performance Test Modifies Server-Global MySQL Configuration

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 168-170
Vulnerability Type: Unrestricted use of privileged server-global configuration
Risk Level: Low

Vulnerable Code:

sql

-- MySQL: Enable slow query log
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- seconds

Technical Analysis

The performance-testing instructions modify global MySQL variables rather than settings isolated to a test session. These statements require elevated administrative privileges and affect unrelated connections on the same server.

Enabling broad slow-query logging with a low threshold may increase disk consumption and I/O load. Logged SQL can also contain sensitive literals or business data. The instructions do not require administrator authorization, capture existing values, restrict execution to a test server, define log access and retention controls, or restore the original settings.

This example does not itself bypass MySQL authorization; execution depends on the caller already possessing the required administrative privilege. The security concern is that the Skill directs use of privileges broader than ordinary database testing requires and may leave server-wide changes active.

Attack Path

1. The operator supplies an account with privileges sufficient to change global MySQL variables.
2. The operator executes the documented performance commands on a shared server.
3. Slow-query logging is enabled globally and the threshold is reduced to one second.
4. Queries from unrelated applications are written to the slow-query log.
5. The additional logging consumes storage and I/O resources, and sensitive query text becomes available to users or services with log access.
6. Because the original values are not restored, the exposure and operational impact continue after testing.

Impact Assessment

No new privilege is directly obtained because MySQL must authorize the commands. H ...[truncated 316 chars]

Remediation

View remediation

Remediation Suggestions

• Prefer existing performance-schema data, EXPLAIN ANALYZE, and other diagnostics that do not require global configuration changes.
• Require explicit database-administrator approval before changing global variables.
• Restrict this procedure to isolated non-production servers.
• Capture the current values before testing and restore them in a guaranteed cleanup step:

  sql

  SELECT @@GLOBAL.slow_query_log, @@GLOBAL.long_query_time;
  

• Use the least-privileged account appropriate for routine tests and a separately controlled administrative workflow when global changes are genuinely necessary.
• Configure log-file permissions, redaction, rotation, retention, storage quotas, and monitoring before enabling query logging.
• Document the expected test duration and verify afterward that the original settings have been restored.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (7)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The destructive SQL examples include DELETE and intentionally failing INSERT statements without an explicit warning to use only test data or a rollback-safe environment. In a testing skill, such examples are plausible, but absent guardrails they can cause data loss, referential changes, or operational disruption if copied into staging or production systems.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill explicitly says it is not for database administration, yet it instructs users to change MySQL global server settings (SET GLOBAL slow_query_log, SET GLOBAL long_query_time). Those commands are administrative actions that affect the whole server, may require elevated privileges, and can alter production behavior or performance outside the scope of a testing skill.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

Suggesting administrative modification of global DB settings is unjustified for a database testing skill because it encourages privilege-requiring actions that can impact all workloads on the database server. In the context of a broadly reusable skill, this can normalize unsafe operational changes and lead users to run them in shared or production environments without proper review.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The performance section changes global database settings without any safety warning, which is risky because it can affect all users of the server and may increase logging overhead or alter operational behavior. Even though slow-query analysis is relevant to database testing, the lack of scope limitation and environment warning makes the guidance unsafe.

Content

No source excerpt is available for this finding.

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 60% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 270)May include surrounding context.

bash

# Pattern: API call → DB check
# 1. Call API to create order
curl -X POST "$URL/api/orders" -d '{"item_id":1,"qty":2}'

# 2. Verify in database
mysql -e "SELECT * FROM orders ORDER BY id DESC LIMIT 1;" $DB_NAME

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The document includes INSERT statements that modify database contents but provides no warning that these commands should only be run against an isolated test database. In an agent skill context, users or automated systems may execute examples verbatim, causing unintended writes, test-data pollution, or corruption of real datasets if pointed at non-test environments.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

The deadlock test intentionally instructs users to create conflicting UPDATE operations across two sessions without warning about service impact. If run against a live or shared database, this can block transactions, trigger rollbacks, degrade availability, and interfere with production workloads; in an agent skill, such operationally dangerous steps are more risky because they may be followed automatically or without DBA review.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.