A serious Linux kernel vulnerability has been publicly disclosed:

http://www.openwall.com/lists/oss-security/2026/05/15/9

This issue has been allocated CVE-2026-46333. It targets kernel setuid binaries via kernel ptrace system calls. It affects all servers running recent Linux kernels.

In practical terms, if an actor can run code inside a vulnerable VPS, for example through a compromised website, shell account, or application, this bug may allow them to have read access to files owned by the root user.

Mitigations

Where a server is using a modular kernel, you should also check with the distributor as soon as possible for updates and additional mitigation steps.

On RimuHosting VPSs, it is possible to substantially mitigate this attack by preventing user accounts from accessing ptrace functonality. Running the following command will block those until the next reboot.

sysctl -w kernel.user_ptrace=0

This temporary fix may affect anything that depend on setuid binaries, uncluding sudo and su commands.

Another mitigation may be to remove the setuid bit from those affected binaries. This would also result in loss of the specific functionaility that provides and should be carefully tracked.

Fixed kernels

We have released patched kernels on all our hosts. A reboot will be required to use those. VPSs should be restarted from our control panel.

• Control panel restart: https://rimuhosting.com/cp/vps/restart.jsp
• Kernel selection page: https://rimuhosting.com/cp/vps/kernel.jsp

You can verify which kernel your VM is running using the command 'uname -r', it will look something like this...:

6.18.0-really31-rh-20260515150258.xenU.x86_64

Patched kernels will show a build date of 20260515 or newer. Those digits are the date: 2026 May 15th.

Ongoing work

We are continuing to review this vulnerability, and will be providing updates and further recomendations here. Please subscribe to this notice for updates.

Fri, 15 May 2026 00:38 AM UTC: Added namespace mitigation instructions below.

---

A serious Linux kernel vulnerability has been publicly disclosed:

https://github.com/v12-security/pocs/tree/main/fragnesia

This issue has been allocated CVE-2026-46300, also known as Fragnesia. This targets the same components as the recently disclosed Dirtyfrag, but is a different vulnerability.

• It does *not* affect our latest 4.14 kernels
• Affects all servers running recent Linux kernels
• including servers that have already been rebooted with a kernel patched for the Dirtfrag vulnerability.

In practical terms, if an actor can run code inside a vulnerable VPS, for example through a compromised website, shell account, or application, this bug may allow them to take full control of that VPS.

Mitigations

Where a server is using a modular kernel, you should also check with the distributor as soon as possible for updates and additional mitigation steps.

On RimuHosting VPSs, it is possible to substantially mitigate this attack by preventing user accounts from creating their own namespaces. Running the following command will block those until the next reboot.

sysctl -w user.max_user_namespaces=0

This may impact the normal operation of containers and services that depend on namespaces, including in some cases ipsec tunnels.

The exploit modifies the memory used by legitimate system binaries (the public PoC overwrites /usr/bin/su in the page cache as part of gaining root), so applying the mitigation alone is not enough on systems that may have been targeted before it was put place. After mitigating, as root run the following command to drop the page cache and force a reload from disk:

echo 3 > /proc/sys/vm/drop_caches

On busy systems the pagc cache drop may cause some short term slowness until kernel caches fill up again, but is otherwise safe to do at any time.

Ongoing work

We are working on releasing patched kernels for our VPS customers. Kernel developers are still finalising a more comprehensive solution to prevent this class of issues.

We are continuing to review solutions for this vulnerability, and will be providing updates and further recomendations here. Please subscribe to this notice for updates.

A security issue has been identified in the cPanel software affecting all currently supported versions relating to various authentication paths.

Note this is an updated fix of a previouly notified vulnerability and applies to all CPanel users who have not run updates within the last 12 hours. This notice also covers all other recently reported vulnerabilities in CPanel/WHM

Please update as soon as possible. You can run the following commands to retrieve the patched version.

/scripts/upcp --force
/scripts/restartsrv_cpsrvd --hard

More detailed information is avilable on the below notice links

Should you need assistance with this, please pop in a support ticket.

References:
https://support.cpanel.net/hc/en-us/articles/40437020299927-Security-CVE-2026-29205-cPanel-WHM-WP2-Security-Update-May-13-2026

Please subscribe to this notice for updates. Should you need assistance, please pop in a support ticket.

Wed, 13 May 2026 21:24 PM UTC: Planned VPS restarts are completed. No further activity pending.

Mon, 11 May 2026 23:40 PM UTC: Because this is a serious privilege escalation issue and public exploit code is available. For VPSs running one of our LTS kernels that have not already been restarted, We will do so from May 12th 00:00 UTC.

The restart should be a normal VM reboot. Your VM will be unavailable while it restarts.

If you want to control the timing, please restart your VM before then.

If you do not want us to restart your VM, please open a support ticket and ask us to add this tag to your server notes:

