StackX PX: targeted security fixes for Proxmox VE 8

StackX PX

Official support for Proxmox VE 8 ended on 31 August 2026. Yet Debian 12 Bookworm, which it is built on, receives LTS support until 30 June 2028. That Debian support does not cover Proxmox-specific components.

Proxmox of course proposes moving to VE 9. And you know what? That does not satisfy me.

Proxmox does not belong to me. I am not the one making the decisions; I have no say in it. I have been using it in production since version 2.1, perhaps earlier, and I have promoted it for a good part of my life, and still do today. I have literally installed hundreds of clusters that run or have run several tens of thousands of VMs in total. This is not a case against Proxmox VE. Long live Proxmox.

However, I know exactly what I expect from a virtualisation solution running critical systems and, first and foremost, just after stability, security and performance: security support at least until the end of LTS support for the Linux distribution it is built on.

I have never migrated to a Proxmox VE version as soon as it came out: not a single version. Every migration requires thorough testing and simulations of customers’ actual machines on the new infrastructure to find out what the impact might be on VMs and overall stability. I do not want to deal with repeated reboots, VMs freezing or other problems that will only be reported after weeks or even months of use.

What I can tolerate on a Linux distribution and fix more easily, I cannot tolerate on a hypervisor. Previous migrations usually went hand in hand with a move to new infrastructure. The new platform was already running the newer versions, and I migrated from one to the other.

This time, with hardware prices soaring, I have revised the schedule: under normal circumstances, I would have replaced the hardware in early 2027. Now I will keep it until at least 2029. I have also made a contractual commitment to do so.

So I looked into the impact of that migration, the temporary coexistence of VE 8 and VE 9 within the same cluster, and the list of unit and functional tests needed before moving hundreds of our clients’ machines.

Some of those machines are legacy systems with connections to industrial or medical systems. A change can have significant, unpredictable consequences. We need to check the applications, their communication with that equipment and the behaviour production depends on. That takes time, testing and operational experience.

As you may have seen recently with StackX PHP for Debian 9, 10 and 11, followed by the StackX LTS kernels, I am not the kind of person who leaves clients without a solution because their migration takes time. While we prepare and validate it, their services keep running. So I set about backporting the security fixes needed for the affected VE 8 components.

StackX PX therefore publishes a first set of targeted security fixes for Proxmox VE 8 on Debian 12 Bookworm, for amd64. The repository contains five application packages, one corrected kernel image and its matching headers.

Why have I decided to keep Proxmox VE 8 on part of the infrastructure?

For new clusters, that is a decision worth discussing, and it depends on the circumstances: internal needs, a private cloud for a client, and so on. Every case is different. But for our existing sensitive infrastructure, I need time to see how it behaves in practice and an environment I fully understand and control.

VE 8.4 and VE 9 can coexist within the same cluster during the upgrade, for a period Proxmox says should be kept as short as possible. Whenever I have found myself in that situation, that is what I have done. A rollback if something goes wrong is not guaranteed and may cause service interruptions.

VE 9 changes the Debian base, the kernel, QEMU, ZFS and several other components. It moved to Debian 13 Trixie; its first release used Linux 6.14 and QEMU 10, compared with Linux 6.8 by default and QEMU 9.2 in VE 8.4. These changes can alter the behaviour of a specific VM, driver, storage system or workload.

Without extensive testing using real cases, there is nothing to indicate that performance will at least match what we had before. That also matters when making this decision, because for some of our clients, a few milliseconds can make the difference.

Compatibility deserves the same precision:

For LXC containers, VE 9 no longer permits cgroup v1 or hybrid mode. Containers with systemd versions older than 232, including CentOS 7 and Ubuntu 16.04, therefore no longer have this compatibility path. VE 8 is the last branch that provides it: this does not affect me. I stopped using containers a long time ago; I only use KVM VMs.

For KVM VMs, the point requiring attention is old QEMU machine versions. Proxmox states that versions older than 6.0 are to be phased out during the VE 9 lifecycle. Updating them changes the virtual hardware exposed to the guest and may require some drivers to be reinstalled. The machine version stored in a snapshot with memory cannot be changed, so such a snapshot may no longer be resumable once that version disappears.

It may not be a common case, but I prefer to take it into account.

Finally, while Proxmox VE 9 adds features such as snapshots on thick-provisioned LVM storage, HA affinity rules, SDN fabrics and the ability to add disks to a RAIDZ pool without taking it down, none of that applies to me.

I hate LVM (each to their own xD), and I prefer storing directly on the filesystem without an abstraction layer.

At ScalarX, PRD/DRS are managed at VM level, just as they are for dedicated servers, independently of the hypervisors’ HA modes. And to finish: I do not use RAIDZ pools on hypervisors either. I only use ZFS on Proxmox Backup Server (PBS), or possibly on external storage.

