If you run Proxmox VE in a homelab or production environment, the LOLPROX research published in early 2026 should be on your radar. Security researchers demonstrated how attackers with even limited network access could leverage Proxmox's own management interfaces — the API, the web UI, and the SPICE/VNC consoles — to move laterally, escalate privileges, and persist inside a virtualized environment without triggering obvious alarms. The attack chains aren't theoretical. They work against default Proxmox configurations, which is exactly what makes them worth understanding and patching.

This guide breaks down what LOLPROX actually demonstrated, why default Proxmox setups are exposed, and gives you a concrete step-by-step checklist to close the most critical gaps.

What LOLPROX Actually Found

LOLPROX — a play on the "Living Off the Land" (LOTL) technique naming convention — showed that Proxmox ships with a powerful REST API accessible on port 8006 that, by default, has no rate limiting, no IP allowlisting, and exposes sensitive functionality to anyone who can reach it on the network.

The key attack paths researchers identified:

API token abuse: Once an attacker obtains a single API token (via phishing, credential stuffing, or a compromised VM), they can enumerate all VMs, read configurations, create new VMs, and extract storage content.
SPICE/VNC lateral movement: Proxmox's console access proxy doesn't always verify that the requesting session has the right to a specific VM. In certain configurations, an authenticated user at a lower privilege level can hijack console sessions for VMs they don't own.
Subscription nag bypass to RCE: Researchers found that the pveproxy process, which handles the web UI and API, can be coerced into unsafe behavior through crafted headers in unpatched versions.
Backup exfiltration: The Proxmox Backup Server API can be queried to download backup archives if the PBS instance is reachable and token validation is weak.

None of these require exploiting a kernel vulnerability or a zero-day. They're configuration and design issues you can address right now.

Step 1: Isolate the Management Interface

This is the single highest-impact change you can make. The Proxmox web UI and API should never be reachable from untrusted networks — including most of your VMs.

Create a dedicated management VLAN and put your Proxmox nodes on it. If you're using Linux bridges, add a tagged VLAN interface:

# /etc/network/interfaces snippet
auto vmbr0.10
iface vmbr0.10 inet static
    address 10.10.0.1/24
    vlan-raw-device vmbr0

Then bind pveproxy to only that management interface by editing /etc/default/pveproxy:

LISTEN_IP=10.10.0.1

Restart the proxy:

systemctl restart pveproxy

Now your API and web UI are only reachable from the management VLAN, not from your VM network or the public internet.

Step 2: Lock Down the Proxmox Firewall

Proxmox ships with its own firewall subsystem that most people either leave disabled or configure only at the VM level. You need to enable it at the datacenter and node level.

Enable the Datacenter Firewall

In the web UI: Datacenter → Firewall → Options, set Firewall: Yes.

Or via the CLI:

pvesh set /cluster/firewall/options --enable 1

Add Node-Level Rules

Create strict allowlist rules for the node firewall. Deny everything by default, then explicitly allow what you need:

# /etc/pve/nodes/<nodename>/host.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES] IN ACCEPT -source 10.10.0.0/24 -dport 8006 -proto tcp -log warning # Proxmox UI/API IN ACCEPT -source 10.10.0.0/24 -dport 22 -proto tcp -log warning # SSH IN ACCEPT -proto icmp # ICMP

Replace 10.10.0.0/24 with your actual management subnet.

Don't Forget Port 3128

Proxmox uses port 3128 for the SPICE proxy and console relay traffic. It should be restricted to the same management VLAN. Add it to your firewall rules:

IN ACCEPT -source 10.10.0.0/24 -dport 3128 -proto tcp -log warning

Step 3: Harden the API with Token Scoping and IP Restrictions

API tokens are extremely convenient for automation — and extremely dangerous if they're overly permissive. LOLPROX specifically demonstrated token abuse because most admins create tokens with broad rights and never expire them.

Create Scoped Tokens

Instead of one all-powerful token, create purpose-specific tokens with the minimum required privileges:

# Create a token for a backup script with only VM.Backup permission
pveum user token add backup@pam backuptoken --privsep 1
pveum acl modify / --token backup@pam!backuptoken --role PVEDatastoreAdmin

The --privsep 1 flag enables privilege separation, meaning the token can only do what you explicitly grant it — even if the user account has broader rights.

Rotate Tokens Regularly

There's no built-in rotation scheduler, so add a reminder or a cron job:

# List all tokens
pveum user token list backup@pam

Delete old token and recreate

pveum user token remove backup@pam backuptoken pveum user token add backup@pam backuptoken --privsep 1

Two-Factor Authentication for All Admin Accounts

Enable TOTP for every account with PVEAdmin or Administrator role. In the web UI: Datacenter → Permissions → Two Factor. Or force it at the realm level so no user in that realm can bypass it.

Step 4: Audit and Restrict User Roles

Proxmox has a fine-grained RBAC system that most admins underuse. The LOLPROX research showed that even PVEAuditor role accounts could be leveraged in some attack chains to extract useful enumeration data.

Audit your current ACLs:

pvesh get /access/acl

