{"id":5682,"date":"2026-07-09T13:51:27","date_gmt":"2026-07-09T17:51:27","guid":{"rendered":"https:\/\/underhost.com\/blog\/?p=5682"},"modified":"2026-07-09T14:05:00","modified_gmt":"2026-07-09T18:05:00","slug":"ghostlock-and-januscape-what-self-managed-linux-server-owners-need-to-patch-now","status":"publish","type":"post","link":"https:\/\/underhost.com\/blog\/ghostlock-and-januscape-what-self-managed-linux-server-owners-need-to-patch-now\/","title":{"rendered":"GhostLock and Januscape: What Self-Managed Linux Server Owners Need to Patch Now"},"content":{"rendered":"

<\/p>\n

\n
<\/i> UnderHost Security Advisory<\/div>\n

GhostLock and JanusCape Linux Kernel CVEs: How to Patch Self-Managed Servers<\/h1>\n

A practical patching guide for CloudLinux, AlmaLinux, Rocky Linux, RHEL-compatible systems, Ubuntu, Debian, VPS nodes, dedicated servers, and virtualization hosts.<\/p>\n<\/div>\n

<\/p>\n

Main takeaway:<\/strong>
\nGhostLock CVE-2026-43499 and JanusCape CVE-2026-53359 are Linux kernel vulnerabilities that should be treated as urgent on multi-user servers, shared-hosting systems, VPS nodes, and KVM hypervisors. All UnderHost-owned infrastructure, shared hosting platforms, reseller hosting servers, managed VPS services, and managed dedicated environments have already been patched.<\/strong> This guide is intended for customers operating self-managed<\/strong> VPS or dedicated servers where kernel maintenance is handled by the customer.<\/div>\n
\n
\n

<\/i> UnderHost Managed Services Are Patched<\/h2>\n

UnderHost has completed patching for all infrastructure under our management, including shared hosting, reseller hosting, managed CloudLinux environments, managed VPS services, and managed dedicated servers. No action is required from customers hosted on fully managed UnderHost platforms. If you operate an unmanaged VPS or dedicated server, you are responsible for applying the kernel updates inside your own operating system.<\/p>\n<\/div>\n

<\/i> What Happened?<\/h2>\n

CloudLinux recently published advisories for two serious Linux kernel vulnerabilities: GhostLock CVE-2026-43499<\/strong> and JanusCape CVE-2026-53359<\/strong>. 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.<\/p>\n

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.<\/p>\n

\n
\n

GhostLock CVE-2026-43499<\/h3>\n

A Linux kernel local privilege escalation issue in the futex priority-inheritance path. The practical fix is a patched kernel or a supported livepatch solution such as KernelCare.<\/p>\n<\/div>\n

\n

JanusCape CVE-2026-53359<\/h3>\n

A Linux KVM\/x86 memory-management vulnerability. It is especially important for virtualization hosts and any system exposing \/dev\/kvm<\/code> to local users.<\/p>\n<\/div>\n

\n

Self-Managed Servers<\/h3>\n

If your service is unmanaged, you must update the kernel from your distribution vendor, schedule a reboot if required, and confirm the new kernel is actually running.<\/p>\n<\/div>\n<\/div>\n

<\/i> Who Needs to Take Action?<\/h2>\n

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.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Service Type<\/th>\nAction Required?<\/th>\nWhat To Do<\/th>\n<\/tr>\n<\/thead>\n
UnderHost Shared Hosting<\/strong><\/td>\nNo customer action<\/td>\nUnderHost has patched the managed platform.<\/td>\n<\/tr>\n
UnderHost Reseller Hosting<\/strong><\/td>\nNo customer action<\/td>\nKernel maintenance is handled by UnderHost.<\/td>\n<\/tr>\n
Managed VPS or Managed Dedicated Server<\/strong><\/td>\nUsually no action<\/td>\nUnderHost has applied available patches. Contact support if you need confirmation for a specific server.<\/td>\n<\/tr>\n
Self-Managed VPS<\/strong><\/td>\nYes<\/td>\nUpdate the OS kernel, reboot if needed, and verify the running kernel.<\/td>\n<\/tr>\n
Self-Managed Dedicated Server or KVM Host<\/strong><\/td>\nYes, urgent<\/td>\nPatch the kernel and review KVM exposure, especially \/dev\/kvm<\/code>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

<\/i> Check Your Current Kernel<\/h2>\n

Before patching, record your current kernel. After patching and rebooting, run the same command again to confirm the new kernel is active.<\/p>\n

uname -r\r\ncat \/etc\/os-release<\/code><\/pre>\n
For KernelCare users, verify CVE-level patch status with:<\/p>\n
kcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53359|CVE-2026-46113'<\/code><\/pre>\n
<\/i> Quick Patch Guide by Distribution<\/h2>\n
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.<\/p>\n
CloudLinux 7, 7h, 8, 9 and 10<\/h3>\n
CloudLinux customers should follow the official CloudLinux advisory for the exact fixed kernel stream. On stable channels, use the normal package manager first:<\/p>\n
# CloudLinux 7 \/ 7h \/ 8\r\nyum clean all\r\nyum update 'kernel*'\r\nreboot\r\n\r\n# CloudLinux 9 \/ 10\r\ndnf clean all\r\ndnf update 'kernel*'\r\nreboot<\/code><\/pre>\n
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.<\/p>\n
AlmaLinux, Rocky Linux, RHEL-Compatible Systems<\/h3>\n
dnf clean all\r\ndnf update kernel kernel-core kernel-modules kernel-modules-core\r\nreboot<\/code><\/pre>\n
After reboot:<\/p>\n
uname -r\r\ndnf updateinfo list security --available<\/code><\/pre>\n
Ubuntu 22.04, Ubuntu 24.04 and Debian<\/h3>\n
apt update\r\napt full-upgrade\r\nreboot<\/code><\/pre>\n
After reboot:<\/p>\n
uname -r\r\napt list --upgradable<\/code><\/pre>\n
KernelCare Livepatching<\/h3>\n
If you use KernelCare, apply available livepatches and verify the CVE-level patch list:<\/p>\n
kcarectl --update\r\nkcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53359|CVE-2026-46113'<\/code><\/pre>\n
If no livepatch exists yet for your kernel stream, install the vendor kernel update and reboot during a maintenance window.<\/p>\n
<\/i> JanusCape: Review KVM Exposure<\/h2>\n
JanusCape is particularly important for KVM hypervisors and systems exposing \/dev\/kvm<\/code>. 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.<\/p>\n
\n
<\/i> Important<\/h3>\n
Do not unload or block KVM modules on a server that actively runs virtual machines. Doing so can disrupt virtualization services. For hypervisors, the complete fix is a patched kernel or supported livepatch.<\/p>\n<\/div>\n
Check whether KVM is loaded:<\/p>\n
lsmod | grep kvm\r\nls -l \/dev\/kvm<\/code><\/pre>\n
If the server does not run virtual machines, you may unload KVM modules temporarily:<\/p>\n
# Intel hosts\r\nmodprobe -r kvm_intel kvm\r\n\r\n# AMD hosts\r\nmodprobe -r kvm_amd kvm\r\n\r\n# Verify\r\nlsmod | grep kvm<\/code><\/pre>\n
To prevent KVM from loading on boot on non-virtualization servers:<\/p>\n
cat > \/etc\/modprobe.d\/disable-kvm.conf <<'EOF'\r\ninstall kvm_intel \/bin\/false\r\ninstall kvm_amd \/bin\/false\r\nEOF<\/code><\/pre>\n
If the server is a KVM hypervisor, do not disable KVM. You may restrict local access to \/dev\/kvm<\/code>, but this does not protect against a malicious guest-to-host path:<\/p>\n
echo 'KERNEL==\"kvm\", GROUP=\"kvm\", MODE=\"0660\"' > \/etc\/udev\/rules.d\/65-kvm.rules\r\nudevadm control --reload-rules\r\nudevadm trigger \/dev\/kvm\r\nls -l \/dev\/kvm<\/code><\/pre>\n
<\/i> Recommended Hardening Checklist<\/h2>\n