Pre-Publish Security Check

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:12 AM UTC
• Version: 1.0.0

Overview

This skill is not malicious, but its security checker can incorrectly report that a skill is safe to publish despite missing important secret patterns.

Treat this as a lightweight helper only, not a publish gate. Before relying on it, fix the grep error handling and add real coverage for private keys, generic tokens, and coordinates, or use a mature secret-scanning tool alongside manual review. Also expect Chinese-only user-facing output.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: skill-pre-publish-check.sh:29

Finding

Private-Key Detection Fails Silently Due to Incorrect grep Option Handling

Content

View full analysis

Vulnerability Details

File Location: skill-pre-publish-check.sh:29
Vulnerability Type: Security scanner bypass caused by incorrect command-line argument handling
Risk Level: High

Vulnerable Code:

bash

KEY_MATCHES=$(grep -rE "-----BEGIN (RSA )?PRIVATE KEY-----" "$SKILL_DIR" 2>/dev/null || true)

Technical Analysis

The regular expression begins with hyphens but is passed to grep without the -e option or an option-terminating --. Consequently, grep may interpret the pattern as a command-line option instead of a search expression and terminate with an error.

The command suppresses standard error through 2>/dev/null and then converts every failure into a successful shell status through || true. The script therefore cannot distinguish a scanner execution error from a valid scan that found no private keys. KEY_MATCHES remains empty, and the private-key detection branch is skipped.

Attack Path

1. A private key is added to a file under the directory being scanned.
2. The file contains a standard marker such as -----BEGIN PRIVATE KEY-----.
3. The private-key grep command interprets the leading hyphens as command-line syntax and fails.
4. The error is hidden by 2>/dev/null, while || true prevents the script from terminating.
5. If no other detection rule matches, FOUND remains zero.
6. The scanner exits successfully and reports that the Skill is safe to publish.
7. A publishing pipeline chained with && may publish the private key.

Impact Assessment

This issue does not grant local execution privileges or elevate system permissions. Its impact is a complete bypass of the scanner's private-key control. A PEM-encoded private key could be published to a public or shared repository, allowing anyone with access to impersonate the key owner, authenticate to affected services, decrypt data where the key is applicable, or sign malicious artifacts.

The ultimate ...[truncated 138 chars]

Remediation

View remediation

Remediation Suggestions

Pass the expression explicitly with -e and terminate option parsing before the directory argument:

bash

grep -rE -e '-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY-----' -- "$SKILL_DIR"

Support additional common private-key formats, including EC, DSA, and OpenSSH keys.

Do not treat scanner execution failures as successful scans. Capture the grep exit status and distinguish between:

• Exit status 0: matches were found.
• Exit status 1: no matches were found.
• Exit status greater than 1: the scan failed and publication must be blocked.

Add automated tests containing representative PEM files and verify that each test causes a nonzero final scanner exit status.

T09 · Insecure Skill Coding Practices

Warning

• Location: skill-pre-publish-check.sh:20

Finding

Documented Generic Token Detection Is Not Implemented

Content

View full analysis

Vulnerability Details

File Location: skill-pre-publish-check.sh:20; documented behavior at SKILL.md:13-14
Vulnerability Type: Incomplete secret detection and publication-gate bypass
Risk Level: Medium

Vulnerable Code:

bash

API_MATCHES=$(grep -rE "(sk-[a-zA-Z0-9]{20,}|tvly-dev-[a-zA-Z0-9]+|sk_live_[a-zA-Z0-9]+|sk_test_[a-zA-Z0-9]+)" "$SKILL_DIR" --include="*.py" --include="*.sh" --include="*.md" --include="*.json" 2>/dev/null || true)

Technical Analysis

The documentation states that the scanner detects random strings of at least 32 characters, hardcoded tokens, and custom token formats. The implementation only searches for four specific prefixes:

• sk-
• tvly-dev-
• sk_live_
• sk_test_

No generic long-token rule, contextual token-assignment rule, entropy check, or extensible custom-pattern mechanism is implemented. Credentials from other providers, bearer tokens, database passwords, JWTs, and long application secrets can therefore pass undetected.

As with the private-key check, 2>/dev/null || true also converts scanner errors into apparent no-match results.

Attack Path

1. A source or configuration file contains a real secret whose format does not use one of the four recognized prefixes.
2. Examples include a 32-character application token, an unrecognized cloud credential, or a hardcoded bearer token.
3. The regular expression does not match the secret.
4. No other scanner rule identifies it.
5. The script reports a successful scan and exits with status zero.
6. An automated release pipeline proceeds to publish the directory.
7. Users with access to the published package can recover and misuse the credential.

