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.

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.

Dans cet épisode finistérien, nos quatre fantastiques reviennent sur le Very Tech Trip d'OVH, parlent du Manifest V3, de HAProxy, d'une grosse attaque DDos sur Cloudflare, d'Apple qui met la main sur les 1er lots de puces 3nm, de performance, de storytelling et de podman avant de finir en musique.

Seconde partie du double épisode enregistré le 24 février. Dans des conditions extrêmes où le son sature un poil malgré les efforts de rattrapage héroïques de notre monteur, toutes nos excuses, renouvelées.

Avec la participation de @GwinizDu, @PierreZ, @nd4pa et @raclepoulpe

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Timecode & Liens

00:16:00 : Intro et présentation des invités
00:01:22 : retour sur le VeryTechTrip d’OVH
00:09:32 : de la critique du Manifest V3, Google a-t-il encore une âme ?
https://adguard.com/en/blog/firefox-manifestv3-chrome-adblocking.html

00:20:56 : CVE HAProxy
https://www.haproxy.com/blog/february-2023-header-parser-fixed/

00:21:56 : OpenSSL vs Quick
https://github.com/haproxy/haproxy/issues/680#issuecomment-1433118828
OpenSSL not wanting to provide Quick API
Wikipedia is not IETF
https://github.com/haproxy/haproxy/issues/680l

00:27:09 : Grosse attaque DDoS sur Cloudflare
https://blog.cloudflare.com/cloudflare-mitigates-record-breaking-71-million-request-per-second-ddos-attack/

00:33:14 : Apple achète l'intégralité du premier batch de puces 3nm chez TSMC pour l'iphone 15 max et le mac M3
https://www.macrumors.com/2023/02/22/apple-secures-tsmc-3nm-chips/

00:45:08 : Puzzling Postgres: a story of solving an unreproducible performance issue https://medium.com/engineering-at-birdie/puzzling-postgres-a-story-of-solving-an-unreproducible-performance-issue-778075ed7998
Response times were expected to be in single-digit-milliseconds, but I was observing it to be in minutes.
Query qui brûle du CPU
Explain analyze en 9 microsecond et query plan normal
Change la query pour en trouver une qui prends 28s
Valeur du timestamp WHERE qui détruit les perfs
Prepared statements query plan cached
Postgres’ query planner has a bug in its cost estimation.

00:48:07 : Du storytelling et du théâtre dans vos présentations
https://github.com/raclepoulpe/VoyageDuHerosDelIT

00:53:17 : systemd + podman = ❤️
https://www.redhat.com/sysadmin/quadlet-podman

00:56:20 : Musique de fin THYLACINE - Anatolia
https://www.youtube.com/watch?v=By5kBezU_T0