A new Linux kernel vulnerability known as SSH-keysign-pwn (tracked as CVE-2026-46333) was publicly disclosed on 14 May 2026. 

This vulnerability allows an unprivileged local user to read any files owned by root. A working exploit is already publicly available.

Risk Level: When This Vulnerability Is Dangerous

This vulnerability can only be exploited by someone who is able to run local commands on your virtual machine. This means the real‑world risk depends on how your system is exposed and who can access it.

High‑Risk Scenarios (Immediate Action Required)

Your system is at high risk if any of the following are true:

• The VM is externally accessible (SSH open to the internet, public endpoints, jump hosts, etc.).
• You have local users who are not already trusted with root privileges.

In these cases, an attacker who gains any local foothold can escalate to root instantly.

Low‑Risk Scenarios (Not Urgent, but Still Recommended)

The urgency is lower if:

• Your VM is not externally exposed,
• All users already have root access

In these situations, the vulnerability is still present, but the practical risk of exploitation is minimal because no untrusted user can execute local commands.

Interim fix

This is valid for all EWC supported OSes: Rocky 8, Rocky9, Ubuntu22.04, Ubuntu24.04

sudo sysctl -w kernel.yama.ptrace_scope=2

Running the command above effectively breaks unprivileged process tracing with tools such as gdb -p or strace. Those would still work as root. To disable process debug attachment completely, including for root),  you may increase the scope with:

sudo sysctl -w kernel.yama.ptrace_scope=3

A new Linux kernel vulnerability known as Dirty Frag was publicly disclosed on 7 May 2026. The flaw affects the IPsec ESP and rxrpc in-place decryption fast paths and is closely related to the same subsystem area impacted by the recent Copy Fail vulnerability.

Dirty Frag allows an unprivileged local user to gain immediate root access on all major Linux distributions. A working exploit is already publicly available.

The Dirty Frag exploit works by corrupting page-cache pages of sensitive files (such as /etc/passwd or /usr/bin/su).  (reference: AlmaLinux OS - Forever-Free Enterprise-Grade Operating System)

esp4 / esp6 are the kernel-side ESP transforms used by IPsec. Disabling them breaks IPsec tunnels that rely on the kernel data path on the affected machine. Do not apply this mitigation on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels. rxrpc is the AF_RXRPC transport used almost exclusively by AFS clients and is not present on typical web-hosting servers. (reference: Dirty Frag [CVE Pending]: Mitigation and Kernel Update on CloudLinux)

What is its relationship with the "Copy Fail" vulnerability?

Copy Fail was the motivation for starting researching new vulnerabilities. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is triggered regardless of whether the algif_aead module is available. In other words, even on systems where the publicly known Copy Fail mitigation (algif_aead blacklist) is applied, your Linux is still vulnerable to Dirty Frag. (reference V4bel/dirtyfrag)

Risk Level: When This Vulnerability Is Dangerous

This vulnerability can only be exploited by someone who is able to run local commands on your virtual machine. This means the real‑world risk depends on how your system is exposed and who can access it.

High‑Risk Scenarios (Immediate Action Required)

Your system is at high risk if any of the following are true:

• The VM is externally accessible (SSH open to the internet, public endpoints, jump hosts, etc.).
• You have local users who are not already trusted with root privileges.

In these cases, an attacker who gains any local foothold can escalate to root instantly.

Low‑Risk Scenarios (Not Urgent, but Still Recommended)

The urgency is lower if:

• Your VM is not externally exposed,
• All users already have root access

In these situations, the vulnerability is still present, but the practical risk of exploitation is minimal because no untrusted user can execute local commands.

Interim fix

This is valid for all EWC supported OSes: Rocky 8, Rocky9, Ubuntu22.04, Ubuntu24.04

No output is expected.

EUMETSAT Managed Kubernetes

CLI - kubectl

pre-requisite: have a machine with kubectl installed and your kubeconfig in ~/.kube/ folder

Update each MachineDeployment that should use the custom profile:

kubectl --context <user-cluster-context> annotate machinedeployment -n kube-system <machine-deployment-name> \ k8c.io/operating-system-profile=osp-ubuntu-ewc-1105202601 \ --overwrite

Changing the OSP annotation does not automatically rotate existing machines. Trigger a rolling restart so the MachineDeployment creates new machines with the new profile:

forceRestartAnnotations="{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"forceRestart\":\"$(date +%s)\"}}}}}" 
kubectl --context <user-cluster-context> patch machinedeployment -n kube-system <machine-deployment-name> \ --type=merge \ -p "$forceRestartAnnotations"

Watch the rollout:

kubectl --context <user-cluster-context> get machinedeployments,machines -n kube-system -o wide kubectl --context <user-cluster-context> get nodes -o wide

KKP UI

On the KKP UI, the process would be similar via ClickOps, and would need to be done for each intended node pool of each user cluster.

Once logged in go to Resources - > Clusters → Select your cluster. In the Machine Deployment section click the edit button.

In the new window open, scroll down until you find the Operating System Profile and change to the new value: osp-ubuntu-custom-1105202601. And then hit Save Changes.

After that, in the same Machine Deployment section, you can use the Refresh button to refresh the node pool.