What Happened?

CloudLinux recently published advisories for two serious Linux kernel vulnerabilities: GhostLock CVE-2026-43499 and JanusCape CVE-2026-53359. Although the CloudLinux advisories focus on CloudLinux OS, the underlying issues are in the Linux kernel and can affect other distributions depending on kernel version, vendor backports, kernel configuration, and whether KVM is exposed.

These issues matter because kernel-level vulnerabilities can turn a limited local account, compromised website process, shell user, or virtual machine guest into a much larger server-level security risk. On multi-tenant hosting systems, the correct response is not to wait for symptoms. The correct response is to patch, reboot when required, and verify the running kernel.

Who Needs to Take Action?

You should review and patch immediately if you manage your own VPS, dedicated server, virtualization node, private cloud host, or any Linux system where customers, developers, websites, containers, or untrusted processes can run local code.

Check Your Current Kernel

Before patching, record your current kernel. After patching and rebooting, run the same command again to confirm the new kernel is active.

uname -r
cat /etc/os-release

For KernelCare users, verify CVE-level patch status with:

kcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53359|CVE-2026-46113'

Quick Patch Guide by Distribution

The commands below are general update instructions for self-managed systems. Always check your distribution security advisory and test carefully on production workloads. Kernel patches often require a reboot unless a livepatching service is installed and has released coverage for your exact kernel stream.

CloudLinux 7, 7h, 8, 9 and 10

CloudLinux customers should follow the official CloudLinux advisory for the exact fixed kernel stream. On stable channels, use the normal package manager first:

# CloudLinux 7 / 7h / 8
yum clean all
yum update 'kernel*'
reboot

# CloudLinux 9 / 10
dnf clean all
dnf update 'kernel*'
reboot

If CloudLinux has not yet promoted the fixed kernel to your stable repository, CloudLinux may instruct administrators to use a testing repository temporarily. Use testing repositories only when you understand the operational risk or when your security exposure is greater than the risk of early kernel deployment.

AlmaLinux, Rocky Linux, RHEL-Compatible Systems

dnf clean all
dnf update kernel kernel-core kernel-modules kernel-modules-core
reboot

After reboot:

uname -r
dnf updateinfo list security --available

Ubuntu 22.04, Ubuntu 24.04 and Debian

apt update
apt full-upgrade
reboot

After reboot:

uname -r
apt list --upgradable

KernelCare Livepatching

If you use KernelCare, apply available livepatches and verify the CVE-level patch list:

kcarectl --update
kcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53359|CVE-2026-46113'

If no livepatch exists yet for your kernel stream, install the vendor kernel update and reboot during a maintenance window.

JanusCape: Review KVM Exposure

JanusCape is particularly important for KVM hypervisors and systems exposing /dev/kvm. If the server does not run virtual machines, reducing the KVM attack surface is a reasonable temporary hardening step while the kernel update is being deployed.

Check whether KVM is loaded:

lsmod | grep kvm
ls -l /dev/kvm

If the server does not run virtual machines, you may unload KVM modules temporarily:

# Intel hosts
modprobe -r kvm_intel kvm

# AMD hosts
modprobe -r kvm_amd kvm

# Verify
lsmod | grep kvm

To prevent KVM from loading on boot on non-virtualization servers:

cat > /etc/modprobe.d/disable-kvm.conf <<'EOF'
install kvm_intel /bin/false
install kvm_amd /bin/false
EOF

If the server is a KVM hypervisor, do not disable KVM. You may restrict local access to /dev/kvm, but this does not protect against a malicious guest-to-host path:

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' > /etc/udev/rules.d/65-kvm.rules
udevadm control --reload-rules
udevadm trigger /dev/kvm
ls -l /dev/kvm

Recommended Hardening Checklist

• Patch the kernel: Use your vendor repositories or approved livepatch provider.
• Reboot when required: Installing a new kernel package is not enough if the old kernel is still running.
• Verify the active kernel: Always confirm with uname -r after reboot.
• Review KVM exposure: Check /dev/kvm permissions and whether KVM modules are loaded.
• Limit shell access: Disable unnecessary user shells and remove abandoned accounts.
• Update control panels: Keep cPanel, DirectAdmin, Plesk, Virtualmin, aaPanel and related services current.
• Update web apps: Compromised CMS sites can provide the local process needed to abuse kernel bugs.
• Keep backups current: Maintain off-server backups before emergency patching and reboots.
• Monitor logs: Review authentication, kernel, audit, web server and control panel logs after patching.

Before You Reboot: Protect Your Data

Kernel patching often requires a reboot. Before restarting a production server, confirm that your backups are current and restorable. For database-heavy workloads, gracefully stop or flush services when possible, especially on busy MySQL, MariaDB, PostgreSQL, Redis, mail, or virtualization nodes.

# Example checks before reboot
uptime
who
df -h
systemctl --failed
mysqladmin ping 2>/dev/null || true

After reboot, confirm critical services are online:

uname -r
systemctl --failed
ss -tulpn
journalctl -p err -b --no-pager | tail -100

Source References

Administrators should follow their operating system vendor’s official advisory for exact fixed package versions. Useful references:

• CloudLinux GhostLock CVE-2026-43499 advisory
• CloudLinux JanusCape CVE-2026-53359 advisory
• NVD CVE-2026-53359 entry
• SUSE CVE-2026-53359 advisory
• Amazon Linux CVE-2026-43499 advisory