Ai Content Tailor

• Outcome: Review
• Latest audit: Sep 12, 2026 · 2:13 AM UTC
• Version: 1.0.0

Overview

This appears to be a legitimate content-rewriting skill, but its installer and uninstaller can write or delete files outside the skill directory.

Review before installing. Use this only with articles you are comfortable sending to OpenAI, avoid putting sensitive drafts or secrets in inputs, and do not run uninstall.sh until the BASE_DIR bug is fixed or you have verified the exact .env and output paths it will remove. Prefer a virtual environment and a securely permissioned API key instead of the provided global pip install and plaintext .env setup.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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)

T08 · Insecure Dependencies

Warning

• Location: install.sh:13
• Finding: Unpinned dependencies are installed into the active Python environment<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:13-15`; related declaration at `skill.json:9` **Vulnerability Type**: Supply-chain exposure through unconstrained dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash # 安装依赖 echo "📦 安装 Python 依赖..." pip3 install openai python-dotenv --quiet ``` Related manifest declaration: ```json "requirements": ["openai>=1.0.0", "python-dotenv>=1.0.0"], ``` ### Technical Analysis The installer retrieves `openai` and `python-dotenv` without exact version pins, integrity hashes, a lockfile, or an isolated virtual environment. The manifest's `>=` constraints similarly permit any later release. Consequently, the code installed and imported by the Skill can change after the Skill itself has been audited. The direct package names are legitimate and no malicious dependency is currently demonstrated, but this installation method leaves the Skill exposed to compromised upstream releases, dependency-account takeover, and incompatible future versions. Using the active `pip3` also modifies the user's current Python environment rather than a Skill-specific environment. This can create dependency conflicts and expands the scope of package installation beyond what is necessary for the Skill. ### Attack Path 1. An attacker compromises a permitted package release or its publishing account. 2. A new malicious version is published under the legitimate package name. 3. A user runs `install.sh`. 4. `pip3` resolves and downloads the newest permitted release without hash verification. 5. Package-controlled code executes during installation or when `repurpose.py` imports the package. 6. The malicious package obtains the privileges of the user running the installer or Skill. ### Impact Assessment A compromised dependency could read files accessible to the current user, including the Skill's OpenAI API key and article contents; make network requests; alter the user's Python environment; or execute arbi ...[truncated 276 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every dependency to an exact reviewed version. 2. Generate and commit a lockfile containing cryptographic hashes. 3. Install with hash verification, such as: ```bash python3 -m pip install --require-hashes -r requirements.txt ``` 4. Create a dedicated virtual environment inside the Skill directory rather than modifying the user's active Python environment. 5. Use `python3 -m pip` to ensure dependencies are installed for the same interpreter used to run the Skill. 6. Regularly review pinned versions and update them through an explicit, tested dependency-update process. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: install.sh:18
• Finding: OpenAI API key file is created without restrictive permissions<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:18-25` **Vulnerability Type**: Insecure plaintext secret storage **Risk Level**: Medium ### Vulnerable Code ```bash # 创建配置文件模板 if [ ! -f "$BASE_DIR/.env" ]; then echo "📝 创建 .env 配置文件..." cat > "$BASE_DIR/.env" << 'EOF' # OpenAI API Configuration OPENAI_API_KEY=your-api-key-here EOF echo "⚠️ 请编辑 $BASE_DIR/.env 文件，填入你的 OPENAI_API_KEY" fi ``` ### Technical Analysis The installer asks the user to place an OpenAI API key in a plaintext `.env` file, but it neither establishes a restrictive umask nor explicitly applies mode `0600`. The resulting permissions depend on the user's current umask. In an environment with a permissive umask, the file may be readable by other local users or processes. API-key access is necessary for the declared OpenAI functionality, but making the credential potentially accessible outside the owning account exceeds the minimum access required. This is aggravated by the separate base-directory calculation defect: the installer creates the file in the parent of the Skill directory, while `source/repurpose.py` loads `.env` from the Skill directory. ### Attack Path 1. The user runs `install.sh` under a permissive umask. 2. The installer creates `.env` without an explicit restrictive mode. 3. The user replaces the placeholder with a valid OpenAI API key. 4. Another local account or process with access to that path reads the file. 5. The exposed key is used to issue unauthorized OpenAI API requests. Exploitation requires local filesystem access and permissions sufficient to read the resulting file. ### Impact Assessment The exposed credential can allow unauthorized use of the victim's OpenAI account within the key's permissions and limits. This may result in API charges, quota exhaustion, service disruption, or access to capabilities granted to that key. This issue does not itself grant operating-system privilege escalation. Its scope is the OpenAI API autho ...[truncated 46 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Prefer receiving `OPENAI_API_KEY` from the process environment or an operating-system credential manager. 2. If a local `.env` file must be supported, create it with owner-only permissions: ```bash umask 077 install -m 600 /dev/null "$SCRIPT_DIR/.env" cat > "$SCRIPT_DIR/.env" <<'EOF' # OpenAI API Configuration OPENAI_API_KEY=your-api-key-here EOF chmod 600 "$SCRIPT_DIR/.env" ``` 3. Correct the base directory so the installer and Python implementation use the same Skill-local file. 4. Add `.env` to version-control and packaging exclusion rules. 5. Document that the key must never be committed, shared, or included in generated output. 6. Consider supporting scoped or restricted API credentials where the provider permits them. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: uninstall.sh:4
• Finding: Incorrect base-directory calculation can delete data outside the Skill directory<![CDATA[ ## Vulnerability Details **File Location**: `uninstall.sh:4-14`; the same incorrect calculation appears at `install.sh:4-5` **Vulnerability Type**: Out-of-scope filesystem modification and unsafe recursive deletion **Risk Level**: High ### Vulnerable Code ```bash SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" BASE_DIR="$(dirname "$SCRIPT_DIR")" echo "🗑️ 卸载 content-repurposer..." read -p "是否删除配置文件和输出？(y/N): " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]]; then rm -f "$BASE_DIR/.env" rm -rf "$BASE_DIR/output" echo "✅ 已删除配置和输出" fi ``` The installer uses the same incorrect base calculation before creating files: ```bash SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" BASE_DIR="$(dirname "$SCRIPT_DIR")" ``` By contrast, the Python implementation defines the Skill root as follows: ```python BASE_DIR = Path(__file__).parent.parent load_dotenv(BASE_DIR / ".env") ``` ### Technical Analysis Both shell scripts reside in the project root. Therefore, `SCRIPT_DIR` already identifies the Skill directory. Applying `dirname` again sets `BASE_DIR` to the Skill's parent directory. As a result: - Installation creates `.env` and `output` in the parent directory rather than inside the Skill. - The runtime looks for `.env` inside the Skill, so the generated configuration does not match the runtime location. - Uninstallation runs `rm -rf` against the parent directory's `output` path. - That parent path may be shared with other Skills or unrelated user data. The interactive confirmation reduces the likelihood of accidental deletion, but it only asks whether configuration and output should be removed. It does not disclose that the target is outside the Skill directory, nor does it validate the canonical deletion target before recursive removal. ### Attack Path 1. The Skill is installed in a directory whose parent contains an unrelated directory named `output`. 2. The user invokes `uninstall.sh`. 3. The script asks whether configurati ...[truncated 1020 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Treat the script directory itself as the project base in both shell scripts: ```bash SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)" BASE_DIR="$SCRIPT_DIR" ``` 2. Keep configuration and generated output inside the verified Skill root. 3. Before any recursive deletion, resolve the canonical target and confirm it is a nonempty child of the expected Skill directory. 4. Reject dangerous or unexpected targets such as `/`, the user's home directory, the workspace root, or the Skill's parent directory. 5. Display the exact canonical paths to the user before deletion. 6. Prefer deleting only files known to have been created by this Skill rather than recursively removing a broadly named directory. 7. Add automated installation and uninstallation tests that verify no path outside the temporary Skill root is created, modified, or deleted. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (17)

Credential Access

High

• Category: Privilege Escalation

Content

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
if not OPENAI_API_KEY:
    print("❌ 未设置 OPENAI_API_KEY，请编辑 .env 文件")
    sys.exit(1)

try:

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
if not OPENAI_API_KEY:
    print("❌ 未设置 OPENAI_API_KEY，请编辑 .env 文件")
    sys.exit(1)

try:

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
if not OPENAI_API_KEY:
    print("❌ 未设置 OPENAI_API_KEY，请编辑 .env 文件")
    sys.exit(1)

try:

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
if not OPENAI_API_KEY:
    print("❌ 未设置 OPENAI_API_KEY，请编辑 .env 文件")
    sys.exit(1)

try:

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

read -p "是否删除配置文件和输出？(y/N): " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    rm -f "$BASE_DIR/.env"
    rm -rf "$BASE_DIR/output"
    echo "✅ 已删除配置和输出"
fi

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

read -p "是否删除配置文件和输出？(y/N): " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    rm -f "$BASE_DIR/.env"
    rm -rf "$BASE_DIR/output"
    echo "✅ 已删除配置和输出"
fi

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

read -p "是否删除配置文件和输出？(y/N): " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    rm -f "$BASE_DIR/.env"
    rm -rf "$BASE_DIR/output"
    echo "✅ 已删除配置和输出"
fi

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

read -p "是否删除配置文件和输出？(y/N): " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    rm -f "$BASE_DIR/.env"
    rm -rf "$BASE_DIR/output"
    echo "✅ 已删除配置和输出"
fi

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

read -p "是否删除配置文件和输出？(y/N): " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    rm -f "$BASE_DIR/.env"
    rm -rf "$BASE_DIR/output"
    echo "✅ 已删除配置和输出"
fi

• Confidence: 95% 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    rm -f "$BASE_DIR/.env"
    rm -rf "$BASE_DIR/output"
    echo "✅ 已删除配置和输出"
fi

• Confidence: 95% 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).

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill instructs users to configure an OpenAI API key and describes LLM-based rewriting, but it does not explicitly warn that the input article content will be transmitted to a third-party API for processing. This creates a privacy and data-handling risk because users may submit proprietary, confidential, or personal content without informed consent.

Natural-Language Policy Violations

Medium

• Confidence: 97% confidence
• Finding: Multiple user-facing messages in the script are written only in Chinese, including installation status and instructions. This forces a specific language for users without opt-in and matches the policy category for language or locale violations.

Natural-Language Policy Violations

Medium

• Confidence: 92% confidence
• Finding: The manifest description is entirely in Chinese and describes the skill's behavior in a way that implies a Chinese-language, China-platform-specific workflow. There is no indication that users can choose another language or locale, and no documented justification that this skill is restricted to Chinese-language users only.

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: The title and user-facing strings indicate the skill is designed and presented exclusively in Chinese, and the prompt templates require Chinese output styles for specific platforms. There is no indication that users can opt into another language or locale, which can violate language/locale policy when no explicit choice is offered.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The skill sends the full article content to an external OpenAI API for rewriting without any consent prompt, disclosure, redaction step, or data-classification check. If users process proprietary, personal, or otherwise sensitive drafts, that content leaves the local environment and may be exposed to third-party processing, violating privacy expectations or organizational policy.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: The script's natural-language output and prompt are entirely in Chinese, which imposes a specific language on users without opt-in. This matches the language/locale policy concern because the file provides no alternative language handling or justification for being Chinese-only.

Natural-Language Policy Violations

Low

• Confidence: 86% confidence
• Finding: The natural-language content of the skill description, parameters, and examples is presented in Chinese, and there is no indication that users may select another language or that the skill is intentionally limited to a Chinese-speaking context. Under the language/locale policy, forcing a specific language without opt-in can be a policy concern unless the restriction is documented and justified.

Static analysis

No suspicious patterns detected.