Musk's AI Secret and the Linux Flaw Shaking Servers

Here is the most uncomfortable thing Elon Musk has said in a courtroom recently: that xAI, the AI lab he built specifically to compete with OpenAI, may have used OpenAI's own technology to do it.

During cross-examination in his ongoing federal lawsuit against OpenAI, Musk was asked by OpenAI attorney William Savitt whether OpenAI's technology had been used in any way to develop xAI. Musk's answer was not a denial. He said it is "standard practice to use other AIs to validate your AI" — and that "generally all the AI companies" do it. That is a remarkable thing to say when you are the plaintiff suing the company you just admitted you may have leaned on.

The technique at the center of this is called distillation. The short version: you take a powerful, expensive AI model and use its outputs to train a smaller, cheaper one to behave similarly. It is legal in many contexts, but it sits in a very gray area when the model you are distilling from belongs to a competitor with terms of service explicitly prohibiting it.

OpenAI has been particularly aggressive about this lately. Earlier this year, the company told a House committee it had taken steps to "harden" its models against distillation, framing the issue largely around Chinese AI labs — specifically DeepSeek — repurposing American innovation. The Trump administration echoed that concern, with the White House's science and technology office pledging to share intelligence with US AI companies about foreign distillation attempts.

What makes Musk's courtroom admission so pointed is the context. He is not a foreign competitor. He is the guy who co-founded OpenAI, left, and then built a rival company while publicly arguing that OpenAI had betrayed its original nonprofit mission. His entire legal case rests on the idea that OpenAI acted in bad faith. Admitting — even obliquely — that xAI benefited from OpenAI's work does not exactly reinforce that narrative.

To be fair, Musk's framing has some truth to it. AI labs routinely use competitors' models as benchmarks, reference points, and sanity checks. It is genuinely common practice. But there is a meaningful difference between "we tested our model against GPT-4 to see how we compared" and "we used GPT-4's outputs to shape what our model learned." Musk's answers in court blur that line rather than clarify it.

The broader picture here is that the AI industry's habit of borrowing from itself is finally getting scrutinized in public. Anthropic cut off OpenAI's access to Claude last August after a terms-of-service dispute, and more recently blocked xAI from using its coding models too. The era of everyone quietly training on everyone else's outputs may be coming to an end — whether the courts force it or not.

OpenAI and xAI both declined to comment. The trial continues.

A single Python script, released publicly this week, is capable of turning any unprivileged user into a root administrator on virtually every major version of Linux currently running in production. That is not a hypothetical. The exploit code works right now, and most systems have not been patched.

The vulnerability is called CopyFail, tracked as CVE-2026-31431, and it was disclosed Wednesday by researchers at security firm Theori — five weeks after they privately told the Linux kernel security team about it. Kernel patches exist for several versions, but the vast majority of Linux distributions had not yet shipped those fixes when the exploit code dropped publicly. That gap, between "patch exists" and "patch is installed," is exactly where attackers live.

What makes CopyFail especially alarming compared to most Linux vulnerabilities is its consistency. A lot of serious kernel exploits are finicky — they work on some versions, fail on others, require careful tuning for specific memory layouts. CopyFail does not have that problem. The same script works reliably across Ubuntu 22.04, Amazon Linux 2023, SUSE 15.6, and Debian 12, with no modification required. That kind of cross-distribution reliability is rare, and it significantly lowers the bar for attackers.

The flaw lives in the kernel's crypto API and stems from a straightforward logic error rather than a race condition or memory corruption bug. That is part of why it is so reliable — there is no timing window to hit, no heap spray to get right. The exploit works cleanly because the underlying mistake is clean.

The real danger here is not just that root access is possible. It is what "local" actually means in 2026. In a shared Kubernetes cluster, every container on the same node is sharing one Linux kernel. A CI/CD pipeline running untrusted code from a pull request is sharing that kernel. A cloud tenant on a shared hosting box is sharing it. An AI agent with shell access is sharing it. Once someone exploits CopyFail, the isolation those environments are supposed to provide collapses entirely.

The realistic attack chain is not exotic. An attacker finds a known vulnerability in a WordPress plugin, gets a shell as a low-privilege web server user, runs the CopyFail script, and is suddenly root on the host machine. Every other tenant on that box is now exposed. The initial intrusion does not need to be sophisticated — CopyFail handles the escalation.

Security teams managing Linux infrastructure should treat this as a drop-everything situation. Check whether your distribution has shipped the patched kernel version, and if it has not, start looking at what compensating controls you can put in place in the meantime — restricting unprivileged user namespaces is one option that can reduce exposure. The patch exists. The exploit is public. The window to act before attackers do is not wide.