What's New in Security for Ubuntu 26.04

It's that time again. Another Ubuntu LTS, another two years of upstream churn condensed into a single shippable release, with the usual mix of performance wins, new defaults, and a handful of things worth knowing before you roll it out.

We took the same look at Ubuntu 24.04 two years ago. Plenty has been written elsewhere about 26.04's updated installer, desktop refresh, and assorted quality-of-life changes. We're here for the security story, which is genuinely the most interesting thing in this release, so let's dive in.

TL;DR

• The kernel is the headline. Ubuntu 26.04 ships Linux 7.0, packed with security work: Attack Vector Controls for managing CPU vulnerability mitigations, confidential computing support, BPF tokens so containers don't need kernel-wide BPF privilege, kernel stack erasing on by default, and a large pile of memory-safety fixes. If kernel attack surface matters to you, this release alone justifies the upgrade.
• Rust keeps eating security-critical utilities. The transition to Rust coreutils for ls, cat, chmod, and friends is now the default (cp, mv, and rm remain GNU for now due to unresolved TOCTOU bugs). sudo becomes sudo-rs. Memory safety at the command line is no longer a science experiment; it's /usr/bin. Most scripts won't notice. Some will, so plan for testing.
• Modern cryptography lands throughout the stack. OpenSSL 3.5 brings post-quantum hybrid key exchange to TLS by default. OpenSSH 10.2 makes post-quantum key exchange the default for SSH and removes DSA entirely. NGINX 1.28 makes HTTP/3 and TLS 1.3 production-ready and disables TLSv1 and TLSv1.1 by default. The kernel itself now includes post-quantum signature verification, which means kernel module signing can be post-quantum too. Meanwhile SHA-1 is gone from the paths that still mattered.

Table of contents

1. Linux kernel 6.8 to 7.0
2. TPM-backed full disk encryption
3. coreutils: GNU is out, Rust is in
4. sudo becomes sudo-rs
5. OpenSSL 3.0 to 3.5: post-quantum by default
6. OpenSSH 9.6 to 10.2
7. Identity services get privilege-stripped
8. Secure Boot and firmware hardening
9. NGINX 1.24 to 1.28: HTTP/3 ready for production
10. systemd 255 to 259
11. Other notable package stories
12. Time to upgrade?

Linux kernel 6.8 to 7.0

The kernel jumped from 6.8 to 7.0 in this release (release notes). The major version bump is a rollover, not a breaking change. Stable interfaces hold across it. What you actually get is nine upstream kernel releases of accumulated security work, which is the largest single security improvement in the entire 26.04 upgrade.

CPU vulnerability mitigation gets a management layer

If you've administered Linux servers for any length of time, you know how this usually goes. Every new Intel or AMD CPU vulnerability lands with another kernel boot parameter to tune its mitigation: spectre_v2=, mds=, retbleed=, l1tf=, spec_store_bypass_disable=, srbds=, gather_data_sampling=, spec_rstack_overflow=, and so on. You set these in your bootloader configuration (typically GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub), and they get baked into the kernel command line at boot. Keeping that string consistent across a fleet, and updated as new vulns drop, is tedious and error-prone.

Linux 7.0 introduces Attack Vector Controls (AVC), which groups the mitigations by threat-model class:

• user-to-kernel
• user-to-user
• guest-to-host
• guest-to-guest
• Simultaneous Multi-Threading (SMT) related

Why it matters: You declare your threat model once and the right mitigations get applied automatically. A single-tenant dedicated server running trusted workloads has a very different threat model from a multi-tenant cloud host, and AVC lets you express that directly instead of maintaining per-flag spreadsheets. When the inevitable next CPU vulnerability drops, it classifies into your chosen vectors automatically.

Other CPU-related improvements:

• AMD SEV-SNP and Intel TDX host support. Ubuntu 26.04 ships host support for both confidential computing technologies. Why it matters: you can now run virtual machines whose memory is encrypted and integrity-protected by the CPU itself. The hypervisor administrator, such as your cloud provider, cannot read guest memory. This is the foundation of modern confidential computing for regulated industries, financial services, healthcare, AI workloads, and anyone who needs to protect data while it's actively being processed.
• Arm Confidential Compute Architecture (CCA) guest support, the Arm equivalent for running as a confidential guest. Why it matters: confidential computing is no longer exclusive to x86 hardware. If you run on AWS Graviton or similar Arm-based cloud infrastructure, you now have a path to confidential VMs.
• Protected KVM (pKVM) for arm64, where the hypervisor is isolated from the host kernel on Arm. Why it matters: you get confidential-VM-style guarantees on Arm hardware that doesn't yet have full Arm CCA support.

Memory-safety hardening

• Kernel stack erasing is on by default. The kernel now wipes sensitive data from its stack after use, and the behavior is tunable via the kernel.stack_erasing sysctl. Why it matters: uninitialized stack memory has historically been a major source of information-disclosure vulnerabilities, including leaks of kernel pointers and cryptographic material. Closing that window reduces the payoff of an entire category of exploits.
• ARM Permission Overlay Extension / Memory Protection Keys (MPK) provides hardware-accelerated memory protection on modern Arm CPUs. Why it matters: applications that use Memory Protection Keys, like databases and JIT compilers, get faster and more reliable memory isolation without the usual system call overhead.
• Kernel Address Space Layout Randomization (KASLR), stack canaries, and Control Flow Integrity (CFI) all received continued incremental improvements across the 6.9 to 7.0 window. Why it matters: these are the mitigations that turn many kernel bugs from "reliable exploit" into "probabilistic crash."

Linux Security Modules and access control

