{"uuid": "9f7446d7-16d2-4dc6-8f55-298026047964", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-53359", "type": "seen", "source": "https://t.me/aenix_io/427", "content": "\ud83d\udc7bThird 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\ud83d\udc47\n\nSecurity Advisory: CVE-2026-43499 (\"GhostLock\") \u2014 Cozystack Exposure Assessment\nOn July 7, 2026, a critical Linux kernel local privilege escalation \u2014 CVE-2026-43499 (\"GhostLock\") \u2014 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 \u2014 an unprivileged local process reaching root on the host kernel.\n\nThe 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.\n\nReference: https://nvd.nist.gov/vuln/detail/CVE-2026-43499\n\nConfirmed not affected\nGhostLock 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.\n\nManaged 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 \u2014 a futex sequence issued inside a guest reaches the guest kernel, not the host.\n\nManaged 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.\n\nNo arbitrary tenant code on the management cluster. Cozystack exposes only the managed services we provide \u2014 there is no surface on which a tenant runs arbitrary native code in a container on a management node.\nBy 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.\n\nRecommended action \u2014 same as Januscape: upgrade the kernel\nThe vulnerability is confirmed in current Talos Linux releases, and any future regression in the isolation above could re-expose it \u2014 so we recommend applying the kernel fix regardless.\n\nGhostLock 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 \u2014 one move to v1.13.6 closes all three.\n\nAlready upgraded to v1.13.6 for Januscape? You are protected \u2014 no further action needed.\nNot 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.\nIf you cannot upgrade immediately, kernel.randomize_kstack_offset=1 (via machine.sysctls) reduces the exploit's reliability as a defense-in-depth measure \u2014 not a substitute for the fix.\n\nWe will update this advisory as fixed releases and further mitigations are confirmed.", "creation_timestamp": "2026-07-29T12:00:04.361628Z"}