T03 · Remote Payload Retrieval and Execution
- Location
scripts/deploy-k3s.sh:98- Finding
Unpinned Remote Installation Script Executed with Administrative Privileges
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill matches a K3s deployment purpose, but it uses high-impact root SSH automation, unverified remote installers, and insecure handling of cluster credentials.
Review this before installing on real infrastructure. Use only on hosts you intend to reconfigure, prefer SSH keys with verified host keys over passwords, pin and verify K3s installers and container images, avoid command-line secrets, secure or eliminate temporary token files, and plan rollback before applying the troubleshooting repair commands.
scripts/deploy-k3s.sh:98Unpinned Remote Installation Script Executed with Administrative Privileges
scripts/deploy-k3s.sh:49SSH Host Authentication Disabled for Privileged Deployment Sessions
scripts/deploy-k3s.sh:134Command and Configuration Injection Through Unvalidated Shell Interpolation
scripts/deploy-k3s.sh:106Administrative Passwords and Cluster Join Token Handled Insecurely
scripts/deploy-k3s.sh:68Privileged Cluster Components Pulled from Third-Party Mirrors by Mutable Tags
The description understates sensitive behavior: remote root SSH access with passwords, high-privilege system changes, handling of cluster join tokens, and kubeconfig manipulation. This is dangerous because users may authorize the skill expecting routine installation help, while it actually performs credentialed cross-host administration and writes sensitive artifacts to disk.
curl -sfL https://get.k3s.io | sh downloads and immediately executes a remote script as root on the target master without pinning content or verifying integrity. This creates a high-risk supply-chain execution path: compromise of DNS, TLS trust, the upstream distribution point, or any in-path dependency can result in full cluster and host compromise.
# 安装 K3s
log_info "安装 K3s Server..."
ssh_exec $host $user $pass "curl -sfL https://get.k3s.io | sh -s - server \
--flannel-backend vxlan \
--cluster-cidr 10.244.0.0/16 \
--service-cidr 10.96.0.0/12 \
The script rewrites the kubeconfig server endpoint by first changing 127.0.0.1 to 0.0.0.0, then to the host IP, effectively turning a local-only admin kubeconfig into a remotely usable one. In the context of a deployment skill, creating a remote-reachable cluster-admin credential on disk increases the blast radius if that file is exposed through the remote user account, backups, or lateral movement on the host.
export K3S_TOKEN=$token
log_info "集群 Token: ${token:0:20}..."
# 复制 kubeconfig
ssh_exec $host $user $pass "mkdir -p ~/.kube && cp /etc/rancher/k3s/k3s.yaml ~/.kube/config && \
sed -i 's/127.0.0.1/0.0.0.0/g' ~/.kube/config && \
sed -i 's/127.0.0.1/$host/g' ~/.kube/config"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
log_info "集群 Token: ${token:0:20}..."
# 复制 kubeconfig
ssh_exec $host $user $pass "mkdir -p ~/.kube && cp /etc/rancher/k3s/k3s.yaml ~/.kube/config && \
sed -i 's/127.0.0.1/0.0.0.0/g' ~/.kube/config && \
sed -i 's/127.0.0.1/$host/g' ~/.kube/config"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
log_info "集群 Token: ${token:0:20}..."
# 复制 kubeconfig
ssh_exec $host $user $pass "mkdir -p ~/.kube && cp /etc/rancher/k3s/k3s.yaml ~/.kube/config && \
sed -i 's/127.0.0.1/0.0.0.0/g' ~/.kube/config && \
sed -i 's/127.0.0.1/$host/g' ~/.kube/config"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
log_info "集群 Token: ${token:0:20}..."
# 复制 kubeconfig
ssh_exec $host $user $pass "mkdir -p ~/.kube && cp /etc/rancher/k3s/k3s.yaml ~/.kube/config && \
sed -i 's/127.0.0.1/0.0.0.0/g' ~/.kube/config && \
sed -i 's/127.0.0.1/$host/g' ~/.kube/config"
The worker installation repeats the same unsafe remote-script execution pattern on every joining node. In a multi-node deployment skill, this amplifies the supply-chain risk by turning one upstream compromise into fleet-wide root code execution across the cluster.
# 安装 K3s Agent
log_info "安装 K3s Agent..."
ssh_exec $host $user $pass "curl -sfL https://get.k3s.io | sh -s - agent \
--server https://$MASTER_IP:6443 \
--token $token \
--kubelet-arg container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \
Code deploys a privileged Kubernetes workload (privileged container, hostPath mount, or host namespaces). This grants root on the node and is a node/cluster takeover vector.
tier: node
app: flannel
spec:
hostNetwork: true
tolerations:
- operator: Exists
effect: NoSchedule
Code deploys a privileged Kubernetes workload (privileged container, hostPath mount, or host namespaces). This grants root on the node and is a node/cluster takeover vector.
mountPath: /etc/cni/net.d
volumes:
- name: run
hostPath:
path: /run
- name: cni
hostPath:
Code deploys a privileged Kubernetes workload (privileged container, hostPath mount, or host namespaces). This grants root on the node and is a node/cluster takeover vector.
mountPath: /etc/cni/net.d
volumes:
- name: run
hostPath:
path: /run
- name: cni
hostPath:
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).
health_check $MASTER_IP $MASTER_USER $MASTER_PASS
# 清理临时文件
rm -f /tmp/k3s-token.txt
log_info "=== 部署完成 ==="
}
The skill advertises operational deployment behavior that clearly implies shell execution and network access, yet it declares no explicit tool scope or permissions. This weakens user awareness and policy enforcement, making it easier for the skill to be invoked with broader capabilities than the metadata transparently communicates.
The trigger conditions are broad enough to match ordinary Kubernetes or K3s discussion, increasing the chance the skill is activated without clear user intent. In a skill that can perform remote administrative actions, accidental invocation raises the risk of unintended command execution or pressure to provide sensitive credentials.
The skill documentation does not clearly warn that it may require root SSH credentials and make privileged changes across multiple servers. In this context, missing warnings materially increase the chance that a user supplies powerful credentials without appreciating the blast radius, including filesystem, networking, and cluster configuration changes.
The document instructs overwriting /etc/cni/net.d/10-flannel.conflist via shell redirection, which can replace an existing working CNI configuration and break cluster networking. Because this is system-level networking state, an incorrect or generic replacement can leave nodes NotReady or worsen the outage.
The guide recommends pulling an image tagged latest, which is mutable and can change over time without notice. In an infrastructure deployment/troubleshooting skill, this undermines reproducibility and can introduce unreviewed or compromised image contents into cluster nodes.
The guide replaces /etc/docker/daemon.json wholesale and restarts Docker, which can discard existing daemon settings and affect all containers on the host. On shared or production systems this can interrupt workloads, alter registry trust behavior, or create configuration drift beyond the intended troubleshooting scope.
The troubleshooting guide includes disruptive repair commands such as restarting services, deleting pods, and deleting/reapplying a daemonset without clearly warning that these actions can cause outages, workload interruption, or loss of transient state. In a cluster operations skill, users may copy-paste these commands directly, increasing the chance of accidental production impact.
The script retrieves the K3s node join token from the master and persists it locally in /tmp/k3s-token.txt, while also exporting it into the local environment. That creates unnecessary local exposure of a sensitive cluster secret on the operator machine, where other users, processes, backups, or logs may access it.
Persisting an administrative kubeconfig in ~/.kube/config creates durable access to the cluster for that remote user beyond the installation session. In a shared or weakly managed server account, this becomes a persistence mechanism for ongoing cluster control if the account is later compromised.
log_info "集群 Token: ${token:0:20}..."
# 复制 kubeconfig
ssh_exec $host $user $pass "mkdir -p ~/.kube && cp /etc/rancher/k3s/k3s.yaml ~/.kube/config && \
sed -i 's/127.0.0.1/0.0.0.0/g' ~/.kube/config && \
sed -i 's/127.0.0.1/$host/g' ~/.kube/config"
Writing the cluster token to /tmp/k3s-token.txt without secure handling exposes a credential in a globally predictable temporary location. On multi-user systems or systems with weak /tmp hygiene, another local user or process could read the token and join unauthorized nodes or pivot into cluster administration.
The script claims to accept a password argument and then attempts to feed it into sshpass using -e, which expects the password from the SSHPASS environment variable rather than stdin. This mismatch can cause operators to misunderstand how authentication works, leading to insecure workarounds, failed automation, or accidental credential exposure while troubleshooting.
The script takes a password as a command-line argument, which can expose credentials through shell history, process listings, audit logs, and CI job output. In an infrastructure deployment skill, this is especially risky because the credential likely grants SSH access to cluster nodes, enabling broader compromise if leaked.
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
No suspicious patterns detected.