Kernel CVEs land every few weeks. The traditional answer — schedule a maintenance window, reboot, take the downtime — does not scale past about 20 servers, and it does not work at all if you sell uptime SLAs. Live patching closes the gap between CVE disclosure and patched-in-production from days to hours, without a reboot.
This article compares the three realistic options for a hosting fleet in 2026 — KernelCare, Oracle Ksplice, and a disciplined reboot window — on coverage, cost, operational fit, and compliance.
Why live patching matters
The window between a kernel CVE being disclosed and being weaponised is shrinking. Public PoC code typically appears within 7 days of disclosure for kernel privilege-escalation bugs; some appear within hours. If your reboot window is monthly, you are exposed for up to 30 days per CVE.
The compliance angle is increasingly explicit: PCI-DSS 4.0 expects critical patches within 30 days, HIPAA expects "promptly", and a recent ISO 27001 audit we saw flagged "lack of evidence of patch latency monitoring" as a major finding. Live patching gives you both the patch and the audit trail.
At a glance
| Dimension | KernelCare | Oracle Ksplice | Reboot windows |
|---|---|---|---|
| Distros | RHEL/CentOS/Alma/Rocky, Ubuntu, Debian, Oracle Linux, CloudLinux | Oracle Linux (practical), RHEL/CentOS (with caveats) | Any |
| Userland live patching | Yes (LibCare for glibc, OpenSSL) | Yes (UEK) | N/A |
| ePortal (on-prem) | Yes | No | N/A |
| cPanel integration | Native plugin | None | Manual |
| Patch cadence | Within 24-48h of CVE | Within 24-48h for Oracle kernels | Per your schedule |
| Cost per server / year | $45-65 retail; lower in bulk | Included with Oracle Linux support | Free (your time) |
| Vendor lock-in | Low (TuxCare, multi-distro) | High (Oracle Linux) | None |
| Audit trail | ePortal dashboard, API | Ksplice uptrack-show | Manual changelog |
KernelCare
The default choice for mixed-distro hosting fleets. KernelCare from TuxCare patches the running kernel without rebooting, supports every realistic hosting distro, and ships an on-prem ePortal that lets you stage patches, restrict to changesets, and report on patch lag across the fleet.
What you get:
- Distro coverage — RHEL 7/8/9 family (CentOS, AlmaLinux, Rocky), Ubuntu LTS, Debian, Oracle Linux, CloudLinux. CloudLinux ships KernelCare's tech as the basis for CloudLinux's own live patching — same engine, different SKU.
- LibCare — live patches for glibc, OpenSSL, and other userland libraries. Saves restarts of long-running processes after a glibc CVE.
- ePortal — on-prem patch server. Mirror patches internally, stage releases, restrict which CVEs deploy when, full audit log. Required for air-gapped environments and useful for everyone else.
- cPanel plugin — surface patch state per server in WHM without an SSH session.
Cost: $45-65/server/year at retail; volume pricing through panellicense brings it below that — see KernelCare licensing. For a 100-server fleet at $50/server, KernelCare costs $5,000/year, which is one engineer-day spent debugging a CVE response.
Oracle Ksplice
Bundled with Oracle Linux Premier support. Technically excellent, practically limited.
The Oracle Linux story is strong — Ksplice was the original live-patching technology, Oracle bought it, and integration with UEK is tight. If your fleet is Oracle Linux, Ksplice with Premier support is the lowest-friction option and you pay for it via the OS subscription anyway.
The RHEL/CentOS story is much weaker. Ksplice technically supports RHEL, but the CentOS rebuild has slipped repeatedly, AlmaLinux and Rocky are not officially covered, and there is no on-prem patch server analogous to ePortal. For a hosting fleet of mixed RHEL-family distros, this is a non-starter.
There is also no cPanel integration — cPanel is not a supported workload from Oracle's perspective.
Reboot windows
Free and fully supported by every distro. Acceptable if:
- Your fleet is under 20 servers
- Your customers tolerate scheduled maintenance
- You have HA or load-balancer redundancy that lets you reboot one node at a time without user-visible downtime
- Your compliance regime accepts a monthly patch cadence
A disciplined kpatch-aware reboot window with unattended-upgrades on Debian/Ubuntu or dnf-automatic on RHEL-family, paired with monitoring that pages you when a server is more than N days behind, covers a lot. It does not cover the gap between CVE disclosure and your next window, which is what you are paying for with live patching.
Operational fit
The patch-lag metric matters more than the patching mechanism. Whatever you choose, instrument:
- Time from CVE publication to patched-in-production per host
- Percentage of fleet patched within 7 / 14 / 30 days
- Hosts more than 60 days behind (always investigate)
KernelCare's ePortal gives you this for free. Ksplice has it via uptrack-show and the Oracle reporting tools. With reboot windows, you build it from uname -r and CVE feeds.
Compliance
For PCI-DSS, HIPAA, ISO 27001, or SOC 2, auditors want:
- Patch policy — written, signed, scoped
- Patch evidence — log of what was applied when, to which hosts
- Patch latency monitoring — alerts when hosts fall behind
KernelCare's ePortal produces audit-ready reports out of the box. Ksplice has the data; report generation is manual. Reboot windows mean rolling your own — usually a Confluence page that drifts.
Recommendation
- Mixed RHEL/CentOS/Alma/Rocky/Ubuntu fleet — KernelCare. The distro coverage and ePortal pay for themselves.
- Pure Oracle Linux fleet — Ksplice. Already included with Premier.
- Small fleet, tolerant customers, no compliance pressure — disciplined reboot windows with
unattended-upgradesare fine. - Pure CloudLinux fleet — KernelCare ships with CloudLinux. You already have it; enable it.
For the deeper KernelCare vs Ksplice technical comparison, see KernelCare vs Ksplice. For the rollout playbook, see KernelCare onboarding for a production fleet.
Next steps
- Compare tools: KernelCare vs Ksplice.
- Roll out: KernelCare onboarding for a production fleet.
- Buy or renew: KernelCare license.