Enable the KernelCare included with your Imunify360 license

Every Imunify360 server is entitled to KernelCare live kernel patching at no extra cost. Imunify's own documentation is blunt about it: KernelCare "is free on the servers with Imunify360 installed". It is not switched on by default, though, and plenty of hosts either leave it off or buy a separate KernelCare seat for the same box.

This guide covers checking whether it is active, enabling it from the dashboard or the CLI, confirming patches are applied, and cancelling any standalone KernelCare license you no longer need. It assumes Imunify360 is already installed and licensed. If not, start with installing Imunify360 on cPanel or on Plesk.

Why this matters now

Kernel local privilege escalations are arriving faster than most hosts schedule reboots. In the space of two weeks in spring 2026, three went public: Copy Fail (CVE-2026-31431) on 29 April, Dirty Frag (CVE-2026-43284 and CVE-2026-43500) on 7 May, and Fragnesia (CVE-2026-46300) on 13 May. Each one turns an unprivileged shell user into root. On a shared server that means one compromised customer account becomes a full-server compromise.

KernelCare patched all three live, without a reboot. The autumn wave, covered in our CloudLinux KEV kernel CVEs advisory, follows the same pattern. With live patching enabled, a new kernel CVE is closed as soon as TuxCare ships the patch. Without it, every fix waits for a reboot window across the fleet.

Check whether KernelCare is already enabled

From the dashboard

Open Imunify360 in WHM, Plesk, or DirectAdmin and look for the KernelCare tab in the main menu. If it is active, the tab shows four fields:

• Effective Kernel Version — the patched kernel version actually running
• Real Kernel Version — the kernel the server last booted with
• Update mode — the automatic patching toggle
• Uptime — kernel uptime in days

If the tab offers to install KernelCare instead, it is not enabled.

From the CLI

imunify360-agent features status kernelcare

On a server where it has never been enabled, the output is:

{'status': 'not_installed', 'message': 'KernelCare is not installed'}

To audit a fleet, run the same command over SSH against every node and grep for not_installed. The rest of the imunify360-agent subcommands are in our Imunify360 agent CLI reference.

Enable KernelCare

Via the dashboard

1. Open Imunify360 in the admin interface.
2. Go to Settings → General → Installation.
3. Click Install KernelCare.

When the install finishes, open the KernelCare tab and confirm Update mode is set to automatic.

Via the CLI

imunify360-agent features install kernelcare
imunify360-agent features status kernelcare

The features subcommand only manages the CloudLinux software bundled with Imunify360. The other bundled item is Hardened PHP (hardened-php), which you need if you still host end-of-life PHP versions. You can list what is available with imunify360-agent features list, and uninstall with imunify360-agent features remove kernelcare.

Verify patches are applied

Once KernelCare is installed, its own kcarectl tool reports the patch state:

kcarectl --uname        # the "safe" (effectively patched) kernel version
kcarectl --info         # patches installed by KernelCare
kcarectl --patch-info   # applied patches, per CVE

kcarectl --patch-info is the command to use when a customer or auditor asks whether a specific CVE is fixed. Grep its output for the CVE ID. Run kcarectl --update to fetch and apply them immediately rather than waiting for the next four-hour check.

Automatic updates are controlled by AUTO_UPDATE=YES in /etc/sysconfig/kcare/kcare.conf. The Update mode toggle in the dashboard does the same thing, so pick one place to manage it.

Stop paying for KernelCare twice

This is the part most hosts miss. If a server already carries a standalone KernelCare license and an Imunify360 license, you are paying for live patching twice. Imunify's documentation says to cancel the standalone KernelCare license on any server where Imunify360 is installed, because KernelCare is free there.

Before cancelling:

1. Confirm the server's Imunify360 license is active with imunify360-agent rstatus.
2. Run kcarectl --license-info to see which license the KernelCare agent is currently using.
3. Make sure the server is running Imunify360, not ImunifyAV or ImunifyAV+. Imunify's documentation ties the free KernelCare to Imunify360 only. Our ImunifyAV vs Imunify360 comparison covers the differences.

Then cancel the standalone seat. For licenses bought through us, open a ticket with the server IP to cancel it. At our list price that saves $3.95 per server per month. Across a 20-server fleet that is about $950 a year.

Where the bundle stops making sense

The bundle only applies while Imunify360 is installed and licensed on that server. If you plan to drop Imunify360 on some nodes, for example moving a VPS line to ImunifyAV or to a different security stack, budget a standalone KernelCare seat for those nodes first. Otherwise their kernel patching stops with the Imunify360 license. Nodes that never ran Imunify360, such as database servers, DNS-only boxes, and backup targets, still need their own KernelCare license. Our guide to live patching across a hosting fleet covers how to plan coverage for those nodes.

Next steps

• Read KernelCare live patching on cPanel for the agent's behaviour on cPanel nodes in more depth.
• Hit a license or registration error? See fixing KernelCare license errors.
• Need Imunify360 on more servers? Activate it on the Imunify360 license page or compare tiers on pricing.