Proxmox's SDN patch now requires privileges it did not: update and somebody gets a 403

Among the fifteen security advisories Proxmox published from 10 to 12 November there is one that does not behave like a patch. PSA-2026-00092-1 fixes ACL checks that were missing from the SDN API and, along the way, requires privileges it did not require before. The advisory says so itself: "it was not, but is now required to have the SDN.Use or SDN.Allocate privilege on DNS and IPAM plugins, controllers, fabrics, route maps and prefix lists for referencing them in zones, controllers, fabrics and route maps". If SDN management in your cluster is shared between several people, moving libpve-network-api-perl to 1.6.8 will hand a permission refusal to somebody who created subnets fine yesterday.

The advisory even tells you where to look: "users who manage zones may need this privilege added, for example on '/sdn/ipams/pve' for the default IPAM". That sentence, buried in a four-paragraph security note, is the difference between a Tuesday-night update and a morning of calls asking why the new machine's network refuses to be created.

What it fixes and what it tightens

The fixing part is four quite specific authorisation flaws, reported privately by Geoffrey McClinsey. The IPAM zone parameter was validated against the wrong scope. Subnets were not checked against the parent VNet they belong to. Moving a VNet from one zone to another did not validate permissions on the target zone. And queries against the configuration —running and pending— were checked against the current configuration, which may hold entities other than the ones you are querying. On top of that, error messages disclosed whether a resource existed even when the user had no access to it.

All of that is door-closing work and changes nothing that works today. The tightening does. The objects the quote names —DNS and IPAM plugins, controllers, fabrics, route maps and prefix lists— are pieces referenced from a zone or a controller; having permission on the zone used to be enough, and now SDN.Use or SDN.Allocate on the referenced piece is required as well. The case that will bite in most places is the silliest one: the default IPAM, at /sdn/ipams/pve, which almost nobody has ever granted to anybody explicitly because it was never necessary.

This needs a window, not an unattended run

The order we follow when a patch carries a contract change is always the same. First, find out who holds permissions under /sdn/ paths today, which pveum acl list answers without modifying anything. Second, decide which concrete objects will need SDN.Use —starting with the IPAM you actually use— and write those ACL entries before touching the package, not after. Third, warn whoever holds delegated zones that there will be a spell where they may see a refusal, because the worst outcome of this advisory is not the refusal: it is somebody reading it as the cluster being broken and starting to undo things. And fourth, check afterwards that what worked still works, instead of taking the package manager's output as proof.

Studies of large internet service failures have for more than twenty years put operator configuration changes at the top of the causes of serious outages, with hardware accounting for 10 to 25 per cent (Oppenheimer, Ganapathi and Patterson, USITS 2003). A security patch is a configuration change, and one that alters who may call what is one twice over. In the checklist we apply to every production cluster the least-privilege token section exists for exactly this: the finer your delegation, the more an unread piece of small print costs you.

From the rest of the batch, the Backup Server one goes first

The other fourteen advisories run from 00086 to 00100 and spread across Virtual Environment, Backup Server, Mail Gateway and Datacenter Manager, with two touching several products at once. If the queue needs ordering, we put PSA-2026-00086-1 for Proxmox Backup Server at the front, and it has neither a CVE nor a score. A user holding only Datastore.Backup could create bogus snapshots in a group they own, and independently executed prune tasks "would treat such bogus snapshots as legitimate". Combining both, every legitimate snapshot in that group could be pruned, "thwarting the ransomware protection guards usually associated with only giving 'Datastore.Backup' privileges to a user/token". Fixed in proxmox-backup-server 4.2.9-1.

That order does not come from severity, it comes from whom it lands on. Datastore.Backup is the permission you give the cluster token precisely so it can write backups and cannot delete them, so the hole is eaten by whoever restricted the token properly rather than by whoever left it as an admin. Behind it come PSA-2026-00088-1 —command injection via a volume name, which with Datastore.AllocateSpace on ZFS-over-iSCSI storage runs as root on the storage array, and with VM.Migrate also on a migration target host; libpve-guest-common-perl 6.0.7, libpve-storage-perl 9.1.15, qemu-server 9.2.15— and PSA-2026-00095-1, which let whoever could reconfigure a container's NIC attach it to a bridge or VNet that was not theirs (pve-container 6.1.17).

The two that do not fit

Reading the batch end to end, it is easy to convince yourself that everything runs through a privilege somebody granted. Better not to, because two advisories do not. PSA-2026-00100-1, published on the 12th, says that "missing shell quoting while handling transfer failures during file upload handling could allow an attacker to execute arbitrary commands as root on the PVE node": root on the node, not on the storage array, and the advisory does not publish what privileges are needed to get there. It is fixed in libpve-storage-perl 9.1.15, the same package that closes half of 00088, so whoever updates for 00088 gets this one thrown in without knowing —and whoever does not, misses both.