• AppArmor, Ubuntu's default LSM and the layer enforcing every snap and system-service profile, picked up new kernel-side mediation hooks. SHA-256 replaced SHA-1 for policy hashes, the kernel grew hooks for io_uring operations, user namespace creation, POSIX and System V message queues, and abstract Unix sockets, cgroup v2 integration tightened, and there's continued performance work. The matching userspace rule syntax lands in AppArmor 5.0 (covered later). Why it matters: AppArmor is the LSM doing real confinement work on every Ubuntu system, from OpenSSH and CUPS to every snap on the desktop. Each new mediation hook expands what those existing profiles can restrict. io_uring in particular has been a steady source of kernel CVEs because it lets userspace bypass many traditional syscall paths, so AppArmor mediating it means a compromised service can't quietly escape through io_uring even if it slips past syscall filters. Canonical's shipped profiles pick up the new hooks over time; existing profiles keep working unchanged.
• Landlock picked up signal scoping and audit logging. The new LANDLOCK_SCOPE_SIGNAL restricts which processes can signal each other, audit logging now works for Landlock-denied operations, and enforcement overhead is low enough for always-on use. Why it matters: Landlock lets an application sandbox itself without requiring system-wide policy changes. The signal-scoping addition closes off a real pivot path where a compromised process would use signals to manipulate other processes.
• Integrity Measurement Architecture (IMA) and Extended Verification Module (EVM) moved into the standard LSM infrastructure for cleaner stacking with other LSMs. Why it matters: file integrity monitoring at the kernel level now plays better with AppArmor and other access control systems you already have.

BPF security

If you run containers that use BPF, which includes tools like Cilium, Falco, Tetragon, and Pixie, this matters:

• BPF tokens let a privileged daemon delegate specific BPF capabilities to unprivileged containers. Why it matters: before tokens, giving a container BPF access required handing it CAP_BPF, which is kernel-wide and can't be namespaced. That effectively granted the container access to BPF features far beyond what it needed. With tokens, you can say "this container can attach exactly these kinds of BPF programs" without blanket privilege. Significant attack-surface reduction for any container running observability or network security agents.
• BPF arenas provide a first-class shared memory primitive between BPF programs and userspace. Why it matters: previous BPF-to-userspace communication was ad-hoc with questionable bounds checking. Arenas give you a proper isolation model with the kernel enforcing boundaries.
• BPF verifier hardening represents two years of continuous correctness work on the static analyzer that gates kernel BPF execution. Why it matters: the verifier has historically been a rich source of kernel exploits; bugs in it have led directly to privilege escalation. Two years of correctness work means fewer ways for malicious or buggy BPF programs to escape their sandbox.

The rest of the kernel security diff

• Networking: TCP drop reasons for detection telemetry, vsock fixes, af_unix MSG_PEEK fixes, nftables maturation. Why it matters: TCP drop reasons let monitoring tools distinguish "packet dropped because of checksum failure" from "packet dropped because of zero window." Real improvement for Distributed Denial of Service (DDoS) analysis and abuse detection.
• System calls: new file_getattr() and file_setattr() with openat(2)-style path resolution close Time-of-Check-to-Time-of-Use (TOCTOU) edges in the older extended attribute (xattr) interfaces. Process file descriptors (pidfd) for threads reduce Process Identifier (PID) reuse races.
• KVM: SEV-SNP guest policy restrictions, a new KVM_IOAPIC disable option for removing legacy device emulation attack surface, and a preservation fix for host debug control state. Why it matters: you can now require SEV-SNP guests run on a single socket and disable SMT, which closes off side-channel paths. Disabling KVM_IOAPIC removes emulation code you don't need if you only run modern guests.
• Filesystems: Filesystem in Userspace (FUSE) passthrough mode reduces attack surface for userspace FUSE daemons.

Post-quantum cryptography lands inside the kernel itself

This one is critical enough to deserve its own section. The kernel's internal cryptography framework is the code that module signing, filesystem encryption, disk encryption, IPsec, kernel TLS, Integrity Measurement Architecture (IMA), and Secure Boot all depend on. In Ubuntu 26.04, that framework now includes Module-Lattice-Based Digital Signature Algorithm (ML-DSA) signature verification. ML-DSA is the NIST-standardized successor to classical signature algorithms, designed to resist attacks from quantum computers.

Why it matters:

• PKCS#7 and X.509 certificates can now validate ML-DSA signatures inside the kernel.
• Kernel module signing can use ML-DSA keys.
• Combined with OpenSSL 3.5 and OpenSSH 10.2, Ubuntu 26.04 has a consistent post-quantum story from boot loader through module signing through userspace TLS and SSH. That's coherent post-quantum coverage across the whole system, not a single point upgrade.

Also in the cryptography subsystem:

• New: ML-DSA verification, SHAKE256, the full SHA-3 family, HMAC for SHA-2 and SHA-3, NIST P-384 ECDSA for module signing, improved Authenticated Encryption with Associated Data (AEAD) in IPsec, and better kernel TLS 1.3 performance with hardware offload.
• Removed: SHA-1 in PKCS#7, SHA-1 in X.509 signature validation, MD4 in X.509, MD5 in X.509. The default module-signing hash moved from SHA-1 to SHA-512.

Why the removals matter: SHA-1 has been broken for practical purposes since 2017, when Google and Centrum Wiskunde & Informatica demonstrated the first SHA-1 collision attack, dubbed SHAttered. MD4 and MD5 were broken much earlier. Having them available in security-critical paths meant a misconfigured tool could still produce signatures that looked valid but weren't. Removing them eliminates that foot-gun. If your internal CA still issues SHA-1 certificates and any of them get imported into the kernel keyring, regenerate them before upgrading.

