Security researcher Lee Jia Jie of STAR Labs disclosed CVE-2026-53264, rated 7.8 on the CVSS scale, a use-after-free race condition in the Linux kernel’s network traffic-control subsystem. The root cause is a lock mismatch in a function called tcf_idr_check_alloc, which looks up shared traffic-control actions by index. The kernel performs those lookups under one lock while the objects themselves can be freed under a different one, without waiting for the grace period that is supposed to guarantee nothing else still holds a reference. That gap lets an attacker reclaim a freed object before its reference count is checked, opening the door to controlled memory corruption. What made the disclosure notable was not the bug itself but Lee’s account of how he built the exploit: AI tooling helped him find the flaw, generate a working proof-of-concept, and tune the race-condition timing needed to win the exploitation window reliably.
Local access only, but the exploitation chain is real
This is a local privilege escalation, not a remote code execution flaw, so it requires an attacker to already have a foothold on the machine, typically an unprivileged user account or a compromised container. The demonstrated exploit needs unprivileged user namespaces to be enabled along with the CONFIG_NET_ACT_GACT and CONFIG_NET_CLS_FLOWER kernel options, and it uses a kernel-specific return-oriented programming chain with hardcoded offsets to overwrite the kernel’s core_pattern setting, redirecting crash-dump handling to an attacker-controlled program. That is a meaningful list of prerequisites, which is exactly why this class of bug tends to get deprioritised behind remote-facing flaws. The fix landed upstream on June 1 and has since been backported to stable kernel branches; there is no CISA KEV entry and no confirmed exploitation in the wild as of this week.
The prerequisite list is shrinking, not the risk
What should concern any team running self-hosted Linux, containers, or Kubernetes nodes is not this specific combination of kernel options, it is how quickly AI-assisted tooling turned a subtle locking bug into a reliable exploit chain. The gap between “a CVE exists” and “a working exploit is public” has historically been where patch management teams bought themselves breathing room. That gap is compressing, and it compresses for defenders too, if you use the same class of tooling to find these issues in your own stack before an attacker does. For organisations under NIS2 or DORA that are required to demonstrate a documented vulnerability management process, this is a good moment to check whether your kernel patch SLA still matches the actual speed of the threat, and whether unprivileged user namespaces are enabled anywhere they do not need to be.
If you want an infrastructure hardening review that checks your kernel configuration, patch cadence, and container isolation against exactly this kind of local escalation path, contact Excello Digital. We help European engineering teams keep their vulnerability management process ahead of tooling that is only getting faster.