To be perfectly honest, VE 8 already has far more features than we need. That is why I am also working on my own hypervisor, StackX Hypervisor (SXHV), with a tighter scope built around what we actually use in production. In fact, it is not unlikely that our next migration will be to SXHV rather than VE 9, at least for ScalarCloud’s Public Cloud units.

Scope of this first release

The five application packages retain the upstream VE 8 version and add a +sx revision. Modified sources are published alongside the binaries.

What was actually done

The Proxmox VE 8 sources were compared with the security fixes published upstream. The required changes were adapted to the versions still used by VE 8, then the packages were rebuilt and qualified in their target environment.

The original authors naturally retain attribution for the upstream fixes. The StackX work covers backporting, adaptation, rebuilding, repository packaging and the validation performed on Proxmox VE 8.

What was verified

Isolated checks covered the sources, binaries, dependencies and APT selection of the exact versions. The set was then installed on our own Proxmox nodes.

Operational validation covered, among other things:

• installation of the set and rebooting into the StackX kernel;
• VM startup and operation;
• snapshots;
• backup and restore with Proxmox Backup Server;
• live migration.

These tests reflect our nodes, configurations and use cases. They do not qualify every possible piece of hardware, driver, storage system, network or scenario.

Add the repository without installing anything

Before doing anything, arrange a recent and actually restorable backup, rescue-console access, a maintenance window and retention of the previous kernel.

Download the script first, read it, then execute it as root:

curl -fsSLo add-stackx-ve8-repo.sh https://mirrors.scalarx.net/stackx-px/ve8/add-stackx-ve8-repo.sh
less add-stackx-ve8-repo.sh
bash add-stackx-ve8-repo.sh

This script only configures the repository. It checks the platform, key and signed index, then adds the APT source. It installs no package, does not run apt-get update and does not reboot anything.

The repository is marked NotAutomatic: yes. It is therefore not intended to impose this set during an ordinary update. A plain apt upgrade may offer nothing.

Simulate the exact versions

Refresh the indexes, then explicitly simulate the installation in the same shell:

apt-get update

stackx_px_packages=(
  proxmox-ve
  qemu-server=8.4.10+sx00072.5
  libpve-http-server-perl=5.2.2+sx00089.2
  libpve-common-perl=8.3.8+sx00077.2
  pve-manager=8.4.21+sx00077.4
  pve-xtermjs=5.5.0-2+sx00075.2
  proxmox-kernel-6.8.12-43-sx3-pve=6.8.12-43+sx3.1
  proxmox-headers-6.8.12-43-sx3-pve=6.8.12-43+sx3.1
)

apt-get -s --no-install-recommends install "${stackx_px_packages[@]}"

Read the result produced on your own server. It must announce no removal and no unexpected package or dependency change, and must select the exact requested versions. The number of upgraded packages depends on the machine’s initial state.

Install, reboot and verify

If and only if the simulated plan is acceptable, run the installation while the same variable is still present in the shell:

apt-get --no-remove --no-install-recommends install "${stackx_px_packages[@]}"

The --no-remove option makes the operation fail if APT decides that a package must be removed. It does not replace reading the simulation beforehand.

Keep the previous kernel and its boot entry. Do not run apt autoremove as part of this procedure. Reboot during the planned maintenance window:

reboot

After the reboot, check the kernel that was actually loaded:

uname -r

If the StackX kernel was selected at boot, the expected value is 6.8.12-43-sx3-pve. Then verify networking, storage, Proxmox services, VMs and backups. If something goes wrong, the retained previous kernel provides a rollback path through the boot menu.

Limits

StackX PX provides targeted fixes for the packages listed on this page. It is not exhaustive maintenance for Proxmox VE 8.

This first set does not replace the pve-qemu-kvm binary and includes no VMA fix.

The VMA issue was excluded from the first set because the scenario described in Proxmox advisory PSA-2026-00067-1 requires a crafted VMA archive to be placed directly on the storage and then restored.

But we use PBS for backups. Even if we decided to make a VMA backup as an exception, locally or over NFS, no third party, client or service provider has any access whatsoever that would allow them to run or restore a backup.

Other components or security advisories may require separate releases.

The repository provides time to qualify a migration. It does not turn an old branch into an eternal release and never replaces a restorable backup, console access or testing on the actual platform.

Resources

• Official Proxmox VE support lifecycle
• Proxmox’s position on temporarily mixing VE 8 and VE 9
• VE 8.4 to VE 9 migration rules explained by the Proxmox team
• Debian 12 Bookworm LTS support until 30 June 2028
• StackX PX repository for Proxmox VE 8
• Repository setup script
• Script signature
• StackX PX public key
• Packages index
• Sources index
• Artifact checksums
• Proxmox VE security advisories
• KVM fix associated with CVE-2026-99082
• Official overview of what is new in Proxmox VE 9.0
• Official Proxmox VE 8 to 9 upgrade guide
• QEMU machine version policy in Proxmox VE

--
Christophe Casalegno
https://all.bo