Look for any entries at the / (root) path — these grant cluster-wide access. Remove anything that doesn't need cluster-wide rights and scope it to a specific VM pool or storage instead:

# Restrict a user to a specific VM pool only
pveum acl modify /pool/devpool --user dev@pam --role PVEVMUser

Remove their cluster-wide access

pveum acl delete / --user dev@pam --role PVEVMUser

Step 5: Secure Proxmox Backup Server Access

If you're running PBS, its API is a goldmine for an attacker — backup archives contain entire disk images. Treat PBS security with the same seriousness as the Proxmox VE nodes.

Put PBS on Its Own VLAN

PBS should only be reachable from your Proxmox nodes, not from the general VM network or admin workstations directly (use a jump host).

Enable PBS Firewall

Same approach as the node firewall — edit /etc/proxmox-backup/host.fw:

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES] IN ACCEPT -source 10.10.0.0/24 -dport 8007 -proto tcp # PBS API/UI IN ACCEPT -source 10.20.0.0/24 -dport 8007 -proto tcp # Proxmox node network IN ACCEPT -source 10.10.0.0/24 -dport 22 -proto tcp # SSH

Use Encryption for Backup Archives

Client-side encryption means even if someone exfiltrates a backup archive from PBS, it's useless without the key. Generate an encryption key and configure it in Proxmox VE:

# On PBS or PVE node
proxmox-backup-client key create /etc/proxmox-backup/encryption-key.json

Then reference it in your backup job under Datacenter → Storage → your PBS storage → Edit → Encryption.

Step 6: Harden pveproxy and the Web Interface

The pveproxy service handles all HTTP traffic to the Proxmox UI and API. A few quick wins:

Force HTTPS-Only

Ensure pveproxy rejects plain HTTP. Check /etc/default/pveproxy:

HTTPS_CERT_FILE=/etc/pve/local/pve-ssl.pem
HTTPS_KEY_FILE=/etc/pve/local/pve-ssl.key

This is the default, but verify it hasn't been changed.

Replace the Self-Signed Certificate

Self-signed certs invite users to click through certificate warnings, which trains them to ignore them — making phishing easier. Use Let's Encrypt via the ACME integration in Proxmox:

In the web UI: Node → System → Certificates → Add ACME Domain.

Or use DNS challenge if your management interface isn't internet-facing (recommended):

pvenode config set --acmedomain0 proxmox.yourdomain.com,plugin=cloudflare
pvenode acme cert order

Restrict Cipher Suites

Add a pveproxy config to disable weak ciphers:

# /etc/default/pveproxy
CIPHERSUITE=ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305

Restart after changes:

systemctl restart pveproxy

Step 7: Monitor for Suspicious API Activity

Proxmox logs all API calls and authentication events. The LOLPROX attacks generate detectable noise if you're actually watching the logs.

Watch the Auth Log

Failed logins go to /var/log/daemon.log and the Proxmox task log:

journalctl -u pveproxy -f | grep -E 'FAILED|invalid|unauthorized'

Set Up fail2ban for the Proxmox API

Create a custom fail2ban filter for Proxmox authentication failures:

# /etc/fail2ban/filter.d/proxmox.conf
[Definition]
failregex = pvedaemon\[.*\]: authentication failure; rhost=<HOST>.*
ignoreregex =

Create the jail:

# /etc/fail2ban/jail.d/proxmox.conf
[proxmox]
enabled = true
port = 8006
filter = proxmox
logpath = /var/log/daemon.log
maxretry = 5
findtime = 600
bantime = 3600

Restart fail2ban:

systemctl restart fail2ban
fail2ban-client status proxmox

Forward Logs to a SIEM

If you're running a log aggregator (Graylog, Loki, Splunk), forward Proxmox logs. This is especially important for detecting the enumeration phase of a LOLPROX-style attack, which produces many low-severity API calls before anything destructive happens.

Step 8: Disable Unused Services and Close Attack Surface

Every service running on your Proxmox node is a potential attack vector. Review what's listening:

ss -tlnp

Services you likely don't need:

spiceproxy — If you don't use SPICE consoles (VNC is fine for most use cases): systemctl disable --now spiceproxy
postfix — If you don't use Proxmox's email notifications through a local MTA: systemctl disable --now postfix
rpcbind — Unless you're using NFS storage: systemctl disable --now rpcbind

For SPICE specifically, LOLPROX demonstrated that port 3128 lateral movement is only possible if spiceproxy is running. Disabling it entirely eliminates that attack surface.

Quick Checklist

Here's a summary you can work through systematically:

Conclusion

The LOLPROX research is a useful reminder that hypervisor security isn't just about patching CVEs. The attack chains it demonstrated work because Proxmox's default configuration prioritizes convenience over defense-in-depth, and most homelab and small production deployments never move beyond those defaults.

The good news is that none of the mitigations here are exotic. Network segmentation, firewall rules, scoped API tokens, 2FA, and log monitoring are standard security hygiene. Working through the checklist above takes a few hours but dramatically raises the cost of any LOLPROX-style attack on your environment. Start with Step 1 — isolating the management interface — and the rest becomes much easier to reason about.

LOLPROX: Protecting Proxmox from Hypervisor Exploits