Post-Development Verification

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:57 AM UTC
• Version: 1.0.1

Overview

This is a legitimate test-verification skill, but it needs review because it can direct broad service, database, network, and credential-using test actions without strong built-in scope guards.

Install only if you will run it in disposable local, CI, or sandbox environments with test credentials. Before allowing execution phases, review the effective hosts, database names, cleanup commands, migration/seed commands, and any Authorization-bearing requests; avoid production-like endpoints, shared databases, broad cleanup commands, and host-level service control unless explicitly intended.

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 (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: references/real-e2e-templates.md:160

Finding

Authorization Tokens May Be Sent to an Unvalidated Configuration-Controlled Endpoint

Content

View full analysis

Vulnerability Details

File Location: references/real-e2e-templates.md:160-177
Vulnerability Type: Credential disclosure through an unvalidated network destination
Risk Level: Medium

Vulnerable Code

text

# Setup (once per test suite)
setup_suite():
    load environment config
    get base_url from config or service discovery
    get auth_token (if needed):
        - real login: POST /auth/login with test credentials
        - or API key from environment variable
    store auth_token for reuse

The token is subsequently attached to requests:

text

create_response = POST base_url + "/api/resource"
    headers: { Authorization: auth_token, Content-Type: "application/json" }
    body: { name: "test-item", value: 42 }

Technical Analysis

The E2E template obtains base_url from configuration or service discovery while allowing the authorization token to come from an environment variable. It does not require validation that the destination is a loopback address, an approved test host, or an authenticated HTTPS endpoint before attaching the token.

Projects being tested may control configuration files consumed by the generated tests. A malicious or compromised project can therefore provide an attacker-controlled base_url. If the user has a test API key or bearer token in the environment, the generated request can disclose that credential to the configured host.

The Skill states that only test credentials should be used. This reduces the likely impact but does not prevent unauthorized disclosure or subsequent misuse of those test credentials.

Attack Path

1. An attacker adds or modifies project configuration so that base_url resolves to an attacker-controlled server.
2. A user invokes the Skill with a test API key or bearer token available through an environment variable.
3. The Skill generates or runs an E2E test using the project-controlled URL.
4. The test attaches the environment-sourced token to the `Authorization ...[truncated 677 chars]

Remediation

View remediation

Remediation Suggestions

1. Resolve and display the effective destination before making any authenticated request.
2. Allow authenticated requests to loopback addresses by default and require explicit user approval for every non-loopback host.
3. Enforce a configurable allowlist of approved test and staging domains.
4. Require HTTPS with valid certificate verification for remote destinations.
5. Reject URLs containing embedded credentials, unexpected schemes, or ambiguous host representations.
6. Disable automatic redirects for authenticated requests, or strip authorization headers whenever the destination origin changes.
7. Use short-lived, narrowly scoped tokens created specifically for the current test run.
8. Redact authorization headers, cookies, API keys, and login responses from logs and generated reports.
9. Abort rather than sending credentials when the destination cannot be conclusively classified as an approved test environment.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/real-e2e-templates.md:398

Finding

Destructive Cleanup and Host-Service Operations Lack Enforced Test-Environment Scope Guards

Content

View full analysis

Vulnerability Details

File Location: references/real-e2e-templates.md:398-402
Related Locations: references/real-e2e-templates.md:47-48, 116-117, 248
Vulnerability Type: Excessive privileges and insufficiently scoped destructive operations
Risk Level: Medium

Vulnerable Code

text

# Per-suite cleanup
cleanup_per_suite():
    drop test database and recreate
    or run project's test cleanup command
    or delete all resources created during test run

Related operational templates also permit broad host and resource manipulation:

text

# Start database
start_service "database" using:
    - docker: docker compose up -d db
    - or native: systemctl start postgresql

text

# 1. Clean start (no cached state)
stop all services if running
clear any cached artifacts (node_modules/.cache, __pycache__, build output)

text

cleanup_suite():
    delete all test-created resources (or use rollback)
    optionally reset database state

Technical Analysis

The Skill’s high-level safety policy says that operations must be limited to a test environment. However, the operational templates do not enforce that policy before invoking native service management, stopping services, resetting database state, dropping a database, or deleting resources.

Instructions such as “stop all services” are not constrained to processes started by the current run. Likewise, “drop test database and recreate” relies on a name or connection being correctly configured but does not require verification that the selected database is ephemeral or test-only.

Use of native systemctl also extends the Skill’s effects beyond an isolated project workspace and may require elevated host permissions. These operations are not necessary when dependencies can instead be launched in ephemeral, project-scoped containers.

Attack Path

1. A malicious project supplies migration, cleanup, service, or database configuration consumed during test setup.
2. The ...[truncated 1265 chars]

Remediation

View remediation

Remediation Suggestions

1. Prefer ephemeral containers or disposable namespaces and disable native systemctl operations by default.
2. Require explicit user approval before host-service control, migrations, seeding, database resets, or destructive cleanup.
3. Validate database names against a strict test-only naming convention and reject default, shared, staging, or production identifiers.
4. Verify the database host is an approved test host before running migrations or destructive commands.
5. Require a generated run identifier and label every created resource with that identifier.
6. Delete only resources carrying the current run’s identifier; prohibit unbounded “delete all” operations.
7. Track exact process IDs and container IDs started by the current run, and stop only those assets.
8. Replace “stop all services” with an explicit allowlist of services created by the current test session.
9. Use restricted database accounts that cannot access or drop non-test databases.
10. Perform a dry run that reports all intended service, database, filesystem, and network effects before execution.
11. Abort cleanup when ownership or test-environment status cannot be conclusively established.
12. Prefer transaction rollback or disposable databases over destructive reset commands.

SkillSpector

Vulnerability Patterns

• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 80% confidence

Finding

Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Content

Scanner excerpt · references/feedback-schema.md (reported line 405)May include surrounding context.

md

"cluster_name": "incorrect error status codes for resource not found",
      "affected_tests": [
        "GET /users/:id returns 404 for non-existent user",
        "DELETE /users/:id returns 404 for non-existent user"
      ],
      "count": 2,
      "suggested_fix": "In GET and DELETE handlers for /users/:id, query the database before processing. If no user is found, return res.status(404).json({ error: 'User not found' }) instead of continuing with null/undefined user data.",

Vague Triggers

Medium

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

Finding

The skill is configured for automatic post-development invocation using broad phrases like 'run tests', 'verify', 'quality check', 'does this work?', and similar multilingual variants. Because this skill can start services, run migrations, seed data, and make network calls, overly broad activation increases the chance it will execute in situations where the user did not intend potentially state-changing or networked operations.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The template explicitly recommends destructive cleanup operations such as dropping and recreating a test database or deleting all resources created during a run, but it provides no safeguards to ensure the target is a disposable test environment. In a skill that promotes 'real execution first' and production-like validation, these instructions could be copied into automation and accidentally pointed at non-test infrastructure, causing data loss or service disruption.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.