11

What Hosting Administrators Need to Know

A Linux server can run websites smoothly and still have a serious flaw in its operating system. That’s why hosting providers need to pay attention to kernel vulnerabilities, even when their applications and customer accounts appear to work normally. One recent example is ZDI-CAN-33367, a Linux kernel vulnerability that allows a local, unprivileged user to change file contents stored in memory under specific conditions. The affected file may belong to another user or even root, although the attacker normally can read it but not modify it.

The vulnerability can create a serious problem for hosting providers that run multiple customer accounts on the same server. If an attacker gains local access, they may use the flaw to increase their privileges and affect other parts of the system.

What steps should you take when you manage Linux servers?

First, check your operating systems and running kernels. Review the relevant vendor advisories and confirm whether your servers have received the required fix. This article explains how to assess your exposure and plan the next steps without disrupting customer services unnecessarily, referencing the ZDI-CAN-33367 Linux vulnerability where relevant.

What Is ZDI-CAN-33367, and Why Does It Matter?

ZDI-CAN-33367 affects the Linux kernel, the core component that connects the operating system to the server’s hardware and manages resources such as memory and processes.

The vulnerability involves something called the page cache. Linux keeps recently accessed file data in memory so that it can retrieve that data faster instead of reading it from the disk every time.

Under specific conditions, ZDI-CAN-33367 allows a local user to alter file data in this memory cache, even when the user cannot normally write to the original file.

Here’s the important distinction: the file stored on disk may remain unchanged, but applications reading the affected cached data can still encounter altered contents. That makes the issue more than a simple file-permission problem.

The vulnerability has a reported severity score of CVSS 7.8 and is classified as High by the Zero Day Initiative. It also has a public proof of concept, which makes timely assessment especially important. No CVE identifier had been assigned in the AlmaLinux advisory as of October 28, 2026. AlmaLinux OS+1

For hosting providers, the risk deserves attention because a single server may run dozens or hundreds of customer websites and services.

Pay particular attention to:

• Shared hosting servers: Multiple customer accounts depend on the same operating system.
• VPS infrastructure: Local users or workloads may have opportunities to execute code.
• Container hosts: Containers share the host kernel, so a kernel-level flaw can affect the wider environment.
• Build servers and automated workloads: Untrusted code may run during testing, deployment, or other automated tasks.

The actual risk depends on the operating system, kernel build, configuration, and available attack paths. Don’t assume that every Linux distribution or server is affected in the same way.

Does ZDI-CAN-33367 Affect AlmaLinux 8, 9, and 10?

Yes. AlmaLinux confirmed that its versions 8, 9, and 10 contain the vulnerable code.

Administrators also need to know: AlmaLinux announced on October 28, 2026, that patched kernels are available through its regular production repositories. Administrators no longer need to rely on the testing repository to obtain these fixes. AlmaLinux OS

The patched kernel versions listed in the AlmaLinux advisory are:

Install the listed version or a later applicable version. Before updating production systems, confirm the current instructions in the official AlmaLinux advisory for ZDI-CAN-33367. The advisory includes the updated kernel versions and remediation instructions. AlmaLinux OS

If you manage CloudLinux, Debian, Ubuntu, RHEL, or another distribution, check that vendor’s own advisory instead. A fix released for one distribution does not automatically confirm another distribution’s patch status.

How to Check Whether Your Linux Server Is Affected

There’s no need to change anything to begin. First, find out which operating system and kernel your server currently runs.

Step 1: Check the operating system

Run:

cat /etc/os-release

This command displays the Linux distribution and release installed on the server.

Record the results for every server you manage, especially if your hosting environment includes several Linux distributions or different operating system releases.

Step 2: Check the running kernel

Next, run: uname -r

This command displays the kernel version currently running on the server.

Compare the output with the relevant vendor advisory and the applicable patched version.

Keep in mind that Linux distributions sometimes include fixes in their own kernel packages without changing the version number in the way you might expect. A version string alone may not tell you whether the fix has been applied.

For an accurate Linux server vulnerability assessment, check both the running kernel and the vendor’s package information.

Step 3: Review local access and workload exposure

Now look at how each server operates.

Ask yourself:

• Can customers or developers execute code locally?
• Do automated jobs run code from sources you do not fully trust?
• Does the server host multiple customer accounts or containers?
• Could a compromised website or account provide a route to local access?

These questions help you prioritize systems that may offer a more realistic attack path.

For a repeatable process across other newly reported flaws, use the same approach to assess whether a newly published CVE affects your servers. This helps your team decide which systems need attention before scheduling maintenance.

What’s the quick checklist for hosting providers?

If you manage several servers, it’s easy to lose track of which systems need attention. A simple inventory helps you keep the assessment organized and makes future Linux kernel patch management easier.

Use this checklist to track your progress:

• List all Linux servers, including shared hosting, VPS, dedicated servers, and cloud instances.
• Record each operating system and release.
• Check running kernel versions against the applicable vendor guidance.
• Identify servers where customers, developers, or automated workloads can execute local code.
• Confirm patch availability in the appropriate production repository.
• Prioritize systems based on exposure, workload sensitivity, and vendor recommendations.
• Schedule updates and reboots with a recovery plan.
• Verify the running kernel after maintenance.
• After rebooting, check websites, databases, and other critical services. Before a planned reboot, collect kernel logs before rebooting a production server when you need to preserve evidence of an existing system issue.
• Record completed fixes, outstanding updates, and temporary mitigations.

A good list pays off again next time. When the next kernel bug lands, you’ll know in minutes which servers matter. Our KVM host patch checklist uses a similar approach for virtualization hosts.

How Hosting Providers Can Stay Prepared

ZDI-CAN-33367 reminds us that keeping a hosting environment running smoothly takes more than updating websites and applications. The Linux kernel needs regular attention, too.

Hosting providers can reduce their exposure by maintaining an accurate server inventory, reviewing vendor advisories, prioritizing affected systems, and verifying every update after installation.

The key is to make vulnerability response a repeatable process instead of treating each new disclosure as an isolated emergency.

Need a hand?

Not sure which of your servers need attention? SupportPRO’s engineers can review your Linux environment, find the right vendor guidance, apply updates and check that everything runs after maintenance.

• Want a quick look? Start with a free server checkup.
• Need a one-time fix? Book Hourly Administration.
• Want patching handled every month? Explore our Server Administration service.