Proxmox Create Vm
WarnAudited by ClawScan on May 18, 2026.
Overview
The skill’s Proxmox automation purpose is clear, but its root-SSH scripts pass user inputs into shell commands without strong validation or escaping.
Install only if you are comfortable giving the agent root-level Proxmox control. Review generated commands before execution, avoid untrusted names or package arguments, use limited credentials where possible, and pin or verify downloaded binaries.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A malformed VM/container name or other argument could cause unintended commands or changes on the Proxmox host.
The container name is taken from script input and inserted into a remote Proxmox shell command without validation or shell escaping. Similar patterns appear for other arguments in the scripts. Because the remote command is run over SSH against Proxmox, unsafe input could alter the command that is executed.
NAME="${2:?Usage: $0 <proxmox-host> <name> [cores] [ram-mb] [disk-gb]}"
...
ssh "$HOST" "pct create $CTID local:vztmpl/$TEMPLATE \
--hostname $NAME \Validate IDs, hostnames, package names, and resource sizes against strict allowlists; properly shell-escape remote arguments; and require explicit user confirmation before running generated Proxmox commands.
If invoked with the wrong parameters or influenced by bad instructions, the skill can create, modify, stop, or destroy infrastructure with root-level authority.
Root SSH access is expected for this kind of Proxmox automation, but it gives the agent broad authority over the virtualization host and its guests.
## Requirements - SSH access to a Proxmox VE host (root)
Use a dedicated SSH key or account with the narrowest feasible Proxmox permissions, and review commands before execution.
A VM login password may be retained in logs or transcripts.
The VM password is accepted as a command-line argument and printed back in script output. This is understandable for returning access details, but it can expose the password in terminal, process, or agent logs.
PASSWORD="${3:?Usage: $0 <proxmox-host> <name> <password> [cores] [ram-mb] [disk-gb]}"
...
echo "User: deploy / $PASSWORD"Prefer SSH keys or one-time generated passwords, avoid reusing credentials, and rotate the password after first login.
The installed Compose binary could change unexpectedly or be unsafe if the upstream download path is compromised.
The script downloads a moving 'latest' Docker Compose binary and makes it executable without pinning a version or verifying a checksum/signature. This is purpose-aligned setup behavior, but it increases supply-chain risk.
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 -o /usr/local/lib/docker/cli-plugins/docker-compose chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
Pin a specific Docker Compose version and verify the published checksum or signature before installing.
A wrong ID could permanently delete the wrong Proxmox guest and its data.
The teardown helper can permanently stop and purge a selected container or VM. This is a disclosed cleanup capability, but there is no built-in confirmation or target-name verification.
ssh "$HOST" "pct stop $ID 2>/dev/null; pct destroy $ID --purge" ... ssh "$HOST" "qm stop $ID 2>/dev/null; qm destroy $ID --purge"
Confirm the VM/container name and ID before teardown, add an interactive confirmation, and consider requiring a matching name or label before destructive actions.