A bug that has sat in the Linux kernel since December 2007 can hand an ordinary local user root, and in lab testing let code running inside a container take over the host machine underneath it. The researchers who found it say an in-house AI system helped them build the exploit, and that claim is worth reading carefully, because it is narrower than it first sounds.
Fourie Zhang of the TencentOS Security Team posted the disclosure, tracked as CVE-2026-64564 and nicknamed SCTPhantom, to the oss-security mailing list on 6 August. The accompanying technical write-up is published under the lab's own name, Tencent Zhuque Lab, with no individual byline. Zhang's summary of the impact is two lines: "Local low-privileged user -> root on affected systems. Container -> host root."
What's affected
The flaw sits in SCTP, a transport protocol that sits alongside TCP and UDP but sees far less use, in the code handling Dynamic Address Reconfiguration. Put simply, the kernel caches a pointer to a network path while processing a request to remove addresses, then validates the removal against a different address than the one it later acts on. A crafted sequence frees the path while the association is still pointing at it. The Linux CVE record describes the same defect independently, saying it leaves the association "with a transport_count of 0 and primary_path/active_path pointing at freed memory".
The bug dates to a December 2007 commit that shipped in Linux 2.6.25. Fixed versions are 6.6.148, 6.12.101, 6.18.42, 7.1.6 and 7.2-rc5. This was coordinated disclosure: private reporting began on 12 July, the fix reached the Linux networking tree on 24 July, and the CVE was assigned on 4 August, all before the public write-up.
What the researchers achieved
Nothing here has been seen in the wild. There is no threat actor, campaign or victim attached to this flaw, and no proof-of-concept code has been released. What exists is the team's own validation table, and it is worth stating plainly that these are lab results rather than observed attacks. They reached root on five targets: a 7.2-rc2 research kernel, an OpenCloudOS-family 6.6.119 build, Debian 13, Ubuntu 24.04, and a Rocky Linux 9 and RHEL 9 vendor kernel, the last qualified as needing the SCTP module loaded. The mailing-list post lists a shorter set than the blog table does.
The container escape is the more striking result and the more carefully caveated one. "Six of eight attempts reached host root," the write-up says, adding that "the two failures stopped as clean pointer-walk misses without a kernel panic". Crucially, the team found a route that needs neither CAP_NET_ADMIN nor any change to the addip sysctls, enabling the features per socket instead, and says the test container kept the default seccomp profile with no elevated capabilities. That is what makes the escape claim meaningful rather than a lab curiosity.
The AI claim, precisely
Tencent's acknowledgement is one sentence: "Corvus AI assisted with source analysis, reproduction, exploit development, and cross-platform validation." The verb is assisted. The write-up describes using the system to convert research areas into bounded source-analysis, packet-generation, crash-triage and reproduction tasks, and later to evaluate the flaw's impact inside containers. It does not claim the chain was written autonomously, and the exploit sections are narrated in the first person plural throughout. This is a vendor describing its own tooling on its own blog, so treat the framing as Tencent's characterisation. It is a materially weaker claim than an agent choosing and attacking its own targets, and closer to a fast, well-instrumented assistant.
How much to trust it
The memory-safety defect is confirmed by the Linux CVE record. The exploitation claims are not: no third party has reproduced the local root or the container escape, the Linux CVE entry carries no credits and no severity metrics, and NVD has published no score. The CVSS v4.0 rating of 8.5 is Tencent's own assessment, and its vector marks all subsequent-system impacts as none, which sits awkwardly next to a claimed container-to-host escape. The one independent advisory to appear so far, an urgent bulletin from the openKylin community, characterises the impact as a kernel panic and does not mention root or escape at all. This is also local only, not remotely triggerable.
What you should do
Move to one of the fixed releases. Do not judge exposure from a version string: the write-up warns that vendor kernels may backport the fix while keeping an older base version. Note also that the write-up carries no mitigation section, something a respondent on the mailing list raised the same day, asking whether unloading or blacklisting the SCTP module would help. No answer had been posted at the time of writing, so treat module blacklisting as untested rather than a recommended workaround. Exposure also depends on whether SCTP is available at all, and on packet socket access, seccomp, capabilities and LSM policy in your environment.
The disclosure is on the oss-security mailing list, with the full technical analysis on Tencent Zhuque Lab's site. IntelFusions has previously covered a Linux kernel bug that let any local user become root and storage flaws that broke tenant isolation in Kubernetes.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.