# CVE-2026-98432: when waiting for a kernel fix becomes a concern

Nineteen days have passed since Ubuntu published its CVE-2026-98432 entry on 15 October. For a team operating Internet-facing services, that wait is too long and concerning.

Our own intervention began on 30 October with temporary measures. On 3 November, four days later, we installed the official fix on both VPS instances and verified that they had booted into kernel 7.0.0-43-generic.

These Ubuntu packages come from the -proposed testing pocket. Ubuntu’s announced general qualification is still in progress: our verified installation does not turn these packages into an update already distributed through the usual stable channels.

## Why the wait matters

An application keeps responding. Its certificates are valid. Deployments succeed. None of those results establishes that a flaw in the kernel receiving network connections has been fixed. A service can look entirely normal while the security response remains unfinished.

For an administrator, every additional day means maintaining an interim decision, following announcements and preparing an intervention. That period is our concern. It supports neither an unsupported accusation of negligence nor allowing a temporary measure to become permanent through neglect.

## A fix exists, but its distribution channel matters

The Ubuntu announcement published on 2 November describes fixes in the -proposed testing pocket for several supported releases. For Ubuntu 26.04 LTS and the linux package, it names version 7.0.0-43.43. The announcement says publication in -updates will follow testing, without giving a firm date.

That changes how the situation should be described. Saying that no fix exists would be inaccurate. Saying that every Ubuntu VPS is already patched would be equally inaccurate. A package being tested, its availability through the usual update channels and its actual use on a machine are separate facts.

[Ubuntu announcement published on 2 November](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432)

## -proposed still requires a production decision

Canonical describes early access to proposed kernels as a choice for teams able to perform their own acceptance testing. This channel lets that work begin sooner. It does not establish that the wider qualification process is complete.

On a VPS serving real applications, the decision also involves the reboot, drivers, networking and recovery. Broadly enabling a repository and upgrading without reviewing the selected packages can expand the intervention beyond the intended fix. This article therefore does not provide a general command for switching a production machine to -proposed.

The useful question is not simply whether a fix is available. It is which channel provides it, for which distribution and kernel flavour, and with what validation.

[early access to proposed kernels](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy)

## Both VPS instances are running the patched kernel

The TinyDigit VPS moved from 7.0.0-38-generic to 7.0.0-43-generic. The PRNext VPS moved from 7.0.0-28-generic to 7.0.0-43-generic. On each server, we installed four Ubuntu kernel packages at version 7.0.0-43.43, then checked the actual running kernel after reboot.

Installation was limited to those packages, without a distribution upgrade or globally enabling -proposed. The previous kernels remain available as boot fallbacks. The temporary network filtering and MPTCP settings are also retained during this follow-up.

After the reboots, we opened a fresh SSH connection to each server and checked HTTPS responses from the PRNext and TinyDigit endpoints tested. The five original application containers are present and ready; their five native aliases also respond over HTTPS.

An external dependency remains unavailable; full application recovery still needs to be verified.

## Check the kernel that is actually running

The kernel package installed on disk can differ from the kernel currently executing. After an intervention, the check needs to cover the running system, fresh SSH access, HTTPS and the applications it hosts. A successful package manager exit is not enough to close the work.

These commands do not modify the server. They provide a starting point for comparison with the distribution’s official tracker. A version number alone, without the package identity and the distribution’s backported fixes, cannot establish the result.

```bash
uname -r
cat /etc/os-release
```

## Mitigation is not a kernel repair

Our original guide records the temporary measures applied on 30 October and the checks performed afterwards. It remains a historical account, rather than evidence of each VPS instance’s current state.

Disabling MPTCP does not repair the underlying flaw. Ubuntu’s tracker also describes limits to targeted IPv4 option filtering. A loaded rule, a packet counter or an accessible website does not guarantee protection against every exploitation path.

[original guide](/blog/cve-2026-98432-ubuntu-vps-mitigation)

## What a useful security update should tell you

It is reasonable to expect a clear account of what has been fixed, what is still being tested and what remains to be done on the machines themselves. It is equally important to recognise the cost of deploying a kernel update without sufficient validation. Urgency and stability belong in the same decision.

Our position is simple: an interim measure must remain visible in the work that still needs doing. The endpoint should be a patched version actually running with verified services, rather than a reassuring announcement alone. An npm update to PRNext cannot perform that Linux system task.

## Sources

[Ubuntu · CVE-2026-98432](https://ubuntu.com/security/CVE-2026-98432)

[Ubuntu · Fixes available in -proposed, 2 November 2026](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432)

[Canonical · Kernel release strategy](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy)

[Ubuntu · SRU verification](https://ubuntu.com/project/docs/SRU/reference/sru-verification/)

Published: 2026-11-03

Modified: 2026-11-03

Author: PRNext

---

Language: en

Canonical: https://prnext.dev/blog/cve-2026-98432-ubuntu-waiting-for-kernel-fix

Index: https://prnext.dev/llms.txt
