Back to skill

Security audit

Proxmox Full

Security checks for vulnerabilities and agentic risk

Overview

This Proxmox management skill is transparent about controlling infrastructure, but it teaches unsafe defaults that could expose credentials or cause destructive changes.

Review this skill carefully before installing. Use only a dedicated, least-privilege Proxmox token scoped to the nodes and actions you intend, keep TLS verification enabled with a trusted CA instead of curl -k, replace the example root password with SSH keys or a generated secret, and require explicit human confirmation before stop, rollback, restore, delete, or purge operations.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:32
Finding

TLS Certificate Verification Disabled for Authenticated Proxmox API Requests

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 32–285 and line 308
Vulnerability Type: TLS certificate validation bypass
Risk Level: High

Vulnerable Code

The documented API commands consistently use curl -k, including requests that transmit the Proxmox API token and perform privileged operations:

bash
curl -sk -H "$AUTH" "$PVE_URL/api2/json/cluster/status" | jq

curl -sk -X POST -H "$AUTH" \
  "$PVE_URL/api2/json/nodes/{node}/qemu/{vmid}/status/start"

curl -sk -X DELETE -H "$AUTH" \
  "$PVE_URL/api2/json/nodes/{node}/qemu/{vmid}?purge=1&destroy-unreferenced-disks=1"

The practice is explicitly recommended at line 308:

markdown
- Use `-k` for self-signed certs

Technical Analysis

The -k/--insecure option disables TLS certificate verification. Encryption may still occur, but the client no longer verifies that it is communicating with the legitimate Proxmox server.

Every request includes the reusable API credential through the Authorization: PVEAPIToken=$PVE_TOKEN header. An attacker capable of intercepting or redirecting network traffic can present an arbitrary certificate without causing curl to reject the connection. This allows the attacker to capture the token, inspect API responses, or modify privileged requests and responses.

Attack Path

  1. A user follows the documented commands against a Proxmox endpoint.
  2. An attacker gains a network interception position or redirects the configured endpoint through DNS, routing, or local network manipulation.
  3. The attacker presents an untrusted certificate.
  4. Because curl -k disables verification, the client accepts the certificate.
  5. The authenticated request, including the PVE_TOKEN authorization header, is sent to the attacker-controlled endpoint.
  6. The attacker captures and reuses the token against the genuine Proxmox API.
  7. Subject to the token's permissions, the attacker can inspect in ...[truncated 603 chars]
Remediation
View remediation

Remediation Suggestions

  • Remove -k from every documented curl command.

  • Install the Proxmox server certificate or issuing CA in the client's trusted certificate store.

  • For a private CA, use an explicit trusted CA file:

    bash
    curl --fail-with-body --show-error --silent \
      --cacert "/secure/path/proxmox-ca.pem" \
      -H "$AUTH" \
      "$PVE_URL/api2/json/cluster/status"
    
  • Consider certificate or public-key pinning for high-value automation.

  • Validate that PVE_URL uses HTTPS and points to an approved hostname.

  • Rotate the API token if it has previously been used over connections where certificate verification was disabled.

  • Fail closed when TLS verification fails rather than offering -k as the default workaround.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:85
Finding

Predictable Hard-Coded Root Password in LXC Provisioning Example

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 85–96
Vulnerability Type: Hard-coded default credential
Risk Level: High

Vulnerable Code

bash
curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/lxc" \
  -d "vmid=$NEWID" \
  -d "hostname=my-container" \
  -d "ostemplate=local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst" \
  -d "storage=local-lvm" \
  -d "rootfs=local-lvm:8" \
  -d "memory=1024" \
  -d "swap=512" \
  -d "cores=2" \
  -d "net0=name=eth0,bridge=vmbr0,ip=dhcp" \
  -d "password=changeme123" \
  -d "start=1"

Technical Analysis

The example configures a container root password as the predictable literal value changeme123 and immediately starts the container. Users who copy the command without replacing the example value create a network-connected workload with a publicly known administrative credential.

Passing the password in a command-line argument may also expose it locally through shell history, process inspection, terminal logging, or automation logs. The practical remote exploitability depends on whether password-based root authentication is enabled and whether a login service is reachable.

Attack Path

  1. An operator copies the documented LXC creation command without changing the password.
  2. Proxmox provisions the container with changeme123 as its root password.
  3. The start=1 parameter starts the container immediately on a bridged network using DHCP.
  4. An attacker discovers the container through network scanning or inventory exposure.
  5. If a password-based login service is available, the attacker authenticates using the documented credential.
  6. The attacker obtains root privileges inside the container.

Impact Assessment

Successful exploitation grants administrative control of the affected LXC container. An attacker could read or alter container data, install malware, steal application credentials, disrupt services ...[truncated 293 chars]

Remediation
View remediation

Remediation Suggestions

  • Remove the literal password from the example.
  • Prefer SSH public-key authentication and disable password-based root login.
  • If a password is required, generate a unique high-entropy value through a cryptographically secure secret generator.
  • Obtain the secret from a protected secret manager or interactive prompt rather than placing it directly in command arguments.
  • Do not start the container until authentication, firewall rules, and network exposure have been reviewed.
  • Add an explicit warning that example credentials must never be used in production.
  • Rotate the password on any container created from the current example and review it for unauthorized access.

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:18
Finding

Recommendation to Disable Proxmox API Token Privilege Separation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 18
Vulnerability Type: Excessive token privileges and weakened least-privilege isolation
Risk Level: Medium

Vulnerable Code

markdown
**Create API token:** Datacenter → Permissions → API Tokens → Add (uncheck Privilege Separation)

Technical Analysis

The documentation directs users to disable privilege separation when creating the Proxmox API token. A non-separated token inherits the effective permissions of its backing user instead of being constrained through independently assigned token ACLs.

