KernelCare live patching on cPanel: zero-reboot kernel CVEs

Kernel CVEs are the worst kind of maintenance window for a hosting provider. Every customer's site goes dark for 3–5 minutes during the reboot, the support inbox fills up, and you still ran a vulnerable kernel for the hours or days between patch release and your scheduled window.

KernelCare — CloudLinux's live-patching service — applies kernel security patches into the running kernel without a reboot. This guide walks through installing it on a cPanel server, verifying patches are actually applied, and the userspace gap that the basic license doesn't close.

What KernelCare actually patches

A KernelCare patch is a binary diff against the kernel's text segment, loaded into a reserved memory region at runtime. The kernel keeps running; the next call to a patched function takes the new code path.

Out of the box, the basic license covers:

• The Linux kernel itself — RHEL-family (AlmaLinux, Rocky, CloudLinux, EOL CentOS), Ubuntu, Debian, openSUSE
• Both stock and CloudLinux kernels (the CL kernel runs LVE; KernelCare patches it too)
• Most kernel modules shipped by the distro

What it doesn't patch with the standard license:

• glibc, OpenSSL, and other userspace libraries — userspace patching requires the KernelCare+ SKU
• Third-party out-of-tree kernel modules (e.g. proprietary RAID drivers)
• A handful of very specific patches the vendors flag as needing a reboot (rare — normally once or twice a year)

If your threat model includes Heartbleed-class userspace CVEs, plan on KernelCare+ from the start. The basic license alone leaves your long-lived Exim and PHP-FPM processes running against vulnerable shared libraries until the next service restart.

Step 1 — Check kernel compatibility

KernelCare supports specific kernel build numbers, not every kernel that has ever shipped. Run the compatibility checker before buying anything:

curl -s -L https://kernelcare.com/checker | python3

The script reports Your kernel is supported or names the closest supported build. Custom-compiled kernels and kernel-ml/kernel-lt builds from ElRepo are usually not supported — switch back to the distro kernel first.

For end-of-life kernels (CentOS 7, RHEL 6) you need Extended Lifecycle Support (ELS), which is a separate add-on. If you're still on CentOS 7, the migration to AlmaLinux on cPanel is the cheaper path long-term.

Step 2 — Install the agent

One-liner from the vendor, identical on RHEL-family and Ubuntu:

curl -s -L https://kernelcare.com/installer | bash

This installs the kcare package, drops kcarectl in /usr/bin, registers a systemd timer for auto-updates, and enables the daemon. No reboot.

Step 3 — Activate the license

If you bought a key directly from CloudLinux:

kcarectl --register ACTIVATION-KEY-HERE

If you bought through a reseller and the license is IP-locked (as it is when you activate KernelCare via panellicense), the activation is automatic — only run:

kcarectl --update

The agent contacts the patch server, downloads the patch set matching your exact kernel build, and applies it. The whole thing takes 10–30 seconds.

Step 4 — Verify patches are actually live

This is the step most operators skip and then discover, mid-incident, that auto-updates were broken for three months. Do it now.

Show what kernel version the running kernel is patched to:

kcarectl --uname

The output reports the effective patched version, usually one or two minor versions ahead of uname -r. Then dump the patch set:

kcarectl --patch-info

Each entry shows its CVE ID, the kernel symbol it modifies, and the date it was applied. Cross-reference against the vendor's published patchset feed if you want to confirm you're current.

Finally, scan for CVEs the patches were supposed to close:

kc-prod-scanner -v

A clean run reports No vulnerabilities found. Anything else is a real audit finding.

Step 5 — Tune auto-updates

The defaults in /etc/sysconfig/kcare/kcare.conf are sensible:

AUTO_UPDATE=True
PATCH_METHOD=auto

The daemon checks every 4 hours and applies new patches as they ship. The 4-hour cadence is the right fit for hosting — a fresh CVE patch lands across your fleet within one business day of release, which beats anything you'd achieve with a manual reboot window.

If you have a change-control process that requires manual patch approval, switch to:

AUTO_UPDATE=False

…and run kcarectl --update from your config-management tool after sign-off.

Step 6 — Roll back if a patch misbehaves

Live patches are reversible. To unload all KernelCare-applied patches and revert to the on-disk kernel state:

kcarectl --unload

The next --update will re-apply them. To freeze the system on the current patch level and block auto-updates from going further:

kcarectl --freeze

In four years of production use across our fleet, we've unloaded a KernelCare patch exactly once — a patch interacted badly with a custom XFS workload, and the vendor turnaround was under 24 hours. The rollback path exists, but it isn't a regular operational concern.

Step 7 — Plug the userspace gap

Kernel CVEs are loud; the bigger fleet-wide risk is the userspace OpenSSL/glibc CVE that needs every running service restarted. LibCare (the userspace half of KernelCare+) patches glibc, OpenSSL, and a few other shared libraries in-memory while processes keep running:

libcare-ctl info
libcare-ctl update

For a hosting business running thousands of long-lived PHP-FPM and Exim processes, this is the difference between a 6-hour rolling restart of every cPanel server and a 30-second patch. If you're already paying for KernelCare, the upgrade to KernelCare+ is normally worth it on the first major OpenSSL CVE of the year.

Common mistakes

1. Trusting the installer without kc-prod-scanner. The install completes successfully on a kernel KernelCare can't actually patch — the agent just sits there with an empty patch set. Always run the scanner after first install.
2. Blocking outbound HTTPS to the patch server. Strict egress rules silently break auto-update. Whitelist patches.kernelcare.com or run ePortal as an internal mirror.
3. Forgetting KernelCare on the CloudLinux server. CloudLinux ships its own kernel, but it still needs patching — KernelCare patches the CL kernel too, and is the natural pairing with your CloudLinux LVE setup.
4. Skipping ELS on EOL distributions. CentOS 7 kernels in 2026 are not patched by the base KernelCare subscription. Either buy ELS, or finish the migration off CentOS 7 — half-measures here are how you end up with a 22-month-old unpatched kernel in production.

FAQ

Next steps

• If you haven't activated the underlying CloudLinux license yet, install CloudLinux on cPanel is the prerequisite for getting the bundled KernelCare entitlement on Premium tiers
• For the resource-isolation side of the story, see CloudLinux LVE tuning without angry customers
• Bundles and per-server pricing live on the licensing pricing page — KernelCare is included with some CloudLinux tiers and standalone for non-CL servers