#noautokernelfix

Please note that opting out means your VM may continue running a vulnerable kernel until you restart it yourself with a safe kernel.

---

Mon, 11 May 2026 22:44 PM UTC: Updated kernels for the 4.14 series are now on our hosts. These do not have an upstream patch. Instead the issue has been mitigated by disabling affected kernel components. Servers on one of our 4.14 kernels that use ESP packet functionality (ie for ipsec tunnels), should try one of our newer LTS kernels.

Fixed 4.14 kernels will show a build date as described below, of 20260511 or newer.

---

A serious Linux kernel vulnerability has been publicly disclosed:

https://github.com/V4bel/dirtyfrag

This issue has been allocated CVE-2026-43284, also known as Dirtyfrag.

The issue affects most Linux kernels released in the last decade. It allows a local unprivileged user or process to gain root privileges. In practical terms, if an attacker has access to run code inside a VM, for example through a compromised website, shell account, or application, this bug may allow them to take full control of that VM.

Where a server is using a modular kernel, you should check with the distributor as soon as possible for update and mitigation steps.

We have released patched VM kernels to our hosts. A reboot will be required to use that. We recomend you restart your server as soon as possible to adopt an updated kernel. They should be restarted from our control panel.

• Control panel restart: https://rimuhosting.com/cp/vps/restart.jsp
• Kernel selection page: https://rimuhosting.com/cp/vps/kernel.jsp

You can verify which kernel your VM is running using the command 'uname -r', it will look something like this...:

6.12.0-really87-rh-20260508114817.xenU.x86_64

Patched kernels will show a build date of 20260508 or newer. Those digits are the date: 2026 May 8th.

We are continuing to assess this vulnerability and will be providing updates and further recomendations here. Please subscribe to this notice for updates.

Update at Sat, 2 May 2026 22:33 PM UTC: VMs are now running on new kernels.  We worked through a few restart issues with a few customers.  Now would be a good time to check your services are all running as expected.  Let us know if we can assist with anything!

A serious Linux kernel vulnerability has been publicly disclosed:

https://copy.fail/

This issue is tracked as CVE-2026-31431, also known as Copy Fail.

It affects many Linux kernels shipped from 2017 onwards. The issue allows a local unprivileged user or process to gain root privileges. In practical terms, if an attacker already has access to run code inside a VM, for example through a compromised website, shell account, or application, this bug may allow them to take full control of that VM.

We have pushed patched kernels to our VM hosts.

No action is required, but an urgent restart is strongly recommended

We will be restarting affected customer VMs with the patched kernel.  No action is required by you.  However, it is best if you can switch to the patched kernel as soon as possible rather than waiting for us.

Switching to the patched kernel

Your VM needs to be restarted to boot into the patched kernel.

You can restart it yourself now using one of these methods:

• Control panel restart:
  https://rimuhosting.com/cp/vps/restart.jsp
• Kernel selection page (good option if you wished to change to a new kernel major version):
  https://rimuhosting.com/cp/vps/kernel.jsp
• Command line, as root:
  reboot

After the restart, your VM should be running the patched kernel.

You can check with:

uname -a

For example a fixed kernel looks like:

Linux example.com 6.6.0-really137-rh-20260430214815.xenU.x86_64 #1 SMP Thu Apr 30 22:06:25 UTC 2026 x86_64 GNU/Linux

The kernel version should show a build date of 20260430 or newer. Those digits are the date: 30 April 2026.

Your VM will be restarted

Because this is a serious privilege escalation issue and public exploit code is available, we will restart VMs that are still running an older kernel.

We will start those restarts from:

• Friday 1 May, 22:00 UTC
• Friday 1 May, 17:00 Dallas time
• Saturday 2 May, 10:00 NZST

The restart should be a normal VM reboot. Your VM will be unavailable while it restarts.

We will not restart servers already on a patched kernel.

If you want to control the timing, please restart your VM before then.

If you do not want us to restart your VM, please open a support ticket and ask us to add this tag to your server notes:

#noautokernelfix

Please note that opting out means your VM may continue running a vulnerable kernel until you restart it yourself.

Notes

• VPSs running our 4.14 and older kernels are not be vulnerable to this attack (pre 2017).
• VPSs on our 4.19 or 5.4 kernels can typically be reliably switched on our kernel page to our 5.10 or newer kernels.
• The kernel page will tell you which kernel will be used after the restart and which kernel it was booted on.  For example if it says "Booted on 5.10.0-really251-rh-20260304013052.xenU.x86_64" then that date string "20260304" means the kernel is from March and predates the fixed kernel (20260430 or newer).
• VPSs using a custom kernel (ie via grub) should check with their kernel provider and update as soon as possible.
• As usual please subscribe to this notice to receive updates on the situation.