SiteGround a corrigé 5 failles critiques du noyau Linux en 48 heures, sans aucune interruption de service

Ces dernières semaines ont été particulièrement chargées pour toute personne gérant des serveurs Linux en environnement professionnel. Entre fin avril et mi-mai, des chercheurs en sécurité ont divulgué cinq vulnérabilités graves du noyau, chacune offrant à n’importe quel utilisateur connecté un accès root complet à la machine. Plusieurs d’entre elles étaient accompagnées d’un code d’exploitation fonctionnel publié dès le premier jour.

SiteGround a appliqué des correctifs pour chacune d’entre elles sur notre infrastructure d’hébergement sans redémarrer un seul serveur et sans interrompre le service d’un seul client.

Ce que cela aurait signifié pour vos sites

En termes simples : si l’une de ces vulnérabilités avait été exploitée sur un serveur avant d’être corrigée, un attaquant disposant du moindre point d’appui, un plugin WordPress compromis, un mot de passe FTP divulgué, un script vulnérable, aurait pu passer d’un simple compte à faibles privilèges dans un seul site au contrôle total du serveur sous-jacent. De là, le scénario classique : lire les fichiers des autres clients, installer des portes dérobées persistantes, collecter des identifiants, et s’infiltrer plus profondément dans le réseau.

Il ne s’agit pas là de risques théoriques. Des codes d’exploitation publics existaient pour chacune de ces failles. « Copy Fail », en particulier, a été activement utilisé dans la nature quelques jours seulement après sa divulgation.

Ce qui s’est réellement passé

Voici, dans l’ordre approximatif, ce qui a frappé le monde Linux :

29 avril : Copy Fail (CVE-2026-31431) divulgué : Un simple script Python de 732 octets permettait à n’importe quel utilisateur normal de devenir root sur pratiquement toutes les distributions Linux publiées depuis 2017. Aucune manipulation de timing, aucune approximation — juste un bug logique dans le sous-système cryptographique du noyau. La CISA l’a ajouté à sa liste des vulnérabilités activement exploitées en quelques jours.

7 mai : Dirty Frag – faille xfrm/ESP (CVE-2026-43284) divulguée : Une faille dans le code réseau IPsec ESP du noyau permettant à un attaquant d’écrire des données arbitraires dans la copie mémoire de fichiers système en lecture seule. Souvent appelée « Copy Fail 2 ».

7 mai : Dirty Frag – faille RxRPC (la seconde partie de la chaîne) : Un bug associé dans le module réseau RxRPC du noyau. Combiné à la faille xfrm/ESP ci-dessus, il permet à un utilisateur normal d’obtenir un accès root complet.

13 mai : Fragnesia / Copy Fail 3.0 (CVE-2026-46300) divulguée : Le troisième bug en trois semaines, de la même famille que Dirty Frag, également dans le sous-système IPsec du noyau. Un proof-of-concept fonctionnel a été publié le même jour.

14 mai : Faille ssh-keysign / chage pidfd divulguée et corrigée par Linus Torvalds : Un bug d’une nature différente, non pas une élévation de privilèges root, mais permettant à n’importe quel utilisateur non privilégié de lire des fichiers appartenant à root comme /etc/shadow (les hachages de mots de passe) et les clés d’hôte SSH.

Comment nous avons corrigé cela sans interruption de service

Quatre choix que nous avons faits sur le fonctionnement de SiteGround ont rendu cela gérable, et compte tenu de ce qui arrive, ces quatre éléments vont compter encore plus, pas moins.

Nous surveillons en permanence le paysage des menaces. Notre équipe de sécurité surveille les listes de diffusion du noyau, les flux CVE et les canaux de divulgation 24h/24. Nous avons été informés de Copy Fail le jour de sa divulgation, de Dirty Frag le jour de sa publication, et de Fragnesia dans les heures suivant la mise en ligne du proof-of-concept. Rien ne remplace une surveillance en temps réel : lorsque ces informations font la une des médias technologiques grand public, le code d’exploitation est généralement déjà disponible depuis plusieurs jours. À mesure que la découverte assistée par IA accélère le rythme des divulgations, ce type de surveillance constante devient indispensable plutôt qu’optionnel.