TPM-backed full disk encryption is now generally available

Ubuntu 26.04 promotes Trusted Platform Module (TPM) backed Full Disk Encryption (FDE) out of experimental status into general availability, with a first-class option for it directly in the installer. Earlier Ubuntu releases had this behind a feature flag and required custom partitioning gymnastics; 26.04 makes it a checkbox during install and is production-ready.

Why it matters: TPM-backed FDE anchors your disk encryption keys to the hardware rather than to a passphrase you type at every boot. The key is sealed against specific Platform Configuration Register (PCR) values that describe a known-good boot state. If an attacker swaps out your bootloader or kernel, the TPM refuses to release the key. The disk stays encrypted. No passphrase, no human intervention, just hardware-enforced boot integrity.

coreutils: GNU is out, Rust is in

This is the biggest user-facing change in the entire upgrade. Ubuntu 26.04 replaces most of GNU coreutils as the default with uutils, a Rust reimplementation. About 80 utilities (ls, cat, chmod, chown, du, head, tail, tr, wc, mkdir, ln, touch, and a long list of others) are now Rust binaries aiming for drop-in compatibility. Notable exceptions: cp, mv, and rm remain GNU due to unresolved TOCTOU race conditions that were deemed too data-destructive for an LTS release.

Why it matters: coreutils are called from shell scripts, system services, backup tools, and every configuration management system on the planet. They also parse untrusted input routinely, which means memory-safety bugs in them have real consequences. GNU coreutils has decades of hardening but is still C code with all the footguns that implies. Rust eliminates entire bug categories (use-after-free, double-free, buffer overflows) at compile time. Getting there means accepting some short-term compatibility risk in exchange for structural memory safety at the busiest part of the operating system.

The caveat: "aiming for drop-in compatibility" and "is drop-in compatible" are different sentences. Known rough edges include split, sort, and chroot behaviors and locale handling. Exit codes and error message formats may also differ subtly. This is the category of change where things mostly work, except for the one production script that doesn't.

A few things to know:

• ls --version tells you which implementation you have. GNU says "GNU coreutils." uutils says "uutils."
• The split is managed by two packages: coreutils-from-uutils (the new default) and coreutils-from-gnu (the classical GNU build). You can swap them via apt.
• Even with uutils as the default, every replaced command's GNU version is reachable via a gnu prefix: gnucp, gnutr, gnudate, gnusha256sum, etc. If a script breaks under uutils, you can call the GNU binary by name without flipping the system default.
• File integrity monitoring baselines from 24.04 won't match 26.04 for coreutils binaries. Plan your re-baselining.

The transition has been shipping since Ubuntu 25.04 and works for the vast majority of use cases. Still, test your scripts before rolling 26.04 to production. The GNU versions are always available as a fallback if you hit an edge case.

sudo becomes sudo-rs

While we're on the Rust-replacement theme: sudo is also now a Rust implementation by default. Ubuntu 26.04 ships sudo-rs as the default sudo provider, with the original sudo available as a fallback under the .ws suffix.

Why it matters: sudo is one of the most security-critical programs on any Unix system. It's in the trusted path for every privilege escalation on a typical server. It has also had meaningful CVE entries over the years, most notably CVE-2021-3156 (Baron Samedit), a heap buffer overflow that gave unprivileged users root on nearly every Unix-like system. Rewriting sudo in a memory-safe language closes off the entire class of memory-corruption bugs that produced Baron Samedit. For a setuid-root binary that every server runs, that's a meaningful upgrade.

sudo-rs 0.2.13 in 26.04 includes:

• sudoedit support
• NOEXEC support
• AppArmor profile switching
• Various bug fixes picked from the upstream main branch

Things to know:

• The original sudo is still available, renamed with a .ws suffix (the upstream project is at sudo.ws).
• The sudo-ldap package is gone. If you authenticated sudo through LDAP, you need to switch to LDAP authentication via Pluggable Authentication Modules (PAM) instead.
• sudo-rs is not yet fully feature-complete compared to original sudo. Some advanced features (complex sudoers rules, certain plugins) may not work. Test before rolling out.
• You can switch back to original sudo as the default if needed. Ubuntu Server documentation covers how.

Operational impact: most shell-based sudo invocations work exactly the same. The risk is in automation or sudoers configurations that use less common features.

OpenSSL 3.0 to 3.5: post-quantum by default

If the kernel is the headline, OpenSSL 3.5 is the co-headline. OpenSSL is in the critical path for nearly everything encrypted on Linux (web servers, libcurl, mail, Virtual Private Network (VPN), databases, Kubernetes). When OpenSSL ships new defaults, the whole operating system inherits them.

OpenSSL 3.5 includes three NIST-standardized post-quantum algorithms:

• ML-KEM (FIPS 203, formerly Kyber) for key exchange
• ML-DSA (FIPS 204, formerly Dilithium) for lattice-based signatures
• SLH-DSA (FIPS 205, SPHINCS+-based) for stateless hash-based signatures

The default TLS 1.3 key exchange is now hybrid X25519MLKEM768. Two OpenSSL 3.5 endpoints handshake with quantum-resistant key exchange automatically, with no configuration required. If ML-KEM turns out to be broken later, X25519 still protects the connection. If X25519 turns out to be broken, ML-KEM still does.

