Ubuntu maintenance: 83 package updates verified

#A defined scope for Ubuntu package updates

The packages came from the usual Ubuntu repositories, whose signed metadata was verified. Before installation, we compared the installed versions, available versions and expected changes. The final result matches the planned 83 updates, with no packages added or removed.

Systemd is now at version 259.9-0ubuntu0.1. The operating system remains Ubuntu 26.04 LTS. This intervention keeps the existing kernel, Node.js, Docker and PostgreSQL versions, along with the application versions already deployed. It requires no PRNext npm package update in your projects.

#Kernel security remains a separate follow-up

After reboot, both servers still run 7.0.0-43-generic from the Ubuntu 7.0.0-43.43 packages installed on 3 November. Those official packages were selected from the -proposed testing pocket following a specific decision and dedicated checks, without enabling that pocket globally.

When checked on 5 November, Ubuntu’s official tracker still describes this version as undergoing qualification for Ubuntu 26.04 LTS. The 83 package updates in this maintenance therefore do not constitute a new CVE-2026-98432 fix. Our previous article explains the kernel decision and the distinction between an available package, its distribution channel and the kernel actually running.

Ubuntu’s official tracker

Our previous article

#Why reboot into the same kernel?

Replacing a library on disk does not automatically renew the copy already loaded by a running process. After installation, our checks still found services using old libraries. We therefore rebooted the VPS instances in sequence, checking the first before proceeding with the second.

After each reboot, a fresh SSH connection confirmed that administrative access had returned. The final checks reported no service still using the old libraries. The SSH configuration and existing access were preserved. That is why a reboot was part of this work even though no new kernel was installed during the maintenance.

#Check services after startup

We checked DNS resolution, public HTTPS responses and PostgreSQL readiness, including a simple query confirming that the database answered. The five native application endpoints also returned HTTPS 200 responses with normal TLS verification.

Three containers were initially sleeping after reboot. HEAD requests to their native addresses woke them through the platform’s normal mechanism. All five containers were then observed running with the same identifiers and images. These checks establish that the tested endpoints returned to service; they do not validate every business workflow inside an application.

The temporary network filtering and MPTCP settings remained in place. We checked the rules after boot and confirmed that MPTCP was disabled in every observed network namespace, including after the containers woke. Those protections retain their limitations and do not replace the kernel fix.

#Keep phased updates under review

Seven packages on each server remained subject to Ubuntu’s phased rollout. We preserved this mechanism without forcing their installation. Ubuntu’s documentation explains that it distributes some updates in stages to limit the impact of a potential regression.

The same documentation states that security updates are never phased. A message about deferred packages therefore calls for checking their actual status rather than applying a general command to bypass that protection.

Ubuntu’s documentation

#What this means for your VPS

The 83 packages reflect our servers’ state at the time of the intervention. Your distribution, repositories and installed software will produce a different result. Compare the proposed update plan with your installation, prepare a recovery option and check the services your application depends on after renewing them.

This is a dated account: versions available today may change tomorrow. For the kernel, consult Ubuntu’s tracker for the vulnerability and your package family. For the application, exercise the functions that matter to your users as well. A successful HTTP response provides useful evidence whose scope needs to remain clear.