Nous avons des ingénieurs d’astreinte 24h/7j. Les correctifs critiques du noyau n’attendent pas les heures de bureau, et nous non plus. Pour chacune de ces vulnérabilités, nous avons développé, testé et déployé des correctifs sur l’ensemble de notre infrastructure en moins de 48 heures après la divulgation publique, généralement bien avant que la plupart des distributions aient publié leurs packages officiels.

Nous utilisons le live patching du noyau. C’est le point le plus important pour vous. Le patching traditionnel du noyau nécessite un redémarrage, ce qui entraîne une interruption de service pour tous les services en cours d’exécution sur la machine. Le live patching applique le correctif au noyau en cours d’exécution en mémoire, de sorte que la vulnérabilité est corrigée sans redémarrer quoi que ce soit. Vos sites web, bases de données, services de messagerie et sessions SSH ont tous continué à fonctionner pendant chacun de ces cycles de patching. Lorsque la fréquence des correctifs augmente, le coût d’un « simple redémarrage du serveur » augmente avec elle. Le live patching est ce qui maintient ce coût à zéro pour vous.

Nous maintenons nos noyaux allégés. Une grande partie de la raison pour laquelle ces bugs sont dangereux est que le code vulnérable est activé par défaut sur la plupart des distributions. Copy Fail se trouvait dans l’interface cryptographique du noyau AF_ALG. Dirty Frag et Fragnesia se trouvaient dans les modules esp4, esp6 et rxrpc, du code réseau IPsec et AFS que la grande majorité des serveurs web n’utilisera jamais de leur vie. Nous ne chargeons pas les modules du noyau dont nous n’avons pas besoin. Cela signifie qu’une partie de la surface d’attaque de ces failles n’existait tout simplement pas sur nos machines au départ, ce qui nous a donné une marge supplémentaire pour appliquer le correctif approprié.

Le facteur IA et pourquoi ce n’est que le début

Un détail dans la divulgation de Copy Fail mérite une attention particulière. Le bug n’a pas été trouvé par un chercheur humain qui aurait passé des semaines à étudier du code. Il a été détecté par un outil d’audit de code alimenté par l’IA (Xint Code) en environ une heure de scan du sous-système cryptographique du noyau Linux. Le même scan a également détecté « d’autres bugs de haute sévérité, encore en divulgation coordonnée » ce qui signifie que d’autres divulgations sont déjà dans le pipeline.

C’est un changement majeur dans la façon dont les vulnérabilités sont découvertes. Pendant des années, le goulot d’étranglement dans la découverte de bugs critiques du noyau était le nombre limité d’experts humains prêts à passer des mois à lire le code source du noyau. Ce goulot d’étranglement a disparu. Les outils d’audit IA peuvent désormais scanner des sous-systèmes entiers à la vitesse d’une machine, et ils trouvent des choses qui se trouvaient dans des noyaux stables depuis près d’une décennie.

Ce que cela signifie concrètement : le rythme des divulgations de vulnérabilités graves va continuer à s’accélérer. Trois failles universelles d’élévation de privilèges root en trois semaines n’est pas une anomalie, c’est un avant-goût. Les cycles de patching réactif qui fonctionnaient quand un bug critique du noyau apparaissait tous les six mois ne fonctionneront pas quand un apparaît toutes les deux semaines. La capacité à détecter, réagir et corriger en heures plutôt qu’en jours n’est plus un avantage, c’est le minimum requis pour rester en sécurité.

Ce qu’il faut retenir

Linux traverse une période particulièrement difficile sur le plan de la sécurité du noyau : trois failles universelles d’élévation de privilèges root en trois semaines n’est pas normal, et le rythme ne ralentit pas. Avec des outils d’audit alimentés par l’IA qui scannent désormais le noyau à des vitesses qu’aucune équipe humaine ne pourrait égaler, nous nous attendons à ce que le taux de découverte de vulnérabilités graves continue de s’accélérer. Les bugs qui se trouvaient silencieusement dans des noyaux stables depuis des années sont en train d’être découverts, un sous-système à la fois.

Ce que nous pouvons promettre, c’est que la façon dont nous avons géré ces failles est la façon dont nous gérons chaque vulnérabilité grave : surveiller tôt, corriger vite, patcher en production et maintenir la surface d’attaque aussi réduite que possible dès le départ. Vos sites restent en ligne. Les failles ne sont pas exploitées. Et à mesure que le rythme s’accélère, cela ne va qu’importer davantage.