BTR (CVE-2026-64507, CVE-2026-64508) Spectre v2 kernel memory leak: status for CloudLinux

Branch Target Reuse (BTR, CVE-2026-64507 and CVE-2026-64508) is a Spectre v2 variant in the Linux kernel’s BPF just-in-time compiler, the part of the kernel that turns small user-supplied filter programs into machine code. It lets an ordinary local user read kernel memory. The researchers’ exploit recovers the root password hash from a running su process in a few minutes. On its own, BTR does not let an attacker gain root, because the hash still has to be cracked offline first. VUSec (VU Amsterdam) and Scuola Superiore Sant’Anna published the attack and a proof-of-concept on September 29, 2026.

On CloudLinux, BTR affects CloudLinux 8 LTS, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04, and whether an attack can succeed also depends on the server’s processor. CloudLinux 7 isn’t affected, and the published attack doesn’t work on CloudLinux 7h and 8. There is no mitigation to apply, and the fix arrives with the kernel updates listed below.

Here “local” means any process on the machine, including the PHP worker behind a compromised WordPress plugin, because the filter programs BTR uses are ones any user may load. What that process can then read is the kernel’s memory, which every account on the server shares.

Affected CloudLinux versions

Every CloudLinux version except CloudLinux 7 compiles BPF filter programs, so an ordinary user can reach the code path BTR attacks. We checked this on each version. On CloudLinux 7h and 8, though, our analysis of the kernel code shows the published attack can’t work. On the remaining versions, whether it succeeds depends on the processor; see Which processors are at risk.

^† CloudLinux for Ubuntu 22.04 takes its kernel from Ubuntu (Canonical) via apt, not from a CloudLinux stream. As of October 5, 2026, Canonical lists its 22.04 kernel as needing a fix and has a fix for its 6.8 hardware enablement (HWE) kernel in preparation. We’ll note here when Canonical releases it.

^†† On CloudLinux 7 the kernel interprets filter programs by default, so there is no compiled code for the attack to reuse.

^‡ Red Hat lists the RHEL 8 kernel, the base of the CloudLinux 7h and 8 kernels, as not affected by either CVE. Our analysis of their code also shows the attack the researchers published can’t work on them.

Which processors are at risk

BTR depends on the processor as well as on the kernel, and the researchers’ results differ by processor family.

• Intel: the published exploit works end to end on two microarchitectures, Raptor Cove and Lion Cove. A timing attack like this one has to be tuned to each processor, so on other Intel processors the exploit would have to be adapted first.
• AMD and Arm: the researchers confirmed the underlying behavior on both but published no working exploit for either.

We can’t offer a reliable way to tell from a server’s configuration whether it can be attacked. Until its fixed kernel is installed, treat every affected version as exposed, whatever its processor.

Is there a mitigation?

No, the fix is the kernel update in the streams below.

Two settings are the usual answer to BPF bugs, and neither helps here:

• JIT hardening (net.core.bpf_jit_harden) scrambles the constants in compiled programs. This attack hides its payload in jump distances instead, so hardening changes nothing.
• Blocking unprivileged BPF (kernel.unprivileged_bpf_disabled) stops ordinary users from calling bpf(). The attack loads classic BPF filters through seccomp or a socket filter, which that setting doesn’t govern.

Interpreting filter programs instead of compiling them would remove the attack surface, but it isn’t available. On every version except CloudLinux 7, the kernel is built with compilation always on and refuses the change.

Update instructions

The fix reaches CloudLinux servers through the four streams below as Red Hat and AlmaLinux pick it up, and CloudLinux for Ubuntu 22.04 gets it from Canonical. We’ll update each stream here when its state changes.

Stream 1: CloudLinux 7h and 8 kernel

Stream 2: AlmaLinux kernel (CloudLinux 9 and 10)

Stream 3: TuxCare ELS LTS kernel (CloudLinux 8 LTS and 9 LTS)

Stream 4: KernelCare livepatch

How to verify you are patched

When a fixed kernel is out for your version, compare uname -r with the version its stream lists. For KernelCare, check both CVEs:

kcarectl --patch-info | grep -E 'CVE-2026-6450[78]'

A patched server prints a line for each CVE. Use --patch-info for this: kcarectl --info shows only the patch level and doesn’t list CVEs, so it makes a patched server look unpatched.

Why this matters on a shared host

The attack starts from an ordinary hosting account, the position a shared host gives every customer and a compromised site gives an attacker. It needs no special rights. It loads classic BPF filters through seccomp or a socket, and on the affected versions the kernel compiles them.

From there it reads kernel memory at about 8 bytes a second. That is too slow to copy out a server’s memory in bulk. So the researchers’ demonstration goes after one target, the root password hash, which it reads out of a running su process in 3 to 5 minutes. The attacker still has to crack that hash offline before it is worth anything.

Technical details of the bug

Classic BPF filters are small programs that seccomp uses to restrict a process’s system calls and that sockets use to filter packets. The kernel’s just-in-time compiler turns them into machine code and packs many programs into shared executable memory. When a program is freed and another loads, the kernel reuses the space.

When that memory is rewritten, the processor keeps the code itself consistent but holds on to its indirect-branch predictions for the address. So when the kernel jumps into a new program placed where an old one used to be, the processor can speculatively follow a jump the old program trained.

The attacker trains a prediction with one program, frees it, and gets the kernel to place another program in the same slot. The speculation then runs code hidden in the attacker’s own compiled program. What that code touches leaves a trace in the processor cache, which the attacker reads back by timing memory accesses. The researchers call it a speculative execute-after-free.

The upstream fix came in two parts, which is why there are two CVEs. CVE-2026-64508 adds a hook to the BPF core that flushes the branch predictors before JIT memory is reused; on its own it does nothing.

CVE-2026-64507 enables that hook on x86. The kernel then issues an indirect branch predictor barrier (IBPB) on all cores when a filter program reuses previously executed JIT memory. Only x86 gets the flush. The published fixes name no equivalent for Arm.

References

• VUSec project page: Branch Target Reuse
• Paper: Branch Target Reuse, Spectre-v2 Attacks in JIT Engines (ACM CCS 2026)
• Proof-of-concept on GitHub
• oss-security announcement
• CVE records, with the upstream fix commits: CVE-2026-64507, CVE-2026-64508
• Red Hat: CVE-2026-64507, CVE-2026-64508
• Ubuntu: CVE-2026-64507, CVE-2026-64508
• NVD: CVE-2026-64507, CVE-2026-64508
• CloudLinux status page incident for this advisory