Published 10 November 2026 · Rathish Kumar, Invitty
Backup servers are the systems you need most on your worst day, which makes a critical flaw in them worth acting on before anyone confirms an attack. On 6 November 2026 Veeam published knowledge base article KB4966 about CVE-2026-98432, a use-after-free bug in the Linux kernel code that sets up TCP/IPv4 connections. Veeam lists it at CVSS 9.8 and says it can cause a denial of service or memory corruption.
The bug sits in Linux, not in Veeam's own code. It matters to Veeam customers because the 13.1 appliances run a Linux kernel that Veeam ships and updates from its own repository. If your business adopted the Veeam Software Appliance or the Infrastructure Appliance for proxies and hardened repositories, the kernel on those boxes is now part of your patching job.
Why this one is moving up the queue
As of Veeam's article there is no confirmed exploitation and no public remote code execution exploit. Two things still push it up the list. First, SecurityOnline reports that several denial-of-service proofs of concept are already circulating, and knocking a backup repository offline during a ransomware attack would be damaging even without code execution. Second, researcher Marcus Hutchins has reported internet-wide probing of port 443 using MPTCP connections from 2 November, which he suspects is related to this CVE because ordinary scanners do not use MPTCP by default. That link is his assessment rather than a confirmed fact, but it is a reasonable warning that someone is looking.
Which Veeam components are affected
Veeam's KB splits the answer by product. In plain terms:
| Component | What to do |
|---|---|
| Veeam Software Appliance 13.1 | Install the fixed kernel through Veeam Updater; it has been in Veeam's repository since 2 November. |
| Veeam Infrastructure Appliance 13.1 (proxies, hardened repository, gateway, mount server, WAN accelerator and similar roles) | Same: update through Veeam Updater and restart if prompted. |
| Windows-based Backup & Replication 13.1 | Its Linux helper appliances are affected. Veeam has a private fix that requires build 13.1.2.57 to be installed first; new installs can use the repacked 13.1.2 ISO. |
| Windows-based Backup & Replication 12.3 | Helper appliances and Linux recovery media are affected. Veeam says a private fix is coming but it was not available at publication. |
| Workers for hypervisor plug-ins (13.1) | Pick up the new kernel automatically the next time they launch. |
| Cloud plug-in appliances for AWS, Azure and Google Cloud | Install all available updates through Veeam Updater. |
| Linux recovery media | Media created before the update still carries the old kernel; recreate it. |
| Veeam Kasten for Kubernetes | Not affected by Veeam's component, as its container images do not include a kernel. Follow your node OS vendor. |
| Linux repositories or proxies you built yourself (Ubuntu, Red Hat) | Not a Veeam component. Patch them through the distribution's own advisory. |
A practical order of work
For a typical Indian mid-size business with one backup server, a hardened repository and a couple of proxies, this is the sequence we would follow:
- Check what you run. In the Backup & Replication console, Help > About shows the exact build. Note whether your repository and proxies are Veeam appliances or Linux servers your team installed.
- Update the appliances first. In the Veeam Host Management console, go to Updates, check for updates and install. The History tab tells you whether the kernel update has already gone in. Restart when asked, outside a backup window.
- Apply the private fix on Windows servers running 13.1. Confirm 13.1.2.57 is in place before installing it, and keep the SHA256 value from the KB so you can verify the download.
- Redeploy long-lived helpers. Virtual labs and Azure helper appliances that stay deployed will not refresh by themselves. Helpers that spin up for a single job collect the fix next time they deploy.
- Rebuild recovery media. Any bare-metal recovery ISO or USB created before the update should be recreated and the old copies discarded, so nobody boots a vulnerable image during a real restore.
- Patch your own Linux boxes. If your hardened repository runs on a standard Ubuntu or Red Hat install, follow that vendor's kernel advisory and reboot.
Customers still on 12.3 should watch KB4966 for the promised private fix and, in the meantime, focus on exposure reduction below.
Reduce exposure while you patch
Nothing in a backup environment should accept connections from the internet unless there is a specific, documented reason, such as a Cloud Connect gateway. Check your firewall rules for any inbound NAT or port forwarding to backup appliances, management consoles or repositories, and remove what is not needed. Keep the backup network segmented from user networks, and restrict who can reach the Host Management console. These steps limit what any future kernel or Veeam bug can reach, not just this one.
If your hardened repository is your only copy
Some smaller organisations keep a single on-premises backup copy and treat it as the whole ransomware recovery plan. If that describes you, the hardened repository may be the only immutable copy you have. A denial-of-service bug against that box during an incident would delay recovery at the moment the business is under most pressure, and an attacker who could corrupt memory there would be in a worse position still. If you only have one copy, this is also a prompt to review whether an offsite or cloud copy belongs in next year's budget.
There is a renewal angle too. While you are in the console, note your Veeam licence and support expiry dates. If support has lapsed, ask Veeam or your partner now how you would obtain the 12.3 private fix when it is released, rather than finding out on the day.
Questions about the Veeam kernel fix
Is CVE-2026-98432 a bug in Veeam software?
Has this vulnerability been exploited?
We run Backup and Replication 12.3. Is there a fix yet?
Next step
If you are unsure which of your Veeam components are appliances and which are plain Linux servers, send us the Backup & Replication build number and a list of your proxies and repositories. We will mark which items need the kernel update, the private fix or a vendor OS patch, and check your support renewal date while we are at it. See our Veeam backup page, the broader backup and storage options, and the Veeam brand overview.