alibabacloud-lingjun-cluster-manage

• Outcome: Review
• Latest audit: Sep 7, 2026 · 10:18 AM UTC
• Version: 0.0.1-beta.1

Overview

This is a coherent Alibaba Cloud cluster-management skill, but it should go to Review because key runtime and installation paths are not tightly bounded or verifiable.

Before installing, verify that the packaged runtime includes the expected lib/lj_init.sh and review it directly. Prefer a signed or package-manager Aliyun CLI install, avoid curl-to-bash installers, pin or administratively control the eflo-controller plugin version, and use a dedicated low-privilege or short-lived Alibaba Cloud profile rather than a broad long-lived AccessKey. Do not use the documented --insecure test-region path with production credentials or networks.

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 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

Findings (5)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/cli-installation.md:15
• Finding: Unverified Remote Installer Is Piped Directly into a Shell<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-installation.md:15-20` **Vulnerability Type**: Remote payload retrieval and immediate execution **Risk Level**: Critical ### Vulnerable Code ```markdown | Platform | Command | |---|---| | macOS (Homebrew) | `brew install aliyun-cli && brew upgrade aliyun-cli` | | macOS / Linux x86_64 | `curl -fsSL --connect-timeout 10 --max-time 120 https://aliyuncli.alicdn.com/setup.sh \| bash` | | Linux ARM64 | `wget https://aliyuncli.alicdn.com/aliyun-cli-linux-latest-arm64.tgz && tar -xzf aliyun-cli-linux-latest-arm64.tgz && sudo mv aliyun /usr/local/bin/` | | Windows | Download `https://aliyuncli.alicdn.com/aliyun-cli-windows-latest-amd64.zip`, unzip, and add to PATH | ``` ### Technical Analysis The installation command downloads a mutable shell script and passes it directly to `bash`. The fetched script is not pinned to a specific version and is not verified using a published checksum or cryptographic signature. TLS protects the connection under normal conditions, but it does not make the remote payload immutable. Compromise of the CDN, hosting account, release process, DNS resolution, or TLS trust path could change the code executed after the Skill has already been reviewed. The behavior is not necessary for cluster management. Installation can instead use a pinned package or a separately downloaded and verified archive. ### Attack Path 1. A user follows the documented macOS/Linux installation command. 2. The command retrieves `setup.sh` from the remote CDN. 3. The remote source, delivery path, or release process has been compromised. 4. The modified response is sent directly to `bash` without inspection or integrity verification. 5. The payload executes arbitrary commands with the privileges of the user running the installer. 6. If cloud credentials have already been configured, the payload may access them or invoke cloud APIs under the user's identity. ### Impact Assessment Successful expl ...[truncated 319 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the `curl | bash` installation path. 2. Pin the Aliyun CLI to a reviewed version. 3. Download the installation artifact as a separate step. 4. Publish and verify a SHA-256 checksum or cryptographic signature before execution. 5. Prefer an operating-system package manager where packages are signed and versioned. 6. Display or inspect installation scripts before running them. 7. Document the expected installer source, version, digest, and required privileges. 8. Avoid running the installer with elevated privileges unless a specific installation step requires them. ]]>

T08 · Insecure Dependencies

Error

• Location: references/cli-installation.md:22
• Finding: Automatically Installed and Updated CLI Plugin Is Not Version-Pinned< - eflo-controller API version is **not** pinned — the CLI default is used. ``` ### Technical Analysis The instructions enable automatic plugin installation and invoke an unrestricted plugin update without identifying a reviewed plugin version, immutable digest, signature, or release artifact. The Skill also explicitly states that the API version is not pinned. This creates a supply-chain boundary in which the effective implementation can change after the Skill has been audited. The plugin executes in the context of an authenticated CLI and processes sensitive cloud requests and responses, making dependency integrity particularly important. Automatic plugin installation may be convenient, but unrestricted updates are not the minimum behavior necessary for cluster management. A reviewed plugin can be installed explicitly and upgraded through a controlled process. ### Attack Path 1. The user or initialization library enables automatic plugin installation. 2. The CLI resolves the current `eflo-controller` plugin from its configured upstream source. 3. The upstream registry, release account, artifact, or update channel is compromised. 4. The CLI installs or updates to the compromised plugin because no revi ...[truncated 624 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable automatic plugin installation and automatic updates in production. 2. Pin the `eflo-controller` plugin to a reviewed version. 3. Verify publisher signatures or published cryptographic checksums. 4. Pin the compatible API version where the CLI supports doing so. 5. Maintain an approved dependency manifest recording the CLI version, plugin version, source, and digest. 6. Test upgrades in an isolated account before production rollout. 7. Require explicit administrative approval for plugin upgrades. 8. Fail closed if the installed plugin does not match the approved version or digest. ]]>

