T09 · Insecure Skill Coding Practices
- Location
skills/report/SKILL.md:45- Finding
Automatic Disclosure of Test Results to an Unvalidated Webhook
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent Playwright testing toolkit, but it has review-worthy risks around automatic external reporting, credentialed integrations, and unguarded writes to TestRail/BrowserStack.
Install only in repositories where running Playwright tests, writing test files, and using optional TestRail/BrowserStack/Slack integrations is acceptable. Use low-privilege API tokens, keep these integrations disabled unless needed, verify TESTRAIL_URL and SLACK_WEBHOOK_URL before reporting, avoid production-like data in test output, and prefer lockfile-pinned local Playwright/tsx invocations over bare npx.
skills/report/SKILL.md:45Automatic Disclosure of Test Results to an Unvalidated Webhook
integrations/testrail-mcp/src/client.ts:16TestRail API Credentials Sent to an Unvalidated Configurable Origin
Claiming a broad toolkit while only implementing TestRail schemas or narrow integration logic can mislead users into overtrusting the skill and granting it broader operational latitude. Even when the hidden behavior is not overtly malicious, inaccurate packaging erodes auditability and increases the chance of inappropriate data access.
Claiming a broad toolkit while only implementing TestRail schemas or narrow integration logic can mislead users into overtrusting the skill and granting it broader operational latitude. Even when the hidden behavior is not overtly malicious, inaccurate packaging erodes auditability and increases the chance of inappropriate data access.
Claiming a broad toolkit while only implementing TestRail schemas or narrow integration logic can mislead users into overtrusting the skill and granting it broader operational latitude. Even when the hidden behavior is not overtly malicious, inaccurate packaging erodes auditability and increases the chance of inappropriate data access.
Claiming a broad toolkit while only implementing TestRail schemas or narrow integration logic can mislead users into overtrusting the skill and granting it broader operational latitude. Even when the hidden behavior is not overtly malicious, inaccurate packaging erodes auditability and increases the chance of inappropriate data access.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
expect(body.error ?? body.code).toMatch(/token.*expired|expired_token/i);
});
// Happy path: refresh token obtains new access token
test('refreshes expired token and retries request', async ({ request }) => {
// Step 1: refresh
const refresh = await request.post('{{apiBaseUrl}}/auth/refresh', {
The DELETE test performs a destructive request using fully templated parameters such as apiBaseUrl, entityName, and deletableEntityId, with no validation or restriction on what resource is targeted. In this skill context, that makes misuse more dangerous because the template is designed for direct execution in browser automation/test pipelines, where pointing at the wrong environment or ID could delete real data at scale.
});
// Happy path: DELETE removes entity
test('DELETE /{{entityName}}s/:id deletes entity', async ({ request }) => {
const del = await request.delete(`{{apiBaseUrl}}/{{entityName}}s/{{deletableEntityId}}`, { headers });
expect(del.status()).toBe(204);
// Verify gone
The README promotes TestRail and BrowserStack integrations and says they can read cases, push results, and pull reports, but it does not clearly warn that using these commands may send test metadata, results, screenshots, videos, URLs, and possibly sensitive application data to third-party services. In a testing skill, this is especially relevant because generated or debugged tests often operate against pre-production systems containing internal identifiers, credentials, or customer-like data.
The skill advertises capabilities that involve environment variables and external services, but it declares no explicit tool scope or permission boundaries. That makes it easier for an agent to access credentials or perform network actions without clear user-visible constraints, increasing the risk of unintended secret use or outbound data transmission.
The skill explicitly references syncing with TestRail and running on BrowserStack using API credentials, but it does not clearly warn that test data, metadata, or results may be transmitted to third-party services. In this context, users may expose internal project names, URLs, failures, or other sensitive QA artifacts without realizing the privacy and credential-handling implications.
The agent instructs execution of npx playwright test ..., which can resolve and run a package version at execution time if Playwright is not already installed locally. That creates a supply-chain risk and undermines reproducibility, because the behavior depends on whatever version is currently fetched or available in the environment.
This repeated use of npx playwright has the same issue: it may implicitly fetch and execute an unpinned package version from the registry. In an agent that is explicitly allowed to use Bash and run tests, this increases the practical exploitability of dependency confusion, registry compromise, or unexpected version drift.
Using bare npx playwright for the isolation check can cause the agent to execute code from a version not reviewed with the skill. Because the command is presented as routine debugging workflow, users or agents may run it automatically, making the supply-chain exposure more dangerous in this context than in static documentation alone.
The full-suite command again relies on npx playwright without version pinning, exposing the environment to unreviewed package resolution at runtime. Since full-suite runs are likely to be performed in CI or privileged developer environments, compromise could affect broader codebases, secrets, or build infrastructure.
The trace-capture step also uses unpinned npx playwright, preserving the same supply-chain and non-reproducibility risk. The skill context makes this more dangerous because the file is an operational agent playbook with Bash access, so these commands are intended to be executed rather than merely discussed.
This skill defines bundled lifecycle hooks that automatically execute shell commands on SessionStart and after Write/Edit tool use. Even though the JSON itself only references local scripts, automatic command execution increases attack surface because those scripts run without per-use user review and could perform unintended actions if the package is tampered with or the scripts are unsafe.
This code constructs a Basic Authorization header from the BrowserStack username and access key and uses it for outbound API calls. The file contains no confirmation prompt, user-facing log/print, or explanatory comment/docstring warning that credentials and session/build data will be sent to BrowserStack.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
The tool explicitly exposes detailed BrowserStack session data, including video URLs, logs, and screenshots, and returns it directly to the caller without any access control, redaction, or warning about sensitive contents. In a testing context, these artifacts commonly contain application data, URLs, credentials, tokens, PII, or internal environment details, so broad retrieval materially increases data exposure risk.
The browserstack_get_logs tool returns raw session logs directly as text with no filtering or warning, even though test logs frequently include stack traces, URLs, headers, cookies, access tokens, test credentials, and user data. Because this skill is designed for browser automation and CI/test operations, the likelihood of sensitive material appearing in logs is relatively high, making this more dangerous in context.
This code constructs a Basic Authorization header from the configured user and API key and then sends HTTP requests to a remote TestRail server. The file contains no confirmation prompt, warning comment, or user-facing log indicating that credentials and request payload data will be transmitted over the network.
The shebang uses env npx tsx, which resolves and may fetch an unpinned package at execution time instead of invoking a project-pinned binary directly. In environments where PATH, npm registry configuration, or package resolution can be influenced, this creates supply-chain risk and can lead to execution of an unexpected tsx version or malicious package.
This MCP server exposes state-changing operations like adding cases, updating cases, creating runs, and posting results with no user-facing confirmation, dry-run mode, or explicit guardrails. In an agent context, a mistaken prompt, tool-selection error, or prompt-injection-induced action could silently modify TestRail data, causing integrity issues in test management and reporting.
The example persists authenticated browser session state to .auth/user.json, which can contain cookies, tokens, and other session artifacts that grant access if copied or committed. In a testing toolkit context this is a common technique, but presenting it without an explicit warning about secret handling, file permissions, and .gitignore increases the chance that users will expose reusable credentials or privileged sessions.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
No suspicious patterns detected.