CVE-2026-43499 (GhostLock): Cozystack Exposure Assessment

Security Advisory: CVE-2026-43499 (GhostLock) — Cozystack Exposure Assessment

Third CVE this week — but good news: Cozystack isn’t exposed by design, and the fix is the same v1.13.6 upgrade you already know. Details below.

TL;DR: CVE-2026-43499 (“GhostLock”) is a Linux kernel local privilege escalation. By the design of Cozystack, we currently see no viable attack path for a tenant to reach the affected host kernel surface. We still recommend the fix — and it is the same Talos v1.13.6 upgrade that closes Januscape (CVE-2026-53359) and CVE-2026-46113. One move to v1.13.6 closes all three.

Vulnerability overview

On July 7, 2026, a critical Linux kernel local privilege escalation — CVE-2026-43499 (“GhostLock”) — was disclosed with a working proof-of-concept.

It is a stack use-after-free in the kernel real-time mutex (rtmutex) priority-inheritance path, reachable from futex(2): on the proxy-lock rollback taken from futex_requeue(), remove_waiter() clears pi_blocked_on on the wrong task, leaving a dangling pointer to a freed kernel stack frame. Introduced in Linux 2.6.39 (2011), it affects every kernel up to v7.1-rc1, needs only CONFIG_FUTEX_PI=y (no capabilities, no user namespaces), and can be escalated into a container escape — an unprivileged local process reaching root on the host kernel.

The upstream fix is commit 3bfdc63936dd, shipped in stable kernels 6.1.175, 6.6.140, 6.12.86, 6.18.27, and 7.0.4.

Confirmed not affected

GhostLock is a local escalation: it presupposes the attacker can already run native code on the host kernel’s syscall surface. By design, Cozystack gives tenants no way to do that.

  • Managed Kubernetes and VirtualMachine services. All tenant workloads execute inside guest virtual machines running on top of unprivileged containers. Tenant code has no direct access to the host kernel syscall surface — a futex sequence issued inside a guest reaches the guest kernel, not the host.
  • Managed databases run as non-root, non-superuser users, with no Kubernetes API access and no ability to execute arbitrary code in the server process, so a tenant cannot issue the syscall sequence the exploit requires.
  • No arbitrary tenant code on the management cluster. Cozystack exposes only the managed services we provide — there is no surface on which a tenant runs arbitrary native code in a container on a management node.

By the design of Cozystack, we currently do not see any viable attack path that would allow a tenant to reach the host kernel surface affected by this vulnerability.

Recommended action — same as Januscape: upgrade the kernel

The vulnerability is confirmed in current Talos Linux releases, and any future regression in the isolation above could re-expose it — so we recommend applying the kernel fix regardless.

GhostLock is fixed in Talos Linux v1.13.6 (kernel 6.18.38-talos, newer than the first fixed 6.18.27). This is the same upgrade we recommended for CVE-2026-53359 (“Januscape”) and CVE-2026-46113 — one move to v1.13.6 closes all three.

  • Already upgraded to v1.13.6 for Januscape? You are protected — no further action needed.
  • Not yet? Follow the same runbook: build an Image Factory installer with your extensions, upgrade node by node to v1.13.6, and verify talosctl read /proc/sys/kernel/osrelease shows 6.18.38-talos. Move one node at a time, waiting for etcd quorum and storage health between control-plane nodes.

The full step-by-step upgrade is in our Januscape fix runbook.

If you cannot upgrade immediately, kernel.randomize_kstack_offset=1 (via machine.sysctls) reduces the exploit’s reliability as a defense-in-depth measure — not a substitute for the fix.

We will update this advisory as fixed releases and further mitigations are confirmed.

References

Join the community