Linux servers: a limited user is no longer enough. Updated kernels and reboots
On 4 November OpenAI published the results of an AI agent pipeline that found and exploited hundreds of Linux kernel vulnerabilities. The message for anyone running servers is simple: on a system that is not up to date, a limited account is worth almost as much as administrator access.
What happened
On 4 November 2026 OpenAI described a pipeline of AI agents that looks for vulnerabilities in the Linux kernel, reproduces them, tries to exploit them and proposes a fix. In a single run in mid-October it examined 2,308 candidate flaws, reproduced 1,724 and produced 948 distinct local privilege escalation exploits on a commonly used, unweakened Linux distribution (OpenAI).
The stated cost is about 1.2 million dollars of model usage, roughly 1,279 dollars per exploit. According to OpenAI the agents used at least 10 exploitation techniques that were new even to the experts consulted.
Fixes are arriving quickly: during the 10 days of the research, 61 of these vulnerabilities had already been fixed in the upstream kernel, 43 had a patch in staging and 299 were being discussed publicly (OpenAI). They arrive, however, only for those who update.
What local privilege escalation means
On a Linux server every program runs with the permissions of a user. A WordPress site, for example, usually runs as a user that can only read and write its own files. If the site is hacked, the attacker gets those permissions and nothing more: this is the principle behind isolating sites from each other.
A local privilege escalation (LPE) is a flaw that lets that limited user become root, the server's administrator. As root you can read every site's files, database passwords and keys, and install anything.
OpenAI's conclusion is blunt: in the near and medium term, a low-privileged account on a system without the latest patches should be considered equivalent to root access for a well-resourced attacker (OpenAI).
Why it matters for an SME too
An attack like this needs a first foothold on the server. In real cases it is almost always one of these:
- a site hacked through a vulnerable plugin or a flaw such as PHP2Shell;
- an SSH account belonging to a supplier or former collaborator that was never removed;
- an application that runs code uploaded by users, such as file imports or document previews.
On a server with a single site, the damage stays in that site. On a server hosting ten sites for different clients, an escalation turns one site's problem into everyone's problem. That is why per-user isolation is useful, but it only holds if the kernel underneath is up to date.
Updating the kernel is not enough: you have to reboot
An often forgotten detail: installing the new kernel package does not protect the server. The fixed kernel only takes effect at the next reboot. A server that has been running for months can have the latest kernel sitting on disk and still be running the old one.
| Situation | Is the server protected? |
|---|---|
| Automatic updates on, no reboot for months | No: the running kernel is the one from the last boot |
| Kernel updated and server rebooted | Yes, until the next fix |
| Livepatch on, scheduled reboots | Yes for high and critical vulnerabilities patched live; the rest at reboot |
| Operating system out of support | No: fixes no longer arrive |
Ubuntu has Livepatch, which applies kernel fixes for high and critical vulnerabilities in memory without a reboot. It is included in Ubuntu Pro, free for personal use on up to 5 machines. Canonical itself points out that it does not remove the need for scheduled reboots, it reduces them (Ubuntu).
What to do on your servers
- 01
Check the running kernel
For each server, compare the running kernel with the latest installed one and look at how long the server has been up. On Ubuntu and Debian the file /var/run/reboot-required signals that a reboot is needed.
- 02
Set a reboot window
A scheduled reboot every week or two, at a low-traffic time, costs a few minutes of downtime and solves the problem at the root. For sites that cannot stop, you design redundancy instead of postponing the reboot.
- 03
Turn on Livepatch where it matters
On the most exposed servers it covers high-severity vulnerabilities between one reboot window and the next.
- 04
Move off unsupported systems
An end-of-life operating system no longer gets kernel fixes: migrate it, or cover it with extended support such as Ubuntu Pro.
- 05
Remove access you do not need
SSH accounts of suppliers and former collaborators, old keys, test users: every local account is a possible starting point.
- 06
Separate what matters most
Sites and applications holding health data, payments or customer data are better off on their own servers or cloud accounts. If one is compromised, the others stay out of it.
- 07
Watch what happens
New users, new SSH keys, unknown root processes and modified system files are the signals that matter. Better to find them through an automatic check than from a client.
How we work
At Cloudfactory we manage more than 110 Linux and Windows servers for companies, professional firms and healthcare providers. After PHP2Shell we strengthened the isolation between sites; this research is a reminder that isolation is only as good as the kernel it sits on. That is why kernel updates and reboots have a date in our maintenance plans, and projects with sensitive data run on separate infrastructure.
If you want to know how long your servers have gone without a reboot and which kernel they are running, get in touch: it is a quick check.
How we wrote this article
At Cloudfactory we also use artificial intelligence in our editorial work: it helps us find and cross-check sources, compare data, set up the structure and polish the language. The system we use is configured by us, with instructions, examples and procedures built around the way we write. Our team checked every source, corrected the text and approved the published version. The assessments and choices are Cloudfactory's, and we are accountable for them.
Frequently asked questions
If my server has automatic updates, am I safe?
Not entirely. Automatic updates install the new kernel, but until the server reboots it keeps running the old one. Check how long it has been up.
Can these vulnerabilities be exploited from the Internet?
No, they need initial access to the server, such as a hacked site or an SSH account. They are the second half of an attack: they turn a limited problem into full control of the server.
Does Livepatch replace reboots?
No. It covers high and critical kernel vulnerabilities between maintenance windows, but Canonical still recommends scheduled reboots.
I use shared hosting: what can I do?
Ask your provider how often it updates and reboots its servers and whether client sites are isolated. If the site handles sensitive data, consider a dedicated server.