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

📋 TL;DR — last updated November 3, 2026, 12:00 UTC

BTR (CVE-2026-64507, CVE-2026-64508, Moderate per Red Hat) is a Spectre v2 variant that lets a local unprivileged user read kernel memory. It does not give root by itself. A public proof-of-concept exists for two Intel processor microarchitectures, and no exploitation in the wild has been reported.

• Affected: CloudLinux 8 LTS, 9, 9 LTS and 10, and CloudLinux for Ubuntu 22.04 on its optional 6.8 HWE kernel. CloudLinux 7 and the standard Ubuntu 22.04 kernel aren’t affected, and the published attack doesn’t work on CloudLinux 7h and 8. → Affected CloudLinux versions
• — Processors: whether an attack can succeed also depends on the processor. The published exploit works on two Intel microarchitectures only. → Which processors are at risk
• Mitigation: none. → Is there a mitigation?
• Fix status: fixed upstream on July 25, 2026. Fixed kernels are out for CloudLinux 9 and 10; for the other affected versions they aren’t released yet. → Update instructions
• — CloudLinux 7h and 8 kernel: no update needed.
• — AlmaLinux kernel (CloudLinux 9, 10): fixed in kernel 5.14.0-687.57.1.el9_8 for CloudLinux 9 and 6.12.0-211.65.1.el10_2 for CloudLinux 10.
• — LTS kernels (CloudLinux 8 LTS, 9 LTS): fixed kernel not released yet.
• — KernelCare livepatch: follows the vendor fixes.
• — CloudLinux for Ubuntu 22.04: Canonical lists the standard 5.15 kernel as not affected. The fix for its 6.8 HWE kernel isn’t released yet.
• Why it matters: on a shared host, a compromised site is enough to run the attack. → Why this matters on a shared host
• How the bug works: the processor keeps old branch predictions when the kernel reuses memory for a new filter program. → Technical details of the bug

This advisory is also tracked on the CloudLinux status page; subscribe there for status updates.

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 on its optional 6.8 HWE kernel, and whether an attack can succeed also depends on the server’s processor. CloudLinux 7 and the standard Ubuntu 22.04 kernel aren’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, and Canonical lists the standard Ubuntu 22.04 kernel as not affected. 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 19, 2026, Canonical lists its standard 22.04 kernel (5.15) as not affected by either CVE. The fix for its 6.8 hardware enablement (HWE) kernel is still in preparation, and 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

Update: October 8, 2026.

Red Hat now lists the RHEL 8 kernel as not affected by either CVE. That matches our analysis of the CloudLinux 7h and 8 kernels: no update is needed for these versions, and no fix is expected for them.

Update: October 7, 2026.

The published attack doesn’t work on the CloudLinux 7h and 8 kernels, according to our analysis of their code, so no update is needed for these versions. Red Hat lists RHEL 8 as affected by CVE-2026-64507 and not affected by CVE-2026-64508. If Red Hat releases a fix for RHEL 8, CloudLinux 7h and 8 will pick it up once AlmaLinux 8 has it, and we’ll note it here.

Status: October 5, 2026.

No fixed kernel yet. CloudLinux builds the CloudLinux 7h and CloudLinux 8 kernels and will ship the fix in them once AlmaLinux 8 has it. We’ll add the kernel version here.

Stream 2: AlmaLinux kernel (CloudLinux 9 and 10)

Update: November 3, 2026.

CloudLinux 9 has a fixed kernel. AlmaLinux 9 kernel 5.14.0-687.57.1.el9_8 and newer fix both CVEs and are in the production repositories. To install the update, run dnf update 'kernel*' and reboot.

Update: October 14, 2026.

CloudLinux 10 has a fixed kernel. AlmaLinux 10 kernel 6.12.0-211.65.1.el10_2 (ALSA-2026:81406) fixes both CVEs and is in the production repositories. To install it, run dnf update 'kernel*' and reboot. CloudLinux 9 has no fixed kernel yet. Red Hat released its RHEL 9 fix on October 13, and we’ll add the AlmaLinux 9 kernel version here when it’s out.

Status: October 5, 2026.

No fixed kernel yet. CloudLinux 9 and CloudLinux 10 run the AlmaLinux kernel, which follows Red Hat. Red Hat lists its RHEL 9 and 10 kernels as affected by both CVEs and has published no fix yet. We’ll add the AlmaLinux kernel version here when it’s released.

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

Status: October 5, 2026.

No fixed kernel yet. The LTS kernels follow Red Hat’s release. We’ll add the kernel-lts version here.

Stream 4: KernelCare livepatch

Status: October 5, 2026.

KernelCare follows the vendor fixes for this issue and is not livepatching ahead of them. Once a version’s vendor kernel carries the fix, KernelCare delivers it to running servers without a reboot. We’ll add each release here.

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