T07 · Tool Hijacking and Spoofing

Error

• Location: SKILL.md:4
• Finding: Environment-Controlled External Initialization Script Is Sourced Without Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:4-6`; repeated command patterns at `SKILL.md:99-102` and `SKILL.md:117-120` **Vulnerability Type**: Unverified shell sourcing and tool implementation substitution **Risk Level**: High ### Vulnerable Code ```markdown description: | What it does: manages Alibaba Cloud Lingjun cluster lifecycle via eflo-controller CLI — create / list / describe / delete clusters, list nodes, query machine types & images, tag / untag / list tags, change resource group. When to use it: when the user asks to create, query or delete a Lingjun cluster, list clusters or nodes, look up machine types or images, manage cluster tags, or change its resource group. Run: bash prefix: export LJ_SKILL_DIR="${LJ_SKILL_DIR:-$HOME/.qoder/skills/alibabacloud-lingjun-cluster-manage}" && source "$LJ_SKILL_DIR/lib/lj_init.sh"; i18n: CJK ratio 0.30+ → LJ_LANG=zh else en; stdout (skip ===...=== envelope blocks) is final reply; __LJ_EXEC__ or [Widget interaction] prefix → confirmed → one && chain. ``` The same trust pattern is used by operational examples: ```bash source "$LJ_SKILL_DIR/lib/lj_init.sh" && query <region> <subcommand> [args] ``` ```bash source "$LJ_SKILL_DIR/lib/lj_init.sh" && safe_mutate_oneshot <action> [--intent "<user words>"] aliyun eflo-controller <action> --region <R> [args] ``` ### Technical Analysis The Skill sources `lib/lj_init.sh` from a directory selected by the existing `LJ_SKILL_DIR` environment variable. Shell `source` executes every command in the selected file in the current shell process. The audited package does not contain the referenced `lib/lj_init.sh`. As a result, the implementations of `query`, `safe_aliyun`, `safe_mutate_oneshot`, `safe_mutate_confirm`, plugin installation, confirmation enforcement, and request rewriting cannot be validated from the supplied artifact. If an attacker can influence `LJ_SKILL_DIR` or modify the external installation directory, they can replace the trusted ...[truncated 1087 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Include `lib/lj_init.sh` and all runtime dependencies in the audited package. 2. Resolve the library relative to a trusted, immutable package root rather than an inherited environment variable. 3. Reject or ignore externally supplied `LJ_SKILL_DIR` values during normal execution. 4. Verify the library against a packaged cryptographic digest before sourcing it. 5. Require the Skill directory and library to be owned by the expected user and not writable by other users. 6. Use an executable with a narrow, documented interface instead of sourcing a large shell library into the current process. 7. Audit the implementations of all `safe_*`, query, confirmation, retry, and plugin-installation functions. 8. Fail closed when the expected library is missing or fails integrity validation. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/cli-installation.md:42
• Finding: Long-Lived Cloud Credentials Are Supplied as Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-installation.md:42-52`; similar examples at `references/cli-installation.md:56-65` and `references/cli-installation.md:85-88` **Vulnerability Type**: Sensitive credential exposure through command history, process arguments, and local plaintext configuration **Risk Level**: Medium ### Vulnerable Code ```markdown ### AK Mode Quick Setup (recommended) ```bash aliyun configure set \ --mode AK \ --access-key-id <your-key-id> \ --access-key-secret <your-key-secret> \ --region cn-hangzhou ``` Credentials are stored in `~/.aliyun/config.json`. ``` The short-term and role examples also place credentials directly in arguments: ```bash aliyun configure set --mode StsToken \ --access-key-id <id> --access-key-secret <secret> \ --sts-token <token> --region cn-hangzhou ``` ### Technical Analysis Substituting real secrets into the documented commands can expose them through shell history, terminal recording, debugging logs, command auditing, or process-argument inspection. The documentation also states that credentials are stored in `~/.aliyun/config.json` but does not require restrictive file permissions or describe encryption-at-rest protections. Recommending long-lived AK mode increases the duration and impact of accidental disclosure. Role-based or short-lived credentials provide a safer default for this workload. ### Attack Path 1. A user replaces the placeholders with an actual AccessKey ID and AccessKey Secret. 2. The shell records the command in history, or local process/audit tooling captures its arguments. 3. The CLI stores the credential in `~/.aliyun/config.json`. 4. A local attacker, support bundle, backup process, or diagnostic collector obtains the command record or configuration file. 5. The attacker authenticates to Alibaba Cloud using the exposed credential. 6. The attacker performs actions permitted by the credential's attached RAM policies until the key is revoked ...[truncated 406 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Prefer ECS RAM roles, workload identities, or short-lived STS credentials over long-lived AccessKeys. 2. Do not instruct users to put literal secrets directly into shell command arguments. 3. Use an interactive credential prompt that disables terminal echo, or a secure credential helper. 4. Warn users that command history and process arguments may expose secrets. 5. Require restrictive permissions on the configuration directory and file, such as mode `0700` for the directory and `0600` for the credential file. 6. Avoid including credential files in backups, support bundles, logs, or source repositories. 7. Rotate any credential that may have appeared in command history. 8. Attach only the minimum RAM policy required for the intended workflow and use separate identities for production and non-production environments. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/endpoint-and-regions.md:28
• Finding: TLS Certificate Verification Is Disabled Across All CLI Calls in Test-Region Sessions<![CDATA[ ## Vulnerability Details **File Location**: `references/endpoint-and-regions.md:28-42` **Vulnerability Type**: Insecure TLS configuration with unnecessarily broad scope **Risk Level**: Medium ### Vulnerable Code ```markdown ## ⚠️ Test Region `cn-wulanchabu-test-6` Requires `--insecure` This region is an internal test gateway with a self-signed TLS certificate. Once a session uses this region, **all** `aliyun ...` commands (including eflo-controller / bssopenapi / ecs / vpc) must append `--insecure`. ```bash # ✅ Correct aliyun eflo-controller list-clusters \ --endpoint eflo-controller.cn-wulanchabu-test-6.aliyuncs.com \ --region cn-wulanchabu-test-6 \ --insecure ``` ⚠️ **Never add `--insecure` in production commercial regions** (it bypasses TLS verification — a security risk). ⚠️ Put `--insecure` in the parameter area; do **not** stuff it into the `--endpoint` string. ``` ### Technical Analysis The `--insecure` option disables TLS certificate verification. Although the documented reason is a self-signed certificate on one internal test endpoint, the instruction expands the bypass to all Aliyun commands in the session, including unrelated services. This exceeds the minimum exception required for the declared test endpoint. It weakens endpoint authentication and permits a network-positioned attacker or malicious proxy to impersonate the destination server. Signed cloud API protocols may provide additional request integrity, but certificate verification remains necessary to authenticate the transport endpoint and protect responses and metadata. ### Attack Path 1. A user selects the documented internal test region. 2. The Skill begins appending `--insecure` to all Aliyun CLI commands in that session. 3. The user operates on a hostile or compromised network, DNS path, or HTTP proxy. 4. An attacker presents an arbitrary certificate and intercepts the TLS connection. 5. Because certificate validation is disabled, the CLI accepts the attacker ...[truncated 586 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Install and trust the internal gateway's CA certificate instead of disabling verification. 2. Scope any unavoidable exception to the exact test endpoint and exact command. 3. Never propagate `--insecure` to ECS, VPC, BSS, or commercial-region requests. 4. Keep test-region credentials and accounts isolated from production. 5. Reject attempts to combine `--insecure` with production endpoints. 6. Emit a prominent warning whenever certificate verification is disabled. 7. Use endpoint allow-listing for the internal test environment. 8. Remove the exception once the test gateway has a certificate chaining to an approved trust root. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The documentation instructs users to configure long-lived AccessKey credentials and notes they are stored in ~/.aliyun/config.json, but it does not warn that these secrets are locally recoverable by other processes or users with filesystem access. In a cluster-management skill, these credentials can enable creation, deletion, and modification of cloud resources, so omission of basic secret-handling guidance materially increases credential exposure risk.

External Script Fetching

High

• Category: Supply Chain

Content

| Platform | Command |
|---|---|
| macOS (Homebrew) | `brew install aliyun-cli && brew upgrade aliyun-cli` |
| macOS / Linux x86_64 | `curl -fsSL --connect-timeout 10 --max-time 120 https://aliyuncli.alicdn.com/setup.sh \| bash` |
| Linux ARM64 | `wget https://aliyuncli.alicdn.com/aliyun-cli-linux-latest-arm64.tgz && tar -xzf aliyun-cli-linux-latest-arm64.tgz && sudo mv aliyun /usr/local/bin/` |
| Windows | Download `https://aliyuncli.alicdn.com/aliyun-cli-windows-latest-amd64.zip`, unzip, and add to PATH |

• Confidence: 98% confidence
• Finding: The instruction pipes a remotely fetched script directly into bash, eliminating an opportunity for inspection and making users fully trust the network path, hosting endpoint, and upstream publisher at execution time. In a cloud cluster-management context, compromise of that script could install malware, steal Alibaba credentials, or tamper with CLI behavior used to manage or destroy infrastructure.

Static analysis

No suspicious patterns detected.