Tracked as CVE-2026-98432, the flaw carries a CVSS score of 9.8 and involves a use-after-free condition in the Linux kernel’s IPv4 TCP connection-handling process. Under specific conditions, a remote unauthenticated attacker could trigger memory corruption or cause a system crash. Security researchers have also demonstrated the potential for remote code execution in certain configurations.
Veeam has confirmed that several of its products and supporting components are affected because they include their own Linux kernel. The company has released fixes for a number of these components through Veeam Updater, while Windows-based Veeam Backup & Replication deployments require a separate private fix for their Linux-based helper appliances.
The advisory deserves particular attention because backup infrastructure is often among the most sensitive systems in an enterprise environment. It holds access to backup repositories, recovery processes and, in some cases, the credentials and infrastructure needed to restore entire business operations.
A vulnerability affecting these systems is therefore not simply an operating system maintenance issue. It can become a business continuity and ransomware resilience concern.
What Is CVE-2026-98432?
CVE-2026-98432 is a use-after-free vulnerability in the Linux kernel’s IPv4 networking subsystem, specifically in the handling of TCP connection requests.
A use-after-free occurs when software continues accessing a piece of memory after that memory has already been released. If another process or operation reuses the same memory region, the original operation may encounter corrupted or unexpected data.
In this case, the vulnerability involves a race condition during the processing of TCP connection requests. A race condition occurs when two operations execute concurrently and their timing creates an unexpected result.
Under specific circumstances, a connection request can be processed while another operation is accessing associated socket options. Because the memory may be released before the second operation finishes using it, an attacker could potentially trigger memory corruption.
The consequences include:
- Denial of service through a kernel crash.
- Memory corruption that could compromise system stability.
- Potential remote code execution under vulnerable configurations.
The vulnerability is particularly concerning because exploitation does not require an attacker to authenticate to the affected system or persuade a user to interact with malicious content.
Red Hat describes the issue as a critical remote vulnerability that can be triggered through specially timed network requests. Its security bulletin also explains that disabling Multipath TCP (MPTCP) alone does not eliminate the vulnerability, since the affected code paths also exist in ordinary IPv4 TCP connection handling. Red Hat Customer Portal+1
Why Veeam Products Are Affected
Veeam’s advisory explains that the vulnerability affects components that include their own Linux kernel.
This distinction is important. The issue is not limited to the main Veeam Backup & Replication application. Several supporting appliances and infrastructure roles also run Linux-based components that must receive the appropriate kernel update.
Veeam has therefore provided different remediation procedures depending on the product, deployment model and operating system.
The affected components include Veeam Software Appliance 13.1, Veeam Infrastructure Appliance 13.1, workers deployed by hypervisor plug-ins, Linux-based helper appliances and certain cloud integration appliances.
For Windows-based Veeam Backup & Replication deployments, the Windows operating system itself is not the issue identified in this advisory. Rather, the Linux-based helper appliances deployed to perform specific backup and recovery operations are affected.
This means organizations should not assume that a Windows-based backup server is automatically outside the scope of the advisory.
Which Veeam Products and Components Are Affected?
According to Veeam KB4966, the following products and components require attention.
1. Veeam Software Appliance 13.1
Affected until the updated Linux kernel is installed.
Remediation: Install the update through Veeam Updater.
2. Veeam Infrastructure Appliance 13.1
The affected roles include:
- General-purpose backup proxy.
- VMware backup proxy.
- CDP proxy.
- Cache repository.
- Linux backup repository.
- Hardened repository.
- NFS share.
- Scale-out backup repository extent.
- Guest interaction proxy.
- Gateway server.
- Mount server.
- WAN accelerator.
- Log shipping server.
Remediation: Install the update through Veeam Updater.
3. Workers deployed by Veeam Plug-ins for hypervisors
These workers are affected until the updated kernel is installed.
Remediation: The workers automatically download and install updates from Veeam repositories when they are launched for a backup or restore operation.
4. Veeam Backup & Replication 13.1 on Windows
Linux-based helper appliances deployed by the Windows-based backup server are affected until the private fix is installed.
Remediation: Install the Veeam-provided private fix.
5. Veeam Backup & Replication 12.3
Linux-based helper appliances associated with this release are affected.
Veeam’s advisory states that the private fix will be made available soon. Organizations running this version should monitor the vendor advisory for its release rather than assume that the issue has been resolved.
6. Veeam Recovery Media for Veeam Agent for Linux 13.1
Recovery media created before the updated release is affected.
Remediation: Install the updated recovery media through Veeam Updater or download the updated version from Veeam’s official website.
7. Recovery Media included with Veeam Backup & Replication 12.3
Previously created recovery media is affected. The corresponding private fix is to be made available by Veeam.
8. Veeam Plug-ins for AWS, Google Cloud and Microsoft Azure
The associated appliances are affected until their Linux kernel updates are installed.
Remediation: Install all available updates through Veeam Updater.
What is not affected?
Veeam Kasten for Kubernetes container images do not include their own Linux kernel. They rely on the kernel of the underlying Kubernetes node.
Consequently, customers should follow the security advisory issued by their Kubernetes platform or node operating system provider.
Similarly, Linux servers managed directly by customers are not patched through Veeam. Their operating system updates must be obtained from the relevant Linux distribution vendor.Veeam Software
Veeam Releases Security Updates: What Administrators Need to Do
Veeam has confirmed that the kernel fix has been available in its repository since November 2, 2026, for Veeam Software Appliance and Veeam Infrastructure Appliance 13.1.
The updated kernel version is:
5.14.0-570.60.1+27.2.el9_6_ciq
Veeam Updater checks its repository every 12 hours. Under the default update configuration, mandatory updates are installed automatically on the nearest Sunday at 14:00, using the backup server’s configured time zone.
However, organizations do not need to wait for the automatic installation schedule.
Updating Veeam Software and Infrastructure Appliances
Administrators can install the update manually:
- Log in to the Veeam Host Management Console on the backup server.
- Navigate to Updates.
- Select Check for updates.
- Select the available updates and click Install Updates Now.
- Confirm the operation and allow the installation to complete.
- Restart the appliance if required.
If the infrastructure uses custom update configurations, administrators should repeat the procedure for each affected component.
Organizations using a local mirror of the Veeam repository must also ensure that the mirror has synchronized with the latest available updates.
After installation, check the History tab in the Veeam Host Management Console to confirm that the update was successfully applied.
Updating Hypervisor Workers
Workers deployed through Veeam Plug-ins for hypervisors receive the updated kernel when they are next launched for a backup or restore operation.
Veeam Backup & Replication automatically downloads available updates from its repositories and installs them during the worker launch process.
Security teams should nevertheless verify that these workers have actually been redeployed and are running the updated kernel rather than relying solely on the automatic update mechanism.
Updating Linux-Based Helper Appliances
This is an important area that administrators should not overlook.
Veeam uses Linux-based helper appliances for several operations, including:
- Guest operating system file recovery from non-Windows systems.
- Virtual Labs and proxy appliances.
- Restoring Linux workloads to Microsoft Azure.
- Restoring workloads to Amazon EC2.
- Restoring workloads to Google Compute Engine.
Some helper appliances are deployed temporarily and will receive the updated version the next time they are created.
Others remain deployed and require manual redeployment.
Virtual Labs: Administrators should open the settings of each Virtual Lab and proceed through its configuration wizard to redeploy the proxy appliance with the updated version.
Microsoft Azure helper appliances: Existing configured appliances must be removed and configured again to ensure that the updated appliance is deployed.
This step is particularly important because installing updates on the primary backup server does not automatically guarantee that every previously deployed helper appliance has been replaced.
Applying the Private Fix to Windows-Based Veeam Backup & Replication
For Veeam Backup & Replication 13.1 running on Windows, the private fix addresses the affected Linux-based helper appliances.
Before installation, Veeam requires Windows-based Veeam Backup & Replication version 13.1.2.57.
Administrators should verify their installed version through:
Main Menu → Help → About.
The private fix is available directly from Veeam:
Download Veeam Backup & Replication 13.1.2 Private Fix
Filename: VeeamBackup&Replication_13.1.2.57_20261105_PrivateFix.exe
SHA-256 verification:
63772D1ED2E9759E028F4D9693321E952B7D6D1FED4BAFC1C3C76D4DF2D0BE2B
Administrators should verify the downloaded file against this checksum before installation.
For Veeam Backup & Replication 12.3, Veeam’s advisory states that the corresponding private fix will be made available soon. Customers should follow the vendor’s updates.
What About AWS, Google Cloud and Microsoft Azure?
Veeam’s cloud plug-in appliances run Ubuntu Linux and receive kernel updates through Veeam Updater alongside the product updates.
Administrators should install all available updates and verify the status of the underlying kernel packages.
The Ubuntu security tracker provides additional information on the status of individual packages:
Ubuntu Security Tracker – CVE-2026-98432.
The Wider Linux Ecosystem Is Also Exposed
Although Veeam’s advisory focuses on its own products, CVE-2026-98432 is fundamentally a Linux kernel vulnerability. Its implications extend beyond backup software.
Red Hat has identified affected versions across Red Hat Enterprise Linux 8, 9 and 10, as well as Red Hat OpenShift environments. Its security bulletin warns that systems accepting incoming IPv4 TCP connections may be exposed.
The issue is not restricted to a particular application or service. It exists within the operating system’s networking stack.
Amazon Web Services has also published a security bulletin addressing the vulnerability. AWS reported that specially crafted IPv4 TCP packets containing IP options could trigger the flaw under specific conditions. It also confirmed that researchers had demonstrated unauthenticated remote code execution against hosts with an MPTCP listener.
AWS has released fixes for several Amazon Linux kernel packages and updated certain managed services and infrastructure images.
Ubuntu, meanwhile, announced on November 2 that fixes for Ubuntu 22.04 LTS and newer were available in its proposed package repository while testing continued before wider release.
This illustrates an important operational challenge: the availability of a fix varies by Linux distribution, kernel branch and product. Administrators must verify the actual package status for their environment instead of assuming that one vendor’s patch resolves the issue everywhere.
Why This Vulnerability Matters for Businesses
Backup infrastructure is often considered the last line of defence against ransomware, destructive attacks and major IT outages.
Organizations invest heavily in backup repositories, immutable storage, recovery environments and disaster recovery processes. However, these investments depend on the security of the underlying infrastructure.
A vulnerability in a Linux-based backup proxy, repository or helper appliance introduces another potential entry point into an environment that may have access to sensitive systems and data.
The potential consequences extend beyond the immediate impact of a kernel crash.
For businesses, a compromised backup component could disrupt backup operations, affect recovery services or create opportunities for further attacks against connected infrastructure.
There are several reasons this deserves attention.
Backup infrastructure is a high-value target.
Attackers increasingly understand that compromising backup systems can make ransomware incidents more damaging by affecting an organization’s ability to recover.
Remote exploitation increases exposure.
The vulnerability does not require authentication, making network exposure and the configuration of affected systems important considerations.
Hybrid environments complicate patch management.
Organizations may operate Veeam across on-premises data centres, cloud environments, virtualized infrastructure and multiple Linux distributions. Each deployment may require a different remediation procedure.
Recovery media can retain the vulnerability.
Updating the production backup environment does not automatically update recovery media created before the fix. Older recovery images must also be replaced.
For organizations in banking, telecommunications, government, healthcare, energy and critical infrastructure, these considerations make the advisory relevant to both cybersecurity and business continuity teams.
What Security Teams Should Do: 10 Recommended Actions
Beyond applying the vendor’s updates, security teams should use this advisory to review the resilience of their backup infrastructure.
1. Conduct a complete inventory of Veeam components.
Identify every Veeam Software Appliance, Infrastructure Appliance, proxy, repository, helper appliance, gateway server and cloud integration component. Include temporary and previously deployed systems in the assessment.
2. Verify the installed Linux kernel versions.
Do not rely exclusively on the version displayed in the Veeam management console. Confirm that the affected components are running the fixed kernel or the appropriate vendor-provided private fix.
3. Prioritize internet-accessible and network-exposed systems.
Review which affected systems accept incoming TCP connections and whether they can be accessed from untrusted networks. Restrict unnecessary exposure and limit access to trusted network segments.
4. Apply the appropriate Veeam updates immediately.
Use Veeam Updater for supported appliances and install the private fix where required. Follow the correct procedure for each product rather than applying a generic Linux patch across different Veeam components.
5. Review Linux-based helper appliances.
Identify existing helper appliances used for virtual labs, cloud recovery and guest file restoration. Redeploy persistent appliances where required to ensure they receive the updated kernel.
6. Replace outdated recovery media.
Generate new recovery media after installing the relevant update. Remove or clearly identify older recovery images so administrators do not unintentionally use vulnerable media during an emergency restoration.
7. Strengthen network segmentation around backup infrastructure.
Separate backup servers, repositories and management interfaces from ordinary user networks. Restrict communications to the services and systems genuinely required for backup and recovery operations.
8. Review privileged access and administrative credentials.
Apply least-privilege access, multifactor authentication where supported, privileged access management and regular reviews of administrator permissions. Backup infrastructure should not depend on broadly shared administrative accounts.
9. Monitor systems for unusual activity.
Review operating system logs, network activity and security monitoring alerts for unexpected connection patterns, service crashes, memory-related errors or suspicious activity involving backup components. Investigate unexplained disruptions rather than treating them as routine operational issues.
10. Test backup recovery and incident-response procedures.
Confirm that backups remain accessible, recovery media works and restoration procedures can be completed within business recovery objectives. Include backup infrastructure compromise in ransomware simulations and disaster recovery exercises.
These measures should complement, not replace, the installation of the appropriate security updates.
What This Means for the Middle East and Africa
For organizations across the Middle East and Africa, the advisory is particularly relevant to businesses operating hybrid infrastructure and regional data centres.
Financial institutions, government entities, telecommunications operators, healthcare providers and energy companies frequently depend on centralized backup infrastructure to protect distributed operations.
A vulnerable backup component can create a security concern that extends beyond the individual server, especially when it has access to multiple systems or sensitive repositories.
In the UAE and wider GCC, organizations should also consider how backup infrastructure security fits into their broader cybersecurity governance, operational resilience and business continuity requirements.
For African organizations relying on a combination of on-premises infrastructure and cloud-based backup services, the challenge may be more operational: maintaining accurate inventories, identifying the Linux components managed by third parties and ensuring that updates are applied across all environments.
This is also a reminder that vulnerability management should cover the complete technology stack, including supporting appliances and recovery environments, rather than focusing exclusively on applications and production servers.
Organizations looking to strengthen these capabilities can explore cybersecurity consulting, vulnerability management and GRC services through Saintynet Cybersecurity, alongside professional cybersecurity training and awareness programmes.
Final Thoughts
CVE-2026-98432 is a reminder that vulnerabilities in foundational technologies can have consequences far beyond the operating system itself.
For Veeam customers, the concern is not limited to the primary backup server. Linux-based proxies, repositories, helper appliances, cloud integrations and previously created recovery media all deserve attention.
The availability of fixes is encouraging, but applying them requires more than a routine update. Organizations must identify every affected component, follow the appropriate remediation procedure, redeploy persistent appliances where necessary and verify that recovery environments are also protected.
Backup infrastructure is supposed to help organizations recover from cyberattacks. Ensuring that the infrastructure itself remains secure should therefore be a priority for every security and IT operations team.
Do not wait for a backup failure to discover that your recovery infrastructure was vulnerable. Patch, verify and test your recovery capabilities.
Stay informed. Stay secure.