Why it matters: the practical benefit is "harvest now, decrypt later" protection. Nation-state and well-resourced adversaries are already capturing encrypted traffic today in anticipation of future quantum computers that can break current public-key cryptography. Hybrid post-quantum key exchange means captured traffic can't be decrypted later just by running it through a quantum computer. If you handle data with long-lived confidentiality requirements (financial records, medical data, intellectual property, source code, government information), you get future-proofing automatically by upgrading.

Server-side QUIC is now built into OpenSSL itself. NGINX on 26.04 can use the native OpenSSL QUIC stack instead of the quictls fork. Why it matters: every QUIC-capable server on the OS benefits without needing third-party builds.

Behavior changes worth knowing about:

• Default TLS security level raised from 1 to 2. This disables ciphers below 112 bits of security, SHA-1 in TLS signatures, RSA and DH keys under 2048 bits, and ECC curves under 224 bits. Why it matters: the bar for "acceptable cryptography" goes up automatically. Legacy embedded devices, industrial equipment, or old business-to-business integrations may fail to handshake. You can work around with CipherString = DEFAULT@SECLEVEL=1, but treat that as a short-term measure.
• Default cipher for openssl req, cms, and smime changed from 3DES to AES-256-CBC (changelog). Why it matters: 3DES is slow and has known weaknesses. AES-256 is faster and stronger. Scripts that call these subcommands without specifying an algorithm now produce AES-256 output. Data encrypted with the previous default needs -des-ede3-cbc specified explicitly during decryption.
• SHA-1 certificates rejected at security level 1 and above. Private CAs still using SHA-1 need to rotate.
• X.509 name display is now UTF-8 by default. Scripts parsing openssl x509 -text output may see formatting differences.
• HTTP client header limit of 256 to mitigate Denial of Service (DoS) attacks.

Smaller additions worth noting: Argon2 Key Derivation Function (KDF) for password hashing (memory-hard, resistant to GPU cracking), HPKE for ECH, AES-GCM-SIV for nonce-misuse-resistant authenticated encryption, deterministic ECDSA per RFC 6979, TLS certificate compression (zlib, Brotli, zstd), and continued FIPS 140-3 validation readiness work.

OpenSSH 9.6 to 10.2

SSH gets a structural change worth understanding. The OpenSSH 10.0 release notes cover the major architectural change.

sshd is now three separate binaries:

• sshd, the listener. Minimal, accepts connections.
• sshd-auth, authentication only. Separate process, separate privilege boundary.
• sshd-session, post-authentication session handling.

Why it matters: this is defense in depth applied directly to one of the most critical daemons on any server. In the original monolithic design, a bug in authentication code lived inside the always-listening root-privileged process. The regreSSHion vulnerability (CVE-2024-6387) is a recent example: a race condition in sshd's signal handling led to pre-authentication Remote Code Execution (RCE) with root privileges on millions of servers. With the split, an authentication-code bug of that kind is no longer in the listening process. Session-code vulnerabilities can't reach back into the authentication boundary. Each stage runs with progressively less privilege. This doesn't make sshd invulnerable, but it dramatically shrinks the blast radius of the bugs that have historically mattered most.

Customer-visible consequences:

• Log tagging changed. Messages now come from sshd, sshd-auth, or sshd-session. Security Information and Event Management (SIEM) rules, fail2ban filters, Open Source Security (OSSEC) decoders, and logwatch configurations need to catch all three process names. If you were grepping for sshd alone, you're missing two-thirds of authentication events.
• Process listings changed. Any monitoring that counts sshd processes needs updating.

Other notable changes:

• Post-quantum SSH key exchange by default. mlkem768x25519-sha256 is the default. Two 26.04 hosts talking SSH get hybrid post-quantum key exchange with zero configuration. Older clients fall back to classical X25519 automatically. Why it matters: same "harvest now, decrypt later" story as OpenSSL. Your SSH sessions today are now protected against future quantum attack.
• DSA is fully removed. Any ssh-dss entries in authorized_keys, known_hosts, or as host keys on legacy systems stop working. DSA has been deprecated for years; it's been weak for almost as long. If you still have DSA keys, this upgrade forces you to rotate them.
• Legacy algorithm defaults tightened. SHA-1 RSA signatures and old ciphers and MACs. Managing very old network gear, pre-RHEL 7 systems, or old iLO or iDRAC firmware may require explicit HostKeyAlgorithms, KexAlgorithms, Ciphers, or MACs overrides. Re-enabling weaker algorithms obviously weakens security, so treat it as a migration bridge rather than a permanent configuration.
• sshd no longer reads ~/.pam_environment. Why it matters: ~/.pam_environment was a known environment injection vector where an attacker who could write a single file in the user's home directory could influence the environment of SSH sessions. Removing this closes off that path.
• Stricter PerSourcePenalties by default. Abusive source IP addresses are blocked more aggressively. Retry-heavy legitimate workflows (CI SSH probes, monitoring) should be verified so they aren't rate-limited.
• New PAMServiceName directive. Explicit PAM service name instead of inferring from argv[0]. Set it if you had unusual PAM setups.
• Subsystem directives can now appear in Match blocks. Per-user and per-network SFTP configurations in one file.
• ObscureKeystrokeTiming (client-side) sends interactive SSH traffic at fixed intervals and injects fake keystroke chaff during idle periods. Why it matters: timing analysis of keystroke intervals has been used to infer typed passwords. This defense breaks that attack.
• Transport-level ping (SSH2_MSG_PING) for NAT keepalive without simulating terminal activity.

Ubuntu-specific: 26.04 uses ssh.socket for systemd socket activation. sshd only runs when connections arrive. systemctl reload ssh and systemctl restart ssh.socket have different semantics. Verify which your automation needs.

Identity services get privilege-stripped

