Linux kernel CVEs on the rise: how Host.it live-patches without rebooting servers

Two things stacked, and they should be kept apart. The first is administrative. Since February 2024 the Linux kernel is a CVE Numbering Authority: many issues that used to live on mailing lists or in commits now ship with a public ID. The catalogue grew even without a sudden epidemic of new bugs.

The second is technical, and that is what changed the pace in recent months. Fuzzing (syzkaller and friends) has run for years. What changed is AI assistance in the hunt: agents that explore surfaces, cut false positives, help write reproducers and close the loop through to publication. More automated eyes, more CVEs. “Thanks” to AI, in the strict sense: more vulnerabilities found and disclosed, not a kernel that suddenly became weaker.

What a kernel CVE is not (and what it is)

A kernel CVE is not a plugin you click in a dashboard. It is an identifier for an operating-system defect under WordPress, Joomla, the shop, mail. Severity is case by case: not every ID is exploitable on shared hosting, and not every one needs an immediate reboot. What changed is the cadence: the patch backlog to review is no longer a monthly event.

The surface an agency sees is CMS, plugins, PHP, certificates. The surface an attacker can use also includes the kernel, drivers, namespaces, the network. You do not need to become kernel hackers. You do need to know who patches what, how fast, and with what impact on uptime.

Three layers, three responsibilities

• Application. Core, themes, plugins: your job, or a retainer you sell. Staging, backups, a verification window.
• System. Kernel, libc, hypervisor: the hoster’s job. If the hoster only patches by rebooting, every serious CVE becomes scheduled downtime.
• The client contract. Who answers if the shop is down during a sale? If it is not written down, you pay in reputation.

For a web agency with fifty or two hundred sites the kernel is invisible until it works. It becomes visible the night ten clients time out at once. This is not “security in the abstract”: it is continuity of the service you sold.

A classic kernel patch is easy to explain and expensive to live: you install, reboot, wait for services to come back, check that PHP, the database and the mail queue are up. On one server it is a window. Across a fleet it is a calendar of outages.

What the client pays (and what you pay)

• Minutes of downtime. An e-commerce shop in an ads campaign does not distinguish “kernel maintenance” from “unreliable hosting”.
• Overnight windows. If every advisory wants a reboot, the nights multiply. Internal staff or the supplier have to cover them.
• Ticket storms. Even a clean reboot produces monitoring alerts and phone calls. It costs more than the patch.

The alternative is not to ignore CVEs. It is to separate the fix from the reboot: apply the patch in memory when you can, and keep reboots for when you need a new kernel, not for every ID published on a Monday morning.

At Host.it the strategy is built for Client uptime, not for an internal calendar. When a relevant kernel advisory lands, we apply the fix live (live / hot patch): the vulnerable code in memory is replaced without a power cycle. Sites stay reachable. It is not magic and it does not erase every reboot in a server’s life: it removes the need to reboot constantly just to keep up with CVE cadence.

What we do in practice

• Triage. Not every kernel CVE has the same impact on our stack. We prioritise those that touch the real exposure of the services.
• Real-time patching. Where live patching covers the defect, the fix ships to production without hypervisor or machine downtime.
• Reboot only when needed. A new kernel, a dependency live patching cannot cover, a planned window: reboot stays a tool, not the default answer.
• Observability. We watch that services stay healthy after the patch. We measure uptime; we do not declare it on a slide: see uptime transparency.

It applies to the infrastructure under hosting, cloud and VPS: the end customer should not have to learn what a live patch is. They should find the site up. If you run the fleet as an agency, you see the difference in the tickets that do not arrive. Details on Host.it security and VPS.

A kernel CVE is an awkward meeting topic until you tell it as technology. It becomes a line on the rate card if you translate it into continuity, responsibility and retainer.

• An honest uptime clause. Do not promise 100%. Explain that system security updates do not mean the site goes dark on every advisory. That is a concrete reason to stay with a hoster that patches live.
• A maintenance report. One line in the monthly report: “kernel updated, no reboot downtime”. The client does not understand the CVE; they understand someone did the work without closing the shop.
• Hosting as governance. With Host Bucket you isolate clients, resell under your brand and keep Italian infrastructure. Kernel patching is not an extra: it is part of the reliability you are selling.

None of these three things comes from a prompt. They come from an agency that chose where sites run and can explain it.

Linux kernel CVEs will keep coming, partly because numbering is broader, partly because AI helps find them earlier. Anyone who answers every ID with a reboot stacks downtime. Anyone who ignores advisories stacks risk. The third way is the one we use at Host.it: real-time patches, reboots only when needed, uptime as a constraint.

If you run sites for other people, this is the conversation to have with the hoster, not with the CMS. To talk about your fleet: contact us. For the reseller programme: hosting for web agencies.