Impact Assessment

This flaw does not directly provide privileges on the machine running the scanner. It can, however, expose credentials that grant access to external APIs, cloud resources, databases, or internal services.

The privileges obtain ...[truncated 243 chars]

Remediation

View remediation

Remediation Suggestions

Implement the behavior promised by the documentation. At minimum:

1. Detect suspicious assignments to names such as token, secret, password, api_key, and credential.
2. Add provider-specific patterns for all officially supported credential formats.
3. Detect JWTs and sufficiently long high-entropy strings while using contextual checks to limit false positives.
4. Allow maintainers to supply additional approved detection patterns.
5. Scan relevant configuration formats such as YAML, TOML, environment files, and XML, subject to explicit exclusions for generated or dependency directories.
6. Treat scanning errors as release-blocking failures rather than successful no-match results.
7. Add positive and negative test fixtures for recognized secrets, unknown long tokens, placeholders, and environment-variable references.

If generic token detection is intentionally unsupported, narrow the documentation and success message so they do not claim broader security coverage than the implementation provides.

T09 · Insecure Skill Coding Practices

Note

• Location: skill-pre-publish-check.sh:36

Finding

Coordinate Detection Misses Common Separate Latitude and Longitude Assignments

Content

View full analysis

Vulnerability Details

File Location: skill-pre-publish-check.sh:36; conflicting example at SKILL.md:83-84
Vulnerability Type: Incomplete sensitive-location detection
Risk Level: Low

Vulnerable Code:

bash

COORD_MATCHES=$(grep -rE "[0-9]{2,3}\.[0-9]{4,},[0-9]{2,3}\.[0-9]{4,}" "$SKILL_DIR" --include="*.py" --include="*.sh" --include="*.md" 2>/dev/null || true)

Technical Analysis

The expression only recognizes two positive decimal values on the same line with a comma directly between them. It does not detect the separate longitude and latitude assignments presented as sensitive in the Skill's own documentation.

It also misses several common coordinate representations, including:

• Latitude and longitude on separate lines.
• JSON or YAML fields separated by labels and punctuation.
• Negative coordinates.
• Coordinates separated by whitespace.
• Coordinates where latitude appears before longitude.
• Decimal coordinates with only one digit before the decimal point.

Consequently, the scanner's success result does not reliably establish that precise location data is absent.

Attack Path

1. Precise latitude and longitude values are stored in separate configuration fields or on separate lines.
2. The values do not appear as two directly comma-separated positive decimals on one line.
3. The coordinate expression does not match either value.
4. If no other rule matches, the scanner exits successfully.
5. The package is published with precise location information.
6. A recipient can extract the coordinates and associate them with the affected person, device, or facility.

Impact Assessment

The issue does not grant operating-system privileges. Its impact is disclosure of precise location data that the scanner is intended to prevent from being published.

Depending on context, exposed coordinates could reveal a home, workplace, private facility, device location, or operation ...[truncated 123 chars]

Remediation

View remediation

Remediation Suggestions

Detect latitude and longitude assignments independently and correlate them within the same file or structured object. Support common field names such as lat, latitude, lng, lon, and longitude.

Validate numeric ranges to reduce false positives:

• Latitude: -90 through 90.
• Longitude: -180 through 180.

Extend parsing to supported JSON, YAML, shell, Markdown, and source-code formats. Account for negative values, either coordinate order, optional whitespace, separate lines, and labeled fields.

Add regression tests using the separate LNG and LAT format shown in the documentation, along with JSON, YAML, negative-coordinate, and non-coordinate decimal fixtures.

SkillSpector

Vulnerability Patterns

• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• 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
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 70% confidence

Finding

Without declared permissions the skill's intent is opaque and cannot be validated.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

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

Finding

This shell script's user-facing comments and runtime messages are entirely in Chinese, including usage guidance, warnings, and success/failure output. Because the file provides no opt-in, language selection, or documented region-specific justification, it creates a natural-language locale policy concern under the requirement to avoid forcing a specific language without user choice.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

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

Finding

This markdown file contains user-facing instructions in Chinese with an English sentence embedded, but it does not state any language preference, opt-in, or region-specific justification. Under the policy rule, forcing or assuming a language/locale without user choice can be a natural-language policy concern.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.