A quiet but meaningful pattern runs through 26.04: identity-related daemons that used to run as root no longer do. These are some of the highest-value targets on any server, because compromising identity services compromises authentication for everything else.

• System Security Services Daemon (SSSD) now runs as the dedicated sssd user instead of root. Why it matters: SSSD handles directory lookups, AD integration, Kerberos ticket management, and caches authentication data. Running it as root meant any SSSD vulnerability was automatically a root compromise. Running it as a dedicated unprivileged user means an SSSD exploit gets you that user, not the whole system.
• OpenLDAP runs in AppArmor enforce mode. Why it matters: OpenLDAP has had a steady stream of CVEs over the years, and it's often exposed to the network as the enterprise directory service. An AppArmor-confined OpenLDAP process has restricted access to the filesystem, network, and system calls even if something in the binary itself gets compromised.
• Tunable PBKDF2 iteration control in OpenLDAP for password hashing. Why it matters: the right iteration count for PBKDF2 depends on your hardware and threat model, and it needs to go up over time as hardware gets faster. Being able to tune it lets you raise the cost of offline password cracking without waiting for package updates.
• authd is Ubuntu's new authentication framework for cloud identity integration. Why it matters: authd integrates Ubuntu systems with modern cloud identity providers (Microsoft Entra ID, Google Workspace, Okta) via OIDC. Multi-Factor Authentication (MFA), conditional access policies, and centralized account lifecycle management all become available on Ubuntu Desktop and Server. Previously, getting modern cloud authentication on Ubuntu meant a pile of third-party integration work. Now it's a supported framework with a command-line management tool (authctl).

Combined with the dbus-runs-as-messagebus change and the polkit-agent-helper-1 loss of setuid, there's a consistent theme in 26.04: long-privileged daemons are being stripped of the privilege they never actually needed.

Secure Boot and firmware hardening

Ubuntu 26.04 tightens the chain of trust from firmware through bootloader:

• No Execute (NX) enabled across Secure Boot variants. Why it matters: NX marks memory regions as non-executable, preventing code injection attacks where an attacker writes shellcode into a data buffer and tricks the system into executing it. Having NX enabled across all Secure Boot variants means every boot path benefits, not just some.
• Legacy strictnx variant removed in favor of consolidated hardened builds. Why it matters: fewer variants means fewer opportunities for a customer to accidentally boot a less-hardened configuration, and less surface area for the Canonical security team to maintain.
• Open Virtual Machine Firmware (OVMF) packages aligned to virtualization security technologies. The UEFI firmware for virtual machines now supports AMD SEV and Intel TDX features cleanly. Why it matters: confidential computing only works if the firmware path all the way up to the operating system is trustworthy. Aligning OVMF with the host-side confidential computing support means the full stack is in place.

Boot integrity matters because everything else depends on it. If an attacker can compromise the bootloader or firmware, every security measure above that (disk encryption, kernel lockdown, Linux Security Modules) is defeated before the operating system even starts. Hardening at this layer shrinks the viable attack paths.

NGINX 1.24 to 1.28: HTTP/3 ready for production

HTTP/3 and QUIC went from experimental in 1.25 to stable in 1.26 to production-ready by 1.28.

Why HTTP/3 matters:

• QUIC runs over UDP instead of TCP, which means no transport-layer head-of-line blocking. One slow packet doesn't stall an entire connection.
• 1-Round Trip Time (1-RTT) handshakes on first connection, 0-RTT on resumed connections. Faster than TCP plus TLS.
• Connection migration across network changes. Your mobile clients don't drop connections when switching between Wi-Fi and cellular.
• Mandatory TLS 1.3 at the transport layer. No more "TLS is optional" negotiation.

What HTTP/3 requires operationally:

• Open UDP port 443 in your firewall alongside TCP 443.
• QUIC advertised via the Alt-Svc header on HTTP/1.1 or HTTP/2 responses. Clients discover and switch to HTTP/3 after initial negotiation.
• listen 443 quic reuseport; alongside listen 443 ssl;.
• ssl_early_data on; enables 0-RTT resumption. Worth reviewing the replay-attack implications: 0-RTT data is replayable, so it should only be used for idempotent operations.

Other notable items:

• TLSv1 and TLSv1.1 disabled by default in 1.28. Apache 2.4.66 in 26.04 does the same. Why it matters: both protocols have been formally deprecated by RFC 8996 for years. TLS 1.0 has known padding oracle attacks (Browser Exploit Against SSL/TLS, or BEAST). Keeping them enabled because one legacy client needs them means exposing every client to those weaknesses. The new defaults align both major web servers with RFC 8996.
• Certificate caching directives (ssl_certificate_cache and related) provide significant performance improvement for deployments with many certificates. Why it matters: if you run multi-tenant hosting with hundreds or thousands of certificates via Server Name Indication (SNI), certificate parsing on every reload is expensive. Caching parsed certificate objects cuts reload time dramatically.
• Variable support in ssl_certificate and ssl_certificate_key allows dynamic certificate selection based on request attributes.
• More $ssl_* variables exposed. OCSP handling improvements across the window.

systemd 255 to 259

systemd across this window is mostly a story of removing long-deprecated compatibility code (v259 release notes). That sounds boring, but each removal is a real security step forward, because the removed code was the escape hatch that let services dodge modern isolation.

cgroup version 1 is gone. Unified hierarchy only from here on out. Why the removal matters: cgroup version 1 had real isolation weaknesses. Its delegation model was broken in ways that allowed container escapes. Its resource limit enforcement had race conditions. Its legacy hierarchy was a frequent target in container breakout research. Version 2's unified hierarchy is meaningfully more robust. Removing version 1 means no service or container runtime can accidentally fall back to the weaker isolation model.

Ubuntu has defaulted to cgroup version 2 since 21.10, so for most deployments this is a non-event. It matters if you have:

• Ancient container runtimes (pre-Docker 20.10, pre-containerd 1.4, pre-Kubernetes 1.25)
• Scripts reading /sys/fs/cgroup/memory/ version 1 paths
• Older versions of cAdvisor, node_exporter, or custom cgroup-parsing monitoring
• cgexec, cgclassify, cgconfigparser from libcgroup
• systemd.unified_cgroup_hierarchy=0 in your bootloader

The last one causes boot problems if not removed.

Along with the cgroup version 1 removal, 26.04 also enables stronger cgroup mount options by default: nsdelegate (safer namespace delegation), memory_recursiveprot (recursive memory protection), and memory_hugetlb_accounting (proper accounting for huge pages). Why they matter: these options tighten container resource boundaries and close off edge cases where a container could starve its siblings or escape memory limits through huge page allocation.

System V init scripts are deprecated and on their way out. Ubuntu 26.04 is the last release that supports them. systemd 260, which will ship in a future Ubuntu release, removes the compatibility layer entirely (systemd-sysv-generator, systemd-sysv-install, and rc-local.service are all gone). Why it matters: System V init scripts run as root with no sandboxing whatsoever. They predate every modern isolation primitive systemd provides. As long as the compatibility layer exists, a service vendor can ship an init.d script instead of a proper unit file and inherit root privilege with zero confinement. Removing the layer forces every service to use a unit file, which means every service can be sandboxed with ProtectSystem, PrivateTmp, NoNewPrivileges, RestrictAddressFamilies, SystemCallFilter, and the rest of the systemd hardening toolbox.

Most software moved off System V a decade ago. Third-party vendor agents and legacy in-house scripts shipping init.d files need proper systemd unit files before the next Ubuntu release.

iptables support in systemd-networkd and systemd-nspawn is also gone. Both use nftables exclusively. Why the removal matters: iptables and nftables are two separate firewall code paths in the kernel. Supporting both in systemd meant maintaining two sets of abstractions and doubling the places where a subtle bug could leave a networking policy misconfigured. Consolidating on nftables means atomic rule updates, proper namespace support, and a single, cleaner security model. Docker 29 in 26.04 also uses the nftables backend by default, continuing the consolidation.

New and actually useful:

• DNS delegate zones route queries for specific domains to specific DNS servers with search domains, via /etc/systemd/dns-delegate.d/*.dns-delegate drop-ins. Why it matters: fills a real gap. Previously you could only set global DNS or per-interface DNS. Now you can cleanly say "*.internal.company.com goes to the internal resolver, everything else goes to the public resolver" without ugly workarounds.
• PrivateUsers=managed dynamically allocates a transient range of 65,536 UIDs and GIDs per unit via systemd-nsresourced. Services run in their own user namespace with no mapping back to real host UIDs. Why it matters: meaningful sandboxing improvement for network-facing daemons. A container-escape-style attack on a service using this has nothing on the host side to pivot to, because no host UIDs are mapped into the namespace.
• PrivateUsers=full now correctly maps the full 32-bit UID range.
• ProtectHostname=private lets units change hostname inside a namespace without affecting the host. Useful for containerized workloads that want their own identity.
• RefreshOnReload causes systemctl reload to re-read credentials and ExtensionImages. Why it matters: services using systemd credentials for secrets can now rotate those secrets without a full restart. Real improvement for zero-downtime secret rotation.
• Slice concurrency limits cap concurrent tasks per slice. Why it matters: multi-tenant environments can finally prevent one tenant from spawning unbounded processes and affecting other tenants.
• Per-service directory quotas let StateDirectory, CacheDirectory, and LogsDirectory have filesystem project quotas on ext4, xfs, and btrfs. Why it matters: prevents a runaway service from filling the disk and taking down unrelated services. Long-standing operational papercut, finally fixed.

Other notable package stories

A rapid tour of the rest. Each of these has enough security relevance to mention but not enough for its own section.

apt 2.8 to 3.2

• Cryptography stack swap: GnuTLS and gcrypt replaced by OpenSSL; GnuPG replaced by Sequoia (sqv, Rust-based). Why it matters: improves the memory-safety story (Sequoia is Rust) and consolidates on OpenSSL rather than maintaining a parallel TLS stack. CVE feeds to monitor change accordingly.
• FTP, RSH, and SSH transport methods are gone. Any internal mirror using ftp:// stops working. Why the removal matters: FTP is unencrypted and long deprecated, RSH is unencrypted and even more deprecated, and the SSH transport was underused and had weird authentication semantics. Audit your sources.list before upgrading.
• trusted.gpg.d filename rules tightened. Files with @ or other non-run-parts-compliant characters silently fail signature verification. The key material is valid; apt just ignores it. Any third-party vendor keyring installed with an unusual filename needs renaming.
• Essential package removals now highlighted in color during dist-upgrade. Small thing; helps prevent accidents.
• Solver3 is default. Can produce more aggressive autoremove results than the classic solver. --solver internal is the fallback.
• apt why and apt why-not diagnostic commands. Why they matter: when the solver installs something you didn't expect or refuses to install something you want, these commands explain the decision. Cuts dependency troubleshooting time dramatically.
• Transaction history and rollback (apt history-undo, apt history-rollback) in 3.2. Why they matter: real incident response capability. If a package update breaks production, you can actually roll it back cleanly instead of hunting through dpkg logs.

AppArmor 4.0 to 5.0

• userns rules restrict unprivileged user namespace creation per-profile. Why it matters: unprivileged user namespaces have been a persistent source of kernel exploit chains. Being able to say "this profile cannot create user namespaces" closes off that path for services that don't need it.
• io_uring rules mediate io_uring operations. Why it matters: io_uring is a relatively new kernel subsystem and has been a steady source of CVEs. AppArmor mediating it means your existing AppArmor policies can finally restrict what services do through io_uring.
• mqueue rules for POSIX and System V IPC message queue mediation.
• Expanded unix rules for AF_UNIX socket mediation including abstract namespace.

auditd 3.1 to 4.1

• Service split: audit-rules.service loads rules, auditd.service logs events. Why it matters: runbooks that only check auditd.service are now incomplete. Both services need to be running for correct audit posture. Monitoring and compliance automation needs updating.
• auvirt, autrace, and Python 2 bindings are gone. Legacy tooling needs updating.
• /run/audit/ is the new runtime directory.
• New audisp-filter for pre-SIEM event filtering. Why it matters: if you pay per gigabyte for log ingestion, pre-filtering on the host side can reduce costs meaningfully.
• New max_log_file_action = exec to run a script on log rotation. Useful for custom archival, and a new audit target (what's being executed).

D-Bus 1.14 to 1.16

• dbus-daemon starts as the target user, not as root-dropping-privileges. Why it matters: the system dbus-daemon never runs as root on 26.04. Any exploit path through the drop-privilege code is gone because there is no drop-privilege code. ps shows it as messagebus from start to finish.

fwupd 1.9 to 2.1

• GNU Privacy Guard (GPG) support removed. PKCS#7 with X.509 only. Linux Vendor Firmware Service (LVFS) users are unaffected; internal firmware repositories signed with GPG need to migrate before upgrading.
• New Host Security ID (HSI) checks for HP Sure Start, Intel Converged Security and Manageability Engine (CSME) via SMBIOS, UEFI memory protection attributes, AMD Platform Secure Boot, and Arrow Lake and Meteor Lake CSME.
• TPM eventlog explanation via a new tpm-eventlog subcommand. Why it matters: attestation troubleshooting used to require parsing raw TPM event logs by hand. This subcommand explains what's in the log in human-readable form.
• Streaming firmware over file descriptors instead of loading into memory. Eliminates a class of memory-handling bugs.
• Dropped json-glib, libarchive, and protobuf-c dependencies. Why it matters: reduced transitive CVE surface. Fewer dependencies means fewer vulnerabilities you inherit.

GNU Privacy Guard 2.4.4 to 2.4.8

Mostly maintenance. One thing worth knowing: the signature verification bypass via form-feed character (\f) affects versions through 2.4.8. An attacker can place additional text after signed material, and verification still succeeds (with an "invalid armor" warning). Why it matters: if you have CI/CD automation verifying GPG signatures, "invalid armor" as a warning isn't enough. Treat it as a hard failure, or migrate verification to Sequoia (sqv), which isn't affected.

shadow (login) 4.13 to 4.18

• Subordinate UID and GID defaults hardened. SUB_UID_COUNT and SUB_GID_COUNT defaults raised to 65,536 with proper ceiling and floor. Why it matters: previous defaults could, in edge cases, allow one user's subordinate IDs to collide with another's. That's a real privilege-boundary issue for rootless containers. Anyone running rootless Podman, rootless Docker, or LXC or LXD unprivileged containers gets safer defaults.
• Password expiration and aging officially deprecated. Still works, but removal is on the roadmap. Why the deprecation matters: modern NIST and industry guidance has moved away from mandatory periodic rotation because it tends to produce weaker passwords (users pick patterns they can remember), not stronger ones. Password lifecycle belongs in your identity system, not in /etc/shadow.
• useradd --system no longer adds supplementary groups from /etc/default/useradd. System users get only what you specify.
• More audit events for group operations (groupadd, groupmod, groupdel, gpasswd).

Chrony replaces systemd-timesyncd, with Network Time Security by default

Ubuntu 26.04 switches the default time daemon from systemd-timesyncd to Chrony 4.8, with Network Time Security (NTS) enabled by default against Ubuntu's NTS servers.

Why it matters: classical NTP is unauthenticated. An attacker on the network path can inject bogus time responses, which matters more than it sounds. Certificate expiration is time-based, so an attacker who can set your clock back can convince you a revoked or expired certificate is still valid. Kerberos ticket validity is time-based. Log timestamps are time-based for incident analysis. Time-based One-Time Password (TOTP) for two-factor authentication is, naturally, time-based. NTS adds TLS-based authentication to time synchronization, so the response actually came from the server you think it came from.

Two things to know:

• NTS Key Exchange uses a separate port (4460/TCP) to negotiate security parameters, which are then used via the normal NTP port (123/UDP). If your network is tightly firewalled, both need to be reachable.
• A new CA is installed in /etc/chrony/nts-bootstrap-ubuntu.crt specifically for the Ubuntu NTS bootstrap server. Needed for when the clock is too far off to validate normal certificates.

If your network doesn't allow access to Ubuntu's NTS servers or the required ports, edit /etc/chrony/sources.d/ubuntu-ntp-pools.sources to fall back to traditional NTP.

Samba 4.19 to 4.22

• Group Managed Service Accounts (gMSA). Samba AD DC can now host and manage gMSAs. Linux services can fetch rotating gMSA passwords just like Windows services. Why it matters: static service account passwords that nobody wants to rotate are one of the most common paths into Active Directory. gMSAs automate the rotation so services use a fresh password fetched from AD, eliminating the "nobody's touched that password since 2018" problem.
• Authentication Silos and Authentication Policies. The Microsoft AD feature for tiered admin isolation. Samba now honors and creates them. Requires ad dc functional level = 2016. Why it matters: lets you enforce that Tier 0 accounts (domain admins) can only authenticate against domain controllers, not against general workstations. Dramatically reduces credential theft exposure from compromised workstations.
• utmp-based user enumeration removed. NetWkstaEnumUsers and NetWkstaGetInfo level 102 previously leaked logged-in user lists to any SMB-connected client. Now they return empty. Quiet, meaningful privacy fix.

polkit 124 to 126

• pklocalauthority (.pkla files) fully removed. All rules must now be JavaScript (.rules). Why the removal matters: having two rule systems meant authorization logic could live in two different formats, and customers frequently forgot about rules in one system while updating the other. Consolidating on one format makes polkit easier to audit. Any .pkla files under /etc/polkit-1/localauthority/ or /var/lib/polkit-1/localauthority/ stop applying on upgrade. Configuration management tooling that drops .pkla files needs updating.
• polkit-agent-helper-1 is no longer setuid under systemd. Socket-activated service instead. Why it matters: setuid binaries are a persistent target class for privilege-escalation bugs. Removing setuid from a commonly-invoked helper is meaningful attack-surface reduction.
• Stronger filesystem permissions on rule directories. The polkitd daemon can read rules but can't modify them.
• More aggressive systemd sandboxing on polkit.service: ProtectSystem, ProtectHome, PrivateTmp, NoNewPrivileges.

mdadm 4.2 to 4.4

• Self-Encrypting Drive (SED) support for Intel Matrix Storage Manager (IMSM) metadata. Intel Virtual RAID on CPU (VROC) with self-encrypting drives is a supported path now.
• New --write-zeros option for wiping replacement disks. Useful for security-sensitive workflows requiring deterministic overwrite.

GNU Compiler Collection 13 to 15

Not a runtime package, but if you build anything in-house, this matters.

• -fhardened (GCC 14) is a single umbrella flag that turns on a consensus-reasonable hardening set: _FORTIFY_SOURCE=3, _GLIBCXX_ASSERTIONS, trivial auto variable initialization, Position Independent Executable (PIE), Relocation Read-Only (RELRO) with immediate symbol binding, stack protector strong, stack-clash protection, and Intel Control-flow Enforcement Technology (CET). Why it matters: getting a hardened build used to mean juggling eight to ten individual flags and hoping you didn't miss one. A single flag that turns on the consensus set, all ABI safe with no severe performance cost, makes hardening the path of least resistance.
• -fstrict-flex-arrays=3 closes the "unbounded trailing array in struct" bug class that has shipped as CVEs in the kernel, OpenSSH, and others. Why it matters: C code historically used array[0] and array[1] as flexible array idioms that the compiler couldn't bounds-check. This flag makes GCC treat only true flexible array members ([]) as flex arrays and enforce bounds on the rest. The OpenSSF Compiler Hardening Guide now recommends this in its baseline.
• _FORTIFY_SOURCE=3 runtime object-size checks on more functions than level 2.

Small but noticeable

• curl 8.5 to 8.18: HTTP/3 matured substantially, WebSocket support is first-class, and QUIC implementation improved.
• Apache httpd 2.4.58 to 2.4.66: RewriteRule backreferences at the start of a substitution now require explicit UnsafePrefixStat. Opportunistic TLS upgrade (SSLEngine optional) was removed in 2.4.64. Test your rewrite configurations before rollout.
• wget 1.21 to 1.25: Shorthand Uniform Resource Locators (URLs) (example.com/path without a scheme) are rejected. wget used to silently prepend http://. Why the change matters: automatically prepending http:// to an ambiguous URL opened wget up to argument-injection attacks (CVE-2024-10524). Forcing an explicit scheme closes that off. Any automation relying on the old behavior needs updating.

Time to upgrade?

Short answer: yes.

Longer answer: 26.04 is a genuinely substantial security release. The kernel alone justifies the upgrade. Attack Vector Controls, BPF tokens, host support for both SEV-SNP and TDX confidential computing, kernel stack erasing by default, and two years of accumulated mitigation and memory-safety work add up to a materially better security posture than 24.04 can reach even with backports. Post-quantum cryptography is now the default across kernel module signing, OpenSSL TLS, and OpenSSH key exchange, which means you get "harvest now, decrypt later" protection simply by upgrading.

On top of the kernel story, 26.04 makes a set of structural changes that individually seem small but add up. sudo-rs in a memory-safe language. TPM-backed Full Disk Encryption out of experimental. SSSD and OpenLDAP stripped of root privilege. Secure Boot variants consolidated and hardened. Chrony with Network Time Security replacing unauthenticated NTP. systemd removing the last escape hatches that let services dodge modern isolation.

The tradeoffs are the usual LTS tradeoffs. The Rust coreutils and sudo-rs transitions have been shipping since Ubuntu 25.04 and work for the vast majority of scripts, but edge cases in locale handling, exit codes, or uncommon sudoers features are worth testing before rollout. The systemd cgroup version 1 removal and SysV init deprecation find the last straggler vendor agent in your environment. OpenSSL's security level 2 default catches the legacy industrial device nobody wanted to touch. SHA-1 in your internal CA finally has to go. These are all good outcomes; you just want to discover them in staging, not in production.

If you're still on 22.04, plan your upgrade path now. If you're on 24.04, the security delta is real and worth acting on. If you're already on 26.04, you're ahead of most of us.