Several recent Linux kernel vulnerabilities have required a swift response from infrastructure operators.
Among them, Copy Fail and Dirty Frag drew attention because they involve local privilege escalation scenarios. Copy Fail is tracked as CVE-2026-31431.
Dirty Frag covers two distinct vulnerabilities, CVE-2026-43284 and CVE-2026-43500, tied to Linux kernel components.
At Clever Cloud, we treated these vulnerabilities as critical infrastructure matters. Our goal was twofold: quickly shrink the exposure window, then sustainably improve our kernel selection and deployment process.
This article reviews our approach, the decisions made, and the changes brought to our operations pipeline
Why these vulnerabilities called for a fast response
Copy Fail and Dirty Frag belong to the family of local privilege escalation vulnerabilities. In this type of scenario, an attacker must already be able to execute code locally, but can then attempt to gain higher privileges on the affected machine.
Dirty Frag rests on two Linux kernel flaws.
They notably affect modules related to ESP, used by IPsec, and to RxRPC. On a cloud platform, this type of vulnerability calls for a rapid analysis. The risk is not limited to a single isolated machine.
Scenarios tied to shared environments, containerized workloads, and isolation mechanisms must also be assessed.
What we verified
We analyzed the potential impact of these vulnerabilities on our environments. This step is not just about reading security advisories. It also involves verifying whether a theoretical scenario can become relevant in our operating context.
In the case of Copy Fail, the flaw came under embargo together with its patch. We published a new system image with the patch applied in the days that followed.
Our customers’ applications were redeployed shortly after.
In the case of Dirty Frag, our internal analyses confirmed that these vulnerabilities had to be taken seriously. ESP modules are enabled in our kernels to support some specific customer needs. Fortunately, RxRPC-related modules are not present in our environment, as they serve no purpose for our usage.
We do not detail the technical steps of the exploitation here, since the purpose of this article is to inform our customers, not to publish a reproducible procedure.
This validation confirmed the operational decision: handle the matter immediately, reduce the exposed surface, then force the necessary redeployments.
| Period | Action |
|---|---|
| April 30, 2026 | Fast rollout of initial kernel mitigations |
| May 7, 2026 | Update of kernels affected by the new vulnerabilities |
| May 8, 2026 | Progressive workload redeployment to apply the patches |
| May 11, 2026 | Production release of kernel management integration into the orchestration pipeline |
Our operational response
Rolling out immediate measures
We first applied quick measures on the affected kernels. In the case of Dirty Frag, the publicly recommended measures focus in particular on the kernel components related to ESP and RxRPC.
On Clever Cloud’s side, the goal was clear: reduce the identified exposed surfaces and shrink the exposure window without waiting for a standard maintenance cycle.
Redeploying the affected workloads
A kernel update only matters if the affected systems actually restart on a patched environment. We therefore launched a progressive redeployment of applications, then handled the cases that blocked this redeployment.
This phase matters. On a managed platform, the fix is not limited to producing an image or compiling a kernel. The execution chain must also actually use the expected version.
Improving the process along the way
We also took advantage of this sequence to replace a temporary mechanism with a cleaner integration into our orchestration pipeline.
Concretely, the kernel choice is now passed more explicitly through our internal pipeline, all the way to Supernova, our hypervisor agent. This evolution replaces the stiffer workaround put in place in the heat of the moment.
That is the central point of this intervention: fix fast, then make the fix more reliable for future operations.
What this changes for Clever Cloud customers
For customers, the expected effect is simple: reduce exposure without any manual action on their part whenever the platform can handle the redeployment.
Clever Cloud runs an architecture that relies in particular on isolation through virtualization. This approach is documented on our security pages and in our technical content on running containers inside virtual machines. It does not eliminate every risk, but it limits certain lateral movement scenarios compared to models where multiple workloads share the same execution environment directly.
We avoid, however, presenting this isolation as an absolute guarantee. A kernel vulnerability must always be taken seriously.
That is why we combined mitigation, redeployment, and improvement of our operations pipeline.
What we take away
This sequence confirms three principles.
First, a kernel vulnerability must be analyzed in its actual operating context. A public alert is not enough. We need to understand whether the conditions required for exploitation can exist on the platform.
Second, reaction speed matters. The Copy Fail and Dirty Frag vulnerabilities were disclosed publicly within a few days of each other, with analyses published by several players in the Linux and cloud ecosystem.
Finally, a useful security response must not only fix the problem of the moment. It must also improve the system that will handle the next incident.
That is what we did here: handled the vulnerabilities, shrank the exposure window, and strengthened our kernel management process.
Q&A
What is a local kernel vulnerability?
A local kernel vulnerability is a flaw that already requires execution capability on the affected machine. It can then allow gaining higher privileges, such as root, if the kernel is vulnerable.
Why do these flaws concern cloud platforms?
Cloud platforms run many workloads with isolation mechanisms. A kernel flaw can become critical if it allows crossing certain boundaries between processes, containers, or execution environments.
Are Dirty Frag and Copy Fail the same vulnerability?
No. Copy Fail is tracked as CVE-2026-31431. Dirty Frag covers CVE-2026-43284 and CVE-2026-43500. These vulnerabilities are close in impact, but they are distinct.
What action is required from Clever Cloud customers?
No general action is required from customers for environments handled by the platform. The automation brought by Clever Cloud allowed everything to be updated without action needed. Specific cases are tracked individually.