T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:47- Finding
Unverified Remote Installer Is Piped Directly into Bash
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a real Alibaba Cloud infrastructure-operations guide, but its install path and missing safety wrapper implementation create review-worthy risk.
Install only in a controlled Alibaba Cloud operations environment. Prefer a verified, pinned Alibaba Cloud CLI and plugin installation instead of curl-to-bash or automatic plugin updates, use the smallest RAM policy set needed, and review every confirmation carefully before reimage, renew, run-command, or resource-group changes.
SKILL.md:47Unverified Remote Installer Is Piped Directly into Bash
SKILL.md:59Alibaba Cloud Plugins Are Automatically Installed and Updated Without Version Pinning
references/scripts.md:49Sensitive Mutation Parameters Are Reversibly Serialized Under a Shared Temporary Directory
The schema permits tagging not only nodes but also clusters and Hypernodes, which exceeds the skill's stated node-operations scope. This creates a scope-expansion/authorization risk: a user invoking a node-focused skill could unintentionally or maliciously mutate metadata on broader, potentially higher-impact resources.
The untag operation allows removal of tags from clusters and Hypernodes despite the manifest presenting the skill as node-focused. Untagging can disrupt governance, automation, billing allocation, or security controls that depend on tags, and the presence of the --all option further increases the blast radius if used on broader resource types.
Allowing change-resource-group for clusters and Hypernodes broadens the skill from node management into moving larger infrastructure assets between resource groups. Resource-group reassignment can affect access control boundaries, billing ownership, policy application, and operational isolation, making this more dangerous than routine node lifecycle actions.
This schema exposes an update-node-group mutating capability even though the skill metadata explicitly states change-node-group is out of scope. That mismatch creates unauthorized capability expansion: an agent or caller relying on the declared scope could still trigger node-group level changes, including image, credentials, userdata, RAM role, and disk-related updates, which can materially alter fleet behavior.
The action goes beyond per-node lifecycle operations and enables broader node-group mutation, including changing defaults such as image, login password, user data, key pair, and RAM role. In a skill positioned as node operations, this increases the chance that higher-impact configuration changes are invoked without the stricter review or user expectations normally applied to provisioning/scaling workflows.
The workflow requires aliyun resourcemanager list-resource-groups, which enumerates all resource groups in the account before moving a single node. That broadens data access beyond the minimum needed for node operations and can expose organization-wide tenancy structure and identifiers to a skill that otherwise appears node-scoped.
Listing every resource group under the current account is broader than necessary to move one node and violates least-privilege principles. In the context of an ops skill, this can leak sensitive account topology, naming conventions, and administrative boundaries even when the user only intended a single-node metadata change.
This documentation enumerates destructive node power operations such as stop, reboot, and reimage, including parameters for batch targeting, but provides no explicit operator warning, confirmation guidance, or note about service interruption and data-loss risk. In an agent skill intended to drive infrastructure actions, omission of these cautions makes accidental misuse more likely and lowers the barrier to disruptive operations.
The run-command section documents arbitrary remote command execution across up to 50 nodes without any warning about privilege level, command safety, credential exposure, persistence modes, or production impact. Because this skill is specifically for node operations, normalizing unaudited shell execution materially increases the chance of destructive commands, lateral movement, or secret leakage if a user prompt or downstream agent is manipulated.
The node-group update documentation includes sensitive and high-impact configuration fields such as login passwords, image IDs, user-data, key-pair names, RAM roles, and disk settings, but does not warn about credential handling, rollout consequences, or configuration drift. In this operational skill context, these changes can silently alter future node provisioning behavior and expose secrets if mishandled.
The guide instructs users to execute a remote installer directly via curl ... | bash, which runs network-fetched code without giving the user an opportunity to inspect it first or warning about the trust implications. In an ops-focused skill that manages cloud nodes and credentials, this is more dangerous because users are likely to run the command in privileged environments where a compromised installer could steal Alibaba Cloud credentials or alter local tooling.
The document mandates use of --insecure for the test region, which disables TLS certificate validation and permits man-in-the-middle interception or endpoint impersonation if the network path is compromised. Although the text gives an operational reason (self-signed cert), it does not require an explicit user warning, certificate pinning, or any compensating control, so operators may normalize unsafe transport behavior for real node-management actions.
The manifest exposes a mutating reboot action but does not constrain or clearly document the intended invocation scope beyond generic required parameters. In an operational skill that can reboot up to 100 nodes asynchronously, underspecified scope increases the chance of overbroad targeting, accidental misuse, or unsafe invocation against production nodes without sufficient guardrails.
This schema describes an asynchronous node reboot operation but contains no user-facing warning that the action is disruptive and can cause service interruption, workload failure, or temporary unavailability. In a node-operations skill, omission of an explicit disruption warning materially raises the risk of an operator or agent triggering reboots without understanding the operational blast radius.
The file explicitly documents that a successful call immediately creates a fault report and causes the node to leave the Using state for a deep diagnosis workflow. Because this is a mutating, potentially disruptive operation, the absence of an explicit user warning/confirmation requirement raises the risk that an agent could trigger downtime-affecting behavior without the user understanding the operational consequences. In a node-operations skill, that context makes the side effect materially important rather than incidental.
This manifest exposes a general-purpose remote command execution action against up to 50 nodes with root defaults, but does not declare any manifest-level trigger constraints, safety gating, or exclusion conditions. In a node-operations skill, that means normal user prompts could be translated into arbitrary shell execution on infrastructure, increasing the chance of destructive misuse, prompt-injection-driven abuse, or accidental execution without sufficient confirmation.
The manifest provides remote command execution via CommandContent but does not include an explicit user-facing warning that commands will run on remote nodes, potentially as root and possibly repeatedly via reboot/period modes. Without a clear warning, users may not understand the destructive potential, and an agent may present the action as routine automation rather than privileged code execution.
The manifest defines a mutating action but does not specify invocation scope constraints such as required approvals, actor restrictions, or environmental boundaries. Without explicit scope controls, automation may invoke a write operation in unintended contexts, increasing the risk of unauthorized or accidental changes to production node-group configuration.
The reimage flow gates execution on an exact language-matched confirmation word, but the document does not define how the user's language is determined or how the user opts into that confirmation mode. In a destructive operation like reimage, this can cause ambiguous confirmation handling: a valid user intent may be rejected or, worse, a mismapped locale could accept an unintended confirmation token, increasing the risk of accidental destructive execution or unsafe operator workarounds.
This documentation guides operators through approving disruptive maintenance actions such as repair, reboot, and upgrade, but it does not clearly and explicitly warn that approving them can interrupt workloads, reboot the node, or temporarily remove capacity. In an ops skill that may be executed with user confirmation, omission of service-impact warnings increases the chance of accidental approval of high-impact actions, especially because the workflow emphasizes enum correctness and approval mechanics more than operational blast radius.
This skill documents and operationalizes in-place node type changes on live infrastructure without clearly warning about service disruption, performance changes, or workload impact beyond a narrow task-specific warning. In an infrastructure-operations skill, omission of operational risk guidance can cause an agent or operator to perform destructive or destabilizing changes on production nodes with insufficient caution.