The other is PSA-2026-00089-1, in libpve-http-server-perl 6.0.6, affecting both Virtual Environment and Mail Gateway. What it hardens sits below any permission model: requests with duplicate Content-Length, Host or Cookie headers are now rejected, underscore-to-hyphen mapping in header names is gone, and excessively long query strings are refused; concurrent writes to the access log and the injection of unescaped values into its lines were fixed too. The duplicate headers were privately reported by Apo, of CSB Raccoon Labs. This is the layer that handles the request before it knows who you are, which is why it does not fit the same reasoning as the rest.

When this is NOT urgent for you

If you have no SDN configured, the advisory this post is about does not touch you at all, and saying so costs us billable work. On a cluster with a single administrator, no ZFS-over-iSCSI and no OCI templates pulled from public catalogues, all fifteen fit in the normal maintenance window: none appears today in CISA's known exploited vulnerabilities catalogue or carries any indication of active exploitation, and fourteen of the fifteen do not even have a CVE. The exception is Mail Gateway. PSA-2026-00091-1 drags in ten CVEs from the third-party libmime-tools-perl library —CVE-2026-116264 to CVE-2026-116273, four of them at 7.5, one at 7.0 and five at 5.3— and there the attacker needs no privilege at all, because it is anybody who sends you mail. If you run PMG on the perimeter, that one moves to the front of the queue.

And what we do not know, said before anybody asks: of the fifteen we have read the full entry for twelve. For three we only have the headline and the product, not the fixed package: PSA-2026-00097-1 (authenticated SSRF via ACME directory URL) and PSA-2026-00098-1 (incomplete privilege checks when syncing users from external realms), both Datacenter Manager, and PSA-2026-00099-1 (incomplete UPID validation when handling stop-task requests), which the listing marks as affecting multiple products —so filing it under "a PDM thing" may mean skipping it on the cluster. All three titles fit suspiciously well with what this post argues, which is exactly why we do not use them as evidence of anything.

What is left when the batch passes

An advisory that forces you to grant a new permission only bothers you if you have handed permissions out. On a cluster where everybody logs in as root@pam —the admin, the developer who needed a test machine, the backup script, the vendor who dropped in one Tuesday— this update breaks nothing, and none of the three advisories in the batch that name a specific privilege applies. Not because you are protected: because a broken privilege check needs the check to exist. There the patch report comes back clean, and the credential that leaks one day arrives straight at the end of the road.

Rebuilding that table when it does not exist is an afternoon of work nobody has, and we already covered how it is done and where it goes wrong when we wrote that permissions do not travel from vSphere to Proxmox. What this week adds is the invoice: without that table there is no way to answer whether the SDN patch will lock somebody out, nor to decide in which order to touch four products. It is the least rewarding part of running virtualised infrastructure in production, and the part that decides whether the next batch is an afternoon or a week. We don't sell Proxmox licences, or anybody else's: what we deliver is the table.

Sources (verified 14 Nov 2026, 09:40 CET). The full range PSA-2026-00086 to PSA-2026-00100, with dates 10 and 12 November 2026 and the split by product, in vulnipulse.com's Proxmox advisory listing. Verbatim text and fixed packages from the entries reproduced at PSA-2026-00092-1 (the four ACL flaws, both quotes on the new requirement and on /sdn/ipams/pve, and Geoffrey McClinsey's private report), PSA-2026-00086-1 (both quotes on pruning and the "ransomware protection guards"), PSA-2026-00088-1, PSA-2026-00089-1, PSA-2026-00090-1, PSA-2026-00091-1 (the ten CVEs and their individual scores), PSA-2026-00093-1, PSA-2026-00094-1, PSA-2026-00095-1, PSA-2026-00096-1, PSA-2026-00087-1 and PSA-2026-00100-1 (the root-on-the-node quote). Honesty note on sources: the official channel is the Proxmox forum security advisories thread and we could not open the page of that thread where these fifteen live; everything we put in quotation marks comes from the linked reproductions, corroborated by a second independent aggregator. If any detail conflicts with the official advisory, the official one wins. pveum acl list ("Get Access Control List (ACLs)"), in the pveum(1) man page. The number-one cause of serious outages, in Oppenheimer, Ganapathi and Patterson, USITS 2003. KEV checked against CISA's catalogue. Ours is the framing —00092 is a change to the permission contract and not just a patch—, the four-step order for applying it, the reason to put PBS first, and the warning about the two advisories that do not fit that reading.