Jun 4, 2026 3:18:46 PM
Igor Seletskiy
Igor Seletskiy, CEO and founder of CloudLinux and creator of Imunify360, has over twenty years of experience in hosting and cybersecurity. He is widely recognized for his leadership and practical insight into the challenges facing modern web hosts.
For decades, the hosting industry operated under a predictable security rhythm. A major local privilege escalation (LPE) kernel vulnerability would emerge perhaps once a year. System administrators would scan the vendor change logs, assess the threat, and schedule a patch window or server reboot when convenient.
That era is officially over.
In a matter of just a few weeks, the industry has suffered a rapid succession of root exploits — Copy fail, Dirty frag, and Fragnesia, to name a few. We are no longer dealing with isolated, seasonal security events. We are living through a continuous barrage where new critical kernel vulnerabilities are surfacing weekly. Based on what I’m seeing, the next three to six months will be extremely intense, and the overall elevated threat environment will persist for roughly a year and a half.
What caused this sudden paradigm shift? The maturation of modern Large Language Models (LLMs)
Contents
Both security researchers and vendors are aggressively leveraging AI models to audit source code. These tools are exceptionally proficient at uncovering deep, systemic flaws that went unnoticed by human eyes for years. But this velocity creates a dangerous side effect: as fast as defenders can find and patch a vulnerability, threat actors are watching, waiting to reverse-engineer the fix.
Because malicious actors treat public security bulletins as a roadmap for exploitation, software vendors have quietly changed their tactics. They are no longer explicitly labeling critical fixes as “security updates” in their change logs. They are quietly shipping them inside routine, generic software updates, to protect their user base from immediate exploitation.
For hosting providers, this creates an acute operational crisis. And to understand why, it helps to be clear about how hosting actually operates.
Hosting is not enterprise
The conventional security advice you’ll read in most industry publications is written for enterprise environments – organizations that run structured patch and reboot cycles, with scheduled maintenance windows and established approval processes for every change.
Hosting companies don’t work that way, and most never did. Hosters typically fall into one of two patterns:
- they either run environments that are continuously updating,
- or they update ad-hoc, when they feel like it, or when a major vulnerability forces their hand.
Neither pattern was a serious problem when critical LPE bugs surfaced once a year. Both are a liability now.
In a shared hosting environment, you are running hundreds of web applications on a single server with a shared kernel. The blast radius of an unpatched LPE bug is absolute. A hacker doesn’t need to target your infrastructure directly. They just need to compromise any one of the sites you host. Once they have code execution on the machine, an LPE vulnerability gives them superuser access to the entire physical server, which means every tenant, every account, everything on it.
Before, we’d see one vulnerability of this type per year. Now it’s every week. The calculus around acceptable patching cadence has completely changed.
The change log is no longer a signal hosters can trust
In the new cadence of new CVE disclosures, hosters can no longer rely on a vendor’s change log to tell you whether an update is security-critical.
Vendors are intentionally not labeling security fixes as security fixes, and it is a calculated defensive move. Threat actors actively monitor security bulletins. The moment a vendor publishes a CVE or tags a release as a security update, attackers begin reverse-engineering the patch to construct an exploit. So vendors have started shipping critical security fixes inside generic software releases, with no indication in the release notes that anything sensitive changed.
The absence of a security label on the update does not mean an update isn’t a security update. Hosting providers must now operate on the assumption that any software update from any vendor is potentially a security update, and should be deployed.
This isn’t limited to the Linux kernel. It applies to everything running on your systems.
What the next 12 months look like
The immediate intensity — weekly critical vulnerabilities — will likely persist for three to six months. But even when that frequency begins to ease, the threat doesn’t go away.
As LLMs mature and become more capable, the nature of attacks will shift. Rather than finding single high-severity flaws, these models will chain together multiple low-severity vulnerabilities to achieve the same privilege escalation result. The frequency may decrease slightly, but the sophistication will increase.
Continuous updating is not a temporary response. It is the permanent new posture.
Two things to change now if you are in hosting
First, assume every update is a security update. Stop parsing change logs or trying to determine whether a release is essential before applying it. If a vendor releases an update for software running on your systems, deploy it.
Second, eliminate the reboot bottleneck for kernel patches.
This is the practical constraint that makes continuous kernel patching painful for hosting providers. Every kernel update traditionally requires a server restart to take effect, which means downtime, which in hosting means unhappy customers. Live-patching tools like KernelCare solve this by applying kernel security patches without a reboot, keeping servers protected and online simultaneously.
If you’re already using Imunify360, KernelCare is included. If not, it’s available as a standalone product with a free trial.
Igor Seletskiy is the Founder and CEO of CloudLinux, the company behind CloudLinux, KernelCare, Imunify360, and TuxCare.