While the Skill legitimately performs broad Proxmox management, making unrestricted inheritance the default increases the credential's blast radius and prevents operators from limiting the token to the nodes, guests, storage, and operations needed for a particular deployment.

Attack Path

  1. An operator follows the setup instruction and creates a token with privilege separation disabled.
  2. The token inherits all permissions available to its backing Proxmox user.
  3. The token is exposed through TLS interception, shell history, logs, environment leakage, endpoint compromise, or another credential-disclosure route.
  4. An attacker authenticates to the Proxmox API with the stolen token.
  5. The attacker exercises any inherited backing-user permissions, including permissions unrelated to the immediate automation task.

Impact Assessment

The resulting access is bounded by the backing user's ACLs, but it may span the cluster rather than a narrowly selected resource set. If the user is highly privileged, compromise could permit infrastructure enumeration, workload creation and control, backup access, snapshot manipulation, and destructive deletion.

This configuration does not independently create access for an unauthenticated attacker; it increases the privilege and scope available after token compromise or misuse.

Remediation
View remediation

Remediation Suggestions

  • Keep API token privilege separation enabled.
  • Create a dedicated non-human Proxmox user for automation.
  • Assign the token only the minimum roles needed for approved actions.
  • Scope ACLs to required nodes, pools, guests, and storage rather than the entire cluster.
  • Separate read-only inventory functions from destructive management operations by using different tokens.
  • Require explicit operator confirmation for deletion, purge, rollback, restore, and immediate-stop actions.
  • Store tokens in a secret manager, rotate them regularly, and revoke them immediately after suspected exposure.
  • Audit Proxmox task logs and API activity for unexpected use.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (8)

External Transmission

Medium
Category
Data Exfiltration
Confidence
91% confidence
Finding

This command sends a privileged API request to create and start a new LXC container on the Proxmox host, including a plaintext root password in the request body. In a high-privilege infrastructure-management skill, such state-changing external transmissions are dangerous because they can provision systems, expose credentials, and alter the virtualization environment if triggered improperly.

Content

Scanner excerpt · SKILL.md (reported line 85)May include surrounding context.

md
NEWID=$(curl -sk -H "$AUTH" "$PVE_URL/api2/json/cluster/nextid" | jq -r '.data')

# Create container
curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/lxc" \
  -d "vmid=$NEWID" \
  -d "hostname=my-container" \
  -d "ostemplate=local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst" \

External Transmission

Medium
Category
Data Exfiltration
Confidence
89% confidence
Finding

This command issues a privileged external API request to create a VM, which can consume infrastructure resources and modify production virtualization state. Because the skill is designed for full Proxmox control, an agent using this command without strong confirmation and parameter validation could create unauthorized or misconfigured systems.

Content

Scanner excerpt · SKILL.md (reported line 125)May include surrounding context.

md
NEWID=$(curl -sk -H "$AUTH" "$PVE_URL/api2/json/cluster/nextid" | jq -r '.data')

# Create VM
curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/qemu" \
  -d "vmid=$NEWID" \
  -d "name=my-vm" \
  -d "memory=2048" \

External Transmission

Medium
Category
Data Exfiltration
Confidence
90% confidence
Finding

These clone operations are privileged external transmissions that can duplicate VMs or containers, consuming storage and potentially replicating sensitive data or insecure configurations. In this context, cloning without safeguards can cause unauthorized proliferation of workloads and data exposure across the cluster.

Content

Scanner excerpt · SKILL.md (reported line 161)May include surrounding context.

bash
# Clone VM
curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/qemu/{vmid}/clone" \
  -d "newid=201" \
  -d "name=cloned-vm" \
  -d "full=1" \

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

Rollback and backup restore operations can overwrite or revert current system state, yet the skill presents them as routine commands without caution about downtime, configuration drift, or data loss since the snapshot/backup point. This is dangerous because an agent or operator may execute them without understanding that newer changes will be lost.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
92% confidence
Finding

The snapshot section includes create and rollback operations that send privileged requests to alter VM state on the hypervisor. Rollback is especially sensitive because it can revert disks and configuration to an earlier point, causing service interruption and loss of recent data.

Content

Scanner excerpt · SKILL.md (reported line 205)May include surrounding context.

md
curl -sk -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/qemu/{vmid}/snapshot" | jq '.data[] | {name, description}'

# Create snapshot
curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/qemu/{vmid}/snapshot" \
  -d "snapname=before-update" \
  -d "description=Snapshot before system update"

External Transmission

Medium
Category
Data Exfiltration
Confidence
94% confidence
Finding

The restore command sends a privileged API request that creates or reconstructs a VM from backup, overwriting intended state and potentially colliding with existing identifiers or storage plans. In production Proxmox environments, this can lead to service disruption, unexpected data rollback, and resource exhaustion if performed incorrectly.

Content

Scanner excerpt · SKILL.md (reported line 232)May include surrounding context.

md
curl -sk -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/storage/{storage}/content?content=backup" | jq

# Restore backup
curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/qemu" \
  -d "vmid=300" \
  -d "archive=local:backup/vzdump-qemu-100-2024_01_01-12_00_00.vma.zst" \
  -d "storage=local-lvm"

External Transmission

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 253)May include surrounding context.

curl -sk -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/storage/local/content?content=iso" | jq '.data[] | .volid'

Download template

curl -sk -X POST -H "$AUTH" "$PVE_URL/api2/json/nodes/{node}/aplinfo"
-d "storage=local"
-d "template=debian-12-standard_12.2-1_amd64.tar.zst"

text

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill documents irreversible deletion and purge operations for VMs and containers without any warning, confirmation guidance, or prerequisite checks. In an agent setting, this materially increases the chance of accidental destructive actions leading to permanent data loss or service outage.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.