PinTheft went public on May 19, 2026, and Canonical already has it documented and patched. The bug carries the identifier CVE-2026-43494. It sounds nasty, but the details matter before anyone panics: on most Ubuntu installs the default configuration keeps you out of harm’s way.
What it actually does
The flaw is a reference count bug that lets an attacker poison the page cache with malicious contents. In practice, a local attacker can replace the in-memory contents of arbitrary files. The important nuance is that it only touches what’s loaded in memory; the actual contents on disk stay intact. Canonical compares it to two old acquaintances, Copy Fail (CVE-2026-31431) and the well-known Dirty COW (CVE-2016-5195), which followed a similar pattern of manipulating the cache to escalate privileges.
The mainline kernel fix landed with commit e174929793195e0cd6a4adb0cad731b39f9019b4.
Severity, and why the priority is Medium
This part deserves an explanation. PinTheft has a CVSS 3.1 score of 7.8, which technically puts it in the high band. Yet Ubuntu assigns it a Medium priority. That isn’t a contradiction or an arbitrary downgrade: the local privilege escalation risk is balanced against the safe configuration Ubuntu ships out of the box.
The key is the RDS protocol (Reliable Datagram Sockets). The hole can only be exploited on systems that use that protocol, which is uncommon. And Ubuntu, by default, disables its automatic loading through the file /etc/modprobe.d/blacklist-rare-network.conf. If you’ve never touched that, the RDS module won’t load on its own, and without it the vulnerability has no way in.
Who is affected
The version breakdown is as follows:
- Ubuntu 16.04 LTS and earlier: not affected.
- Ubuntu 18.04 LTS: affected only in the HWE kernel (5.4).
- Ubuntu 20.04 LTS and later: affected in the standard kernels.
So if you run a modern release with the standard kernel, the vulnerable code is present, even though the default RDS hardening keeps protecting you as long as you don’t enable that protocol.
What to do
Canonical’s recommendation is plain: update the kernel and reboot. First check which kernel you’re running:
uname -rThen apply the security updates and reboot so the new kernel takes over:
sudo apt update && sudo apt upgrade
sudo rebootThe reboot is required: patching the kernel without booting into the new one does nothing unless you use Livepatch. If you manage servers where a reboot is expensive, this is exactly the kind of case where live kernel patching earns its keep, though for PinTheft on a regular desktop with the default config you can take your time.
The underlying advice is the usual one: keep your kernel current and don’t casually disable the protections Ubuntu ships with, because sometimes they’re exactly what stands between you and a 7.8 CVE.
Source
Based on the analysis published by Canonical on the official Ubuntu blog: PinTheft Linux kernel vulnerability mitigation (Canonical, author seth-arnold).