Unfortunately this approach doesn't work anymore in 2026. Every kernel update contains hundreds if not thousands of patches for cves (https://www.phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000 ). So whether you want to check whether an update applies to your environment or whether it might contain breakage: In both cases you need a dedicated team and still might get bite back by some missed issue. Shall Proxmox developers publish 2000 security advisorys per updated kernel because otherwise moronic change boards won't accept an update due to potential breakage? Have fun checking what's applicable to your environment then. Or do you happen to have a kernel security researcher on call who is able to give you an outcome which of the 2000 fixed CVEs of the last kernel applies to you or not under 24 hours (the time you need today to apply a patch before bad actors start exploiting the vulnerability: https://zerodayclock.com/)?
With other words: "Only apply needed patches" doesn't work either anymore, all you can do is to develop strategies to minimize breakage. Depending on your budget and other constraints this can be strategies for a fast rollback (by having a spare server with an older version), utilicing high-availability (on application and hypervisor level so you can first apply the patches to one node/vm, then to the others), rebuild systems automatically (see https://zerodayclock.com/call-to-action#stop-patching-start-rebuilding ) or whatever works for you.
But thinking, that "patch-management" aka "only apply needed fixes" still works in 2026 is at best naive wishful thinking and at worse gross negelect.
And yes I'm aware that in practice it's hard to do right in most corporate environments, but admitting the broken state of most IT environments (tbh including the one I work with for a living) is a start to actually fix this mess instead of working around of it.
Last edited:
