china-mirror-skills

• Outcome: Review
• Latest audit: Sep 11, 2026 · 7:49 AM UTC
• Version: 1.0.0

Overview

This skill mostly does what it says, but it can make persistent, high-impact changes to package sources, Git routing, shell profiles, and trust settings that deserve careful review.

Install only if you are comfortable letting this skill modify development tool configuration and system package sources. Prefer dry-run first, avoid --yes, review any sudo commands, avoid --proxy-clone unless you want all future HTTPS GitHub Git operations routed through a third-party proxy, and be cautious because backups may include sensitive files such as .npmrc.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• 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

Findings (4)

T03 · Remote Payload Retrieval and Execution

Error

• Location: scripts/homebrew/setup.sh:145
• Finding: Unverified Homebrew Installer Is Downloaded and Executed Directly<![CDATA[ ## Vulnerability Details **File Location**: `scripts/homebrew/setup.sh:145-151` **Vulnerability Type**: Unverified remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash install_homebrew_with_mirror() { local mirror_name="$1" local mirror_url="${BREW_MIRRORS[$mirror_name]}" log_info "Installing Homebrew with $mirror_name mirror..." # Set environment variables for install script export HOMEBREW_BREW_GIT_REMOTE="${mirror_url}/brew.git" export HOMEBREW_CORE_GIT_REMOTE="${mirror_url}/homebrew-core.git" # Run official installer /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ``` ### Technical Analysis When Homebrew is not present, the script retrieves a shell program from a mutable GitHub `HEAD` URL and immediately executes the response with `/bin/bash`. There is no version pinning, cryptographic signature validation, checksum verification, content inspection, or separation between retrieval and execution. Although the URL is the official Homebrew installer location and HTTPS protects the network transport, the effective code executed can change after this Skill has been reviewed. Compromise of the upstream repository, maintainer account, hosting platform, DNS/PKI path, or delivery endpoint could therefore turn this command into arbitrary code execution. This behavior exceeds the minimum privileges and actions necessary to configure a Homebrew mirror. Mirror configuration can be performed without automatically installing Homebrew, and installation should be a distinct, explicitly approved operation. ### Attack Path 1. A user invokes the Homebrew mirror setup script. 2. `setup_homebrew_mirror` determines that `brew` is not installed. 3. The script enters `install_homebrew_with_mirror`. 4. `curl` retrieves the current contents of the mutable `HEAD/install.sh` resource. 5. The response is substituted directly into `/bin/bash -c`. 6. ...[truncated 738 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not pass a network response directly to a shell. 2. Keep mirror configuration separate from Homebrew installation; if Homebrew is absent, stop and provide safe manual instructions. 3. If automated installation is required: - Pin the installer to a reviewed release or immutable commit. - Download it to a securely created temporary file. - Verify a publisher-provided signature or a pinned SHA-256 digest. - Display the source, version, digest, and intended operation to the user. - Require explicit confirmation immediately before execution. - Execute with ordinary user privileges and allow privilege elevation only for narrowly scoped commands. 4. Remove the temporary file after execution and report exactly what was changed. 5. Prefer a package or installer distribution mechanism that provides signed, versioned artifacts. ]]>

T03 · Remote Payload Retrieval and Execution

Warning

• Location: scripts/rust/setup.sh:110
• Finding: Rust Setup Recommends Executing an Unverified Remote Script Through a Shell Pipeline<![CDATA[ ## Vulnerability Details **File Location**: `scripts/rust/setup.sh:110-119` **Vulnerability Type**: Unsafe remote installer instruction **Risk Level**: Medium ### Vulnerable Code ```bash # Check if cargo is installed if ! command_exists cargo; then log_warn "Cargo not found in PATH" log_info "To install Rust with this mirror, set these environment variables first:" if [[ -n "${RUSTUP_MIRRORS[$mirror_name]:-}" ]]; then echo " export RUSTUP_DIST_SERVER=${RUSTUP_MIRRORS[$mirror_name]}" echo " export RUSTUP_UPDATE_ROOT=${RUSTUP_MIRRORS[$mirror_name]}/rustup" fi log_info "Then run: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" return 1 fi ``` ### Technical Analysis The script does not execute this command automatically, but it presents `curl ... | sh` as the next installation step when Cargo is absent. If the user follows the recommendation, mutable network-delivered shell code is executed without being saved, inspected, pinned, or cryptographically verified. The use of HTTPS and explicit TLS options improves transport security but does not establish that the retrieved script is the same version that was reviewed. It also does not protect against compromise of the upstream service or its deployment process. The associated static warning about sensitive information transmission was not substantiated. This script does not send credentials or other identified secrets to the Rust endpoint; the confirmed issue is the unsafe remote-execution recommendation. ### Attack Path 1. A user runs the Rust mirror setup script on a system where Cargo is absent. 2. The script prints the `curl | sh` installation command. 3. The user follows the instruction. 4. The current response from `https://sh.rustup.rs` is streamed directly to a shell. 5. If the endpoint or delivery path is compromised, arbitrary commands execute as the user. 6. Those commands can alter user ...[truncated 451 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the `curl | sh` recommendation. 2. Direct users to the official Rust installation documentation without providing a direct pipe-to-shell command. 3. If installation automation is necessary: - Download a versioned installer artifact separately. - Pin it to an immutable version or commit. - Verify a trusted signature or published cryptographic digest. - Allow the user to inspect the downloaded file. - Require explicit confirmation before execution. 4. Clearly distinguish Cargo mirror configuration from installation of the Rust toolchain. 5. State that mirror endpoints are third-party supply-chain dependencies and recommend validation of downloaded toolchain artifacts where supported. ]]>

T07 · Tool Hijacking and Spoofing

Error

• Location: scripts/github/setup.sh:157
• Finding: Global Git Configuration Transparently Routes All GitHub HTTPS Operations Through a Third-Party Proxy<![CDATA[ ## Vulnerability Details **File Location**: `scripts/github/setup.sh:157-180` **Vulnerability Type**: Persistent global tool redirection and supply-chain exposure **Risk Level**: High ### Vulnerable Code ```bash if ! command_exists git; then log_error "git is required to configure proxy-clone" return 1 fi local insteadof_url="${proxy_prefix}https://github.com/" if [[ "$dry_run" == true ]]; then log_info "[DRY RUN] Would back up ~/.gitconfig if it exists" log_info "[DRY RUN] Would run:" echo " git config --global url.\"${insteadof_url}\".insteadOf \"https://github.com/\"" return 0 fi if [[ -f "${HOME}/.gitconfig" ]]; then backup_file "${HOME}/.gitconfig" "github" >/dev/null fi local git_config_key="url.${insteadof_url}.insteadOf" git config --global --unset-all "${git_config_key}" >/dev/null 2>&1 || true git config --global "${git_config_key}" "https://github.com/" log_success "Configured global clone acceleration via ${mirror_name}" log_info "All https://github.com/ URLs will be rewritten to ${insteadof_url}" ``` For the supported proxy, this creates an equivalent global rule: ```bash git config --global \ url."https://ghfast.top/https://github.com/".insteadOf \ "https://github.com/" ``` ### Technical Analysis The `--proxy-clone` mode installs a persistent global Git `url.*.insteadOf` rule. Every subsequent Git operation targeting an HTTPS GitHub URL is transparently rewritten through `ghfast.top`, including operations unrelated to this Skill or the original user request. This is broader than configuring a selected mirror or converting one release URL. It modifies Git's global behavior and inserts a third-party service into future software supply-chain operations. The proxy can observe requested repositories and has an opportunity to influence content or availability. Even where later commit verification can detect some tampering, ...[truncated 1583 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the global `https://github.com/` rewrite capability. 2. Restrict acceleration to explicit, allowlisted repositories with narrowly scoped `insteadOf` entries. 3. Prefer established institutional mirrors with documented integrity and synchronization controls. 4. For release assets, only generate and display a transformed URL; do not download or execute the asset automatically. 5. Require verification of signed tags, signed commits, release signatures, or publisher-provided SHA-256 digests. 6. Clearly disclose that a third party will receive repository URLs and mediate downloads. 7. Provide a dedicated removal command and verify that the rule was removed successfully. 8. Consider temporary per-command Git configuration instead of persistent global configuration, for example using `git -c` for one explicitly requested operation. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/restore_config.sh:101
• Finding: Untrusted Backup Metadata Can Select an Arbitrary Restore Destination<![CDATA[ ## Vulnerability Details **File Location**: `scripts/restore_config.sh:101-142` **Vulnerability Type**: Arbitrary file overwrite through unvalidated restore metadata **Risk Level**: Medium ### Vulnerable Code ```bash if [[ ! -f "${backup_subdir}/metadata.json" ]]; then log_error "Backup metadata not found" return 1 fi # Read metadata local original_path original_path=$(grep '"original_path"' "${backup_subdir}/metadata.json" | cut -d'"' -f4) local backup_time backup_time=$(grep '"backup_time"' "${backup_subdir}/metadata.json" | cut -d'"' -f4) local filename filename=$(basename "$original_path") local backup_file="${backup_subdir}/${filename}" if [[ ! -f "$backup_file" ]]; then log_error "Backup file not found: $backup_file" return 1 fi # Confirm restore echo "" log_warn "You are about to restore:" echo " Tool: $tool" echo " Backup ID: $backup_id" echo " Backup Time: $backup_time" echo " Target: $original_path" echo "" if ! confirm "Do you want to proceed?" "n"; then log_info "Restore cancelled" return 0 fi # Ensure target directory exists mkdir -p "$(dirname "$original_path")" # Restore file cp -p "$backup_file" "$original_path" ``` A second implementation in `scripts/common.sh:152-169` follows the same trust model: ```bash local original_path original_path=$(grep '"original_path"' "${backup_subdir}/metadata.json" | cut -d'"' -f4) local filename filename=$(basename "$original_path") local backup_file="${backup_subdir}/${filename}" if [[ ! -f "$backup_file" ]]; then log_error "Backup file not found: $backup_file" return 1 fi # Restore cp -p "$backup_file" "$original_path" ``` ### Technical Analysis The destination path is read directly from an editable metadata file and passed to `mkdir` and `cp`. The implementation does not parse t ...[truncated 2105 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not trust `original_path` from backup metadata as the restore destination. 2. Maintain a hardcoded per-tool allowlist of permitted destination paths and derive the target from the selected tool. 3. Parse metadata using a strict JSON parser and validate it against an explicit schema. 4. Canonicalize both backup and destination paths before use. 5. Reject paths outside approved directories, symbolic-link destinations, non-regular backup files, and unexpected filenames. 6. Create the backup root with restrictive permissions such as `0700` and verify that the directory and files are owned by the expected user. 7. Store and verify a modern integrity digest such as SHA-256; MD5 should not be relied upon for security validation. 8. For system configuration, use a separate narrowly scoped privileged restore operation instead of running the general restore script with `sudo`. 9. Apply the same validation to the duplicate `restore_file` implementation in `scripts/common.sh`. 10. Retain explicit confirmation and clearly display the canonical source and destination paths before writing. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (84)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description is for a comprehensive, self-contained orchestrator covering many package managers and diagnostic tasks. The supplied code chunk is only an APT setup script focused on Ubuntu/Debian sources.list management. While one small aspect of the description mentions running relevant scripts for individual tools, this specific code does not match the claimed primary purpose of being the main entry point that diagnoses and configures all tools. Its actual scope is materially narrower: APT-only configuration with backup, proxy warning, confirmation, dry-run, and package index update.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description presents this as the main self-contained entry point for configuring mirrors and diagnosing network/tooling issues in China. The provided code chunk is instead a backup helper script focused on copying existing config files and enumerating backup metadata. That is a materially different primary purpose from the declared behavior. While backup functionality could be a supporting detail in a larger mirror-configuration skill, the code shown does not implement any of the core promised capabilities such as tool detection, proxy conflict checks, mirror application, connectivity tests, or diagnostic reporting. Therefore the description does not accurately represent what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The description presents a broad orchestration and diagnostic skill for many development tools, with environment-wide detection, diagnostics, and recommendations. The actual code chunk only implements Conda mirror configuration. It does include one declared aspect—proxy conflict checking—and performs expected setup tasks like backup, config generation, cache cleaning, and basic validation. However, its primary purpose is much narrower than the declared skill description, and the major multi-tool diagnostic/orchestration behavior is absent from this code chunk. There is also a likely implementation bug: setup_conda_mirror calls generate_conda_mirror, but the defined function is generate_condarc. That bug does not change the mismatch determination.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The declared description is for a comprehensive, self-contained entry point that configures and diagnoses many development tools in China network conditions. The supplied code instead implements a narrow Docker-specific setup script for configuring Docker CE installation package mirrors on Linux. It changes apt/yum repo files, installs prerequisite packages, fetches a GPG key, updates package caches, and warns that Docker Hub image mirrors are different. Those actions are consistent with one small part of the declared system, but the code chunk does not exhibit the broad orchestration, diagnostics, tool detection, proxy checking, or recommendation features claimed in the description. Therefore, the description does not accurately represent this specific code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description is for a broad, all-in-one tool configuration and diagnostic entry point covering many package managers and network checks. The supplied code chunk only implements Flutter mirror setup. It edits ~/.bashrc, ~/.bash_profile, or ~/.zshrc to set FLUTTER_STORAGE_BASE_URL and PUB_HOSTED_URL, removes prior Flutter config blocks, backs up the profile, and warns about proxy conflicts via a shared helper. While proxy-conflict checking aligns partially with the description, the primary purpose and scope are much narrower than declared, and the advertised diagnostic capabilities are absent from this code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The description presents a broad, self-contained umbrella skill for setup and diagnostics across many development tools in China's network environment. The actual code chunk is much narrower: it handles GitHub-related acceleration only, specifically release URL rewriting, global git insteadOf rules for GitHub via ghfast, and one curated flutter-sdk mirror mapping. While the script does include a proxy-conflict warning hook from common utilities, that is only a small supporting detail and does not substantiate the declared comprehensive diagnostic behavior. This is therefore a clear description-behavior mismatch due to substantial overstatement of scope and capabilities.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description is for a broad, all-in-one environment configuration and diagnostics skill, but the supplied code chunk only implements a narrow Go proxy setup operation. It modifies shell startup files to set GOPROXY/GO111MODULE, validates a selected Go mirror, and checks for Go installation. While proxy-conflict checking is mentioned and likely provided by a shared helper, there is no evidence here of multi-tool detection, diagnostics, source connectivity testing, recommendation generation, or acting as a central entry point. Therefore the description materially overstates and misrepresents what this specific code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description portrays a broad, centralized skill for both configuration and diagnostics across many development tools and network conditions in China. The supplied code chunk is much narrower: it is specifically scripts/homebrew/setup.sh and only configures Homebrew mirrors. It does include one declared-supporting behavior—checking for proxy conflicts—and it can install Homebrew if missing, but it does not implement the multi-tool detection, diagnostics, source connectivity tests, comparison of mirror speeds, or recommendation generation described as core functionality. This is therefore a material description-versus-behavior mismatch for the supplied code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The description presents a self-contained, top-level orchestration and diagnostic skill for many development tools across the system. The actual code provided is narrowly scoped to Python package manager mirror setup: it manages pip, uv, and some poetry-related guidance. While some elements align with the description at a small scale—such as checking for proxy conflicts and configuring mirrors—the primary scope and capabilities are materially narrower than claimed. There is no implementation here for npm/yarn/pnpm, docker, apt, cargo, go, conda, flutter, or homebrew, and no comprehensive diagnostic behavior such as connectivity tests, mirror speed comparisons, or recommendation generation. Therefore the declared description does not accurately represent this supplied code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The supplied code chunk does not implement the declared primary purpose of configuring mirrors, detecting installed tools, diagnosing network connectivity, checking proxy conflicts, or generating recommendations. Instead, it is a backup restoration utility focused on enumerating backups and restoring prior configuration files for specific tools. That is a materially different purpose and an undeclared capability relative to the description. While backup/restore could be related to a broader configuration-management skill, this specific code chunk is not accurately represented by the declared description as written.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a broad, centralized tool for full-environment configuration and diagnostics across many package managers and development tools. The supplied code chunk is much narrower: it only configures Rust/Cargo mirror settings and emits rustup-related guidance. While one declared element—checking for proxy conflicts—is partially reflected via a helper call, the script does not implement the description’s primary multi-tool orchestration or network-diagnostic behavior. This is therefore a material description-to-behavior mismatch due to substantially overstated scope and capabilities.

Credential Access

High

• Category: Privilege Escalation

Content

# Format: tool_name:path1,path2,...
declare -A TOOL_CONFIGS=(
    ["pip"]="${HOME}/.config/pip/pip.conf,${HOME}/.pip/pip.conf"
    ["npm"]="${HOME}/.npmrc"
    ["docker"]="/etc/docker/daemon.json"
    ["apt"]="/etc/apt/sources.list,/etc/apt/sources.list.d/*"
    ["homebrew"]="${HOME}/.bash_profile,${HOME}/.zshrc,${HOME}/.config/fish/config.fish"

• Confidence: 89% confidence
• Finding: The script explicitly backs up ${HOME}/.npmrc, which commonly contains registry authentication tokens, scoped credentials, or private registry settings. Copying credential-bearing files into a backup store increases the attack surface and can expose secrets if the backup directory has weaker permissions, is later archived, or is readable by other users/processes.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Remove old docker.list if exists
    if is_root; then
        rm -f /etc/apt/sources.list.d/docker.list
    else
        sudo rm -f /etc/apt/sources.list.d/docker.list
    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

# Remove old docker.list if exists
    if is_root; then
        rm -f /etc/apt/sources.list.d/docker.list
    else
        sudo rm -f /etc/apt/sources.list.d/docker.list
    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).

Credential Access

High

• Category: Privilege Escalation

Content

# Add Docker's official GPG key
    log_info "Adding Docker GPG key..."
    local keyring_dir="/etc/apt/keyrings"
    if is_root; then
        install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"

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

Credential Access

High

• Category: Privilege Escalation

Content

# Add Docker's official GPG key
    log_info "Adding Docker GPG key..."
    local keyring_dir="/etc/apt/keyrings"
    if is_root; then
        install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"

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

Credential Access

High

• Category: Privilege Escalation

Content

# Add Docker's official GPG key
    log_info "Adding Docker GPG key..."
    local keyring_dir="/etc/apt/keyrings"
    if is_root; then
        install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"

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

Credential Access

High

• Category: Privilege Escalation

Content

# Add Docker's official GPG key
    log_info "Adding Docker GPG key..."
    local keyring_dir="/etc/apt/keyrings"
    if is_root; then
        install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"

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

Credential Access

High

• Category: Privilege Escalation

Content

log_info "Adding Docker GPG key..."
    local keyring_dir="/etc/apt/keyrings"
    if is_root; then
        install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
        chmod a+r "$keyring_dir/docker.asc"
    else

• Confidence: 90% confidence
• Finding: Saving a remotely retrieved repository signing key into APT's trusted keyring establishes a new trust root for package installation. If that key is not independently authenticated, an attacker controlling the mirror or network path can introduce a malicious key and cause arbitrary code execution later through trojaned packages.

Credential Access

High

• Category: Privilege Escalation

Content

if is_root; then
        install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
        chmod a+r "$keyring_dir/docker.asc"
    else
        sudo install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null

• Confidence: 89% confidence
• Finding: This line streams a remote GPG key into a trusted system keyring path under sudo. Because that key determines which packages APT will trust, accepting it from a mirror without fingerprint verification can let an attacker establish a malicious package-signing root.

Credential Access

High

• Category: Privilege Escalation

Content

curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
        chmod a+r "$keyring_dir/docker.asc"
    else
        sudo install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
        sudo chmod a+r "$keyring_dir/docker.asc"
    fi

• Confidence: 89% confidence
• Finding: Writing network-supplied key content into the APT keyring path with elevated privileges creates a persistent trust-anchor change. In the context of a bootstrap skill that reconfigures package sources, this is especially dangerous because it can silently affect all future package installs.

Credential Access

High

• Category: Privilege Escalation

Content

chmod a+r "$keyring_dir/docker.asc"
    else
        sudo install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
        sudo chmod a+r "$keyring_dir/docker.asc"
    fi

• Confidence: 92% confidence
• Finding: The piped `curl | sudo tee` pattern directly installs a repository key into the system trust store with no cryptographic identity check beyond TLS to the mirror. Compromise of the mirror, CDN, DNS, or local TLS trust can result in a malicious signing key being trusted for privileged package installation.

Chaining Abuse

High

• Category: Tool Misuse

Content

chmod a+r "$keyring_dir/docker.asc"
    else
        sudo install -m 0755 -d "$keyring_dir"
        curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
        sudo chmod a+r "$keyring_dir/docker.asc"
    fi

• Confidence: 91% confidence
• Finding: This command chains a remote download directly into a privileged write, collapsing trust, validation, and installation into one step. In a repository bootstrap context, that makes the host trust whatever key the mirror serves and can enable malicious package installation with root impact.

Chaining Abuse

High

• Category: Tool Misuse

Content

if is_root; then
        echo "$repo_line" > /etc/apt/sources.list.d/docker.list
    else
        echo "$repo_line" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    fi

    # Update package list

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

if is_root; then
        echo "$repo_line" > /etc/apt/sources.list.d/docker.list
    else
        echo "$repo_line" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    fi

    # Update package list

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Static analysis

No suspicious patterns detected.