Les CVE du noyau Linux s’envolent : comment Host.it patche à chaud sans redémarrer les serveurs

Deux phénomènes se sont additionnés, et il faut les distinguer. Le premier est administratif. Depuis février 2024 le noyau Linux est une CVE Numbering Authority : beaucoup d’issues qui vivaient sur des listes ou dans des commits sortent désormais avec un ID public. Le catalogue s’est allongé même sans épidémie soudaine de nouveaux bugs.

Le second est technique, et c’est lui qui a changé le rythme ces derniers mois. Le fuzzing (syzkaller et al.) tourne depuis des années. Ce qui a changé, c’est l’assistance de l’IA dans la chasse : des agents qui explorent des surfaces, réduisent les faux positifs, aident à écrire des reproducteurs et ferment la boucle jusqu’à la publication. Plus d’yeux automatiques, plus de CVE. « Grâce » à l’IA, au sens strict : plus de vulnérabilités découvertes et communiquées, pas un noyau soudain plus fragile.

Ce qu’un CVE noyau n’est pas (et ce qu’il est)

Un CVE noyau n’est pas un plugin à cliquer dans un tableau de bord. C’est un identifiant sur un défaut du système d’exploitation sous WordPress, Joomla, la boutique, le mail. La gravité se lit au cas par cas : tous les ID ne sont pas exploitables en hébergement mutualisé, et tous n’exigent pas un reboot immédiat. Ce qui a changé, c’est la cadence : le backlog de correctifs à évaluer n’est plus un événement mensuel.

La surface que voit l’agence, c’est CMS, plugins, PHP, certificats. Celle qu’un attaquant peut utiliser inclut aussi le noyau, les drivers, les namespaces, le réseau. Vous n’avez pas à devenir des hackers noyau. Vous devez savoir qui patche quoi, en combien de temps, et avec quel impact sur l’uptime.

Trois plans, trois responsabilités

• Application. Core, thèmes, plugins : votre métier, ou un forfait que vous vendez. Staging, sauvegardes, fenêtre de vérification.
• Système. Noyau, libc, hyperviseur : métier de l’hébergeur. S’il ne patche qu’en redémarrant, chaque CVE sérieux devient une coupure planifiée.
• Contrat client. Qui répond si la boutique tombe pendant les soldes ? Si ce n’est pas écrit, vous payez en réputation.

Pour une agence avec cinquante ou deux cents sites, le noyau est invisible tant qu’il fonctionne. Il devient visible la nuit où dix clients reçoivent un timeout en même temps. Ce n’est pas de la « sécurité abstraite » : c’est la continuité du service que vous avez vendu.

Le correctif classique du noyau est simple à expliquer et cher à vivre : on installe, on redémarre, on attend que les services remontent, on vérifie PHP, la base et la file mail. Sur un serveur, c’est une fenêtre. Sur un parc, c’est un calendrier d’interruptions.

Ce que paie le client (et ce que vous payez)

• Des minutes de site down. Un e-commerce en campagne pubs ne distingue pas « maintenance noyau » d’« hébergement peu fiable ».
• Des fenêtres de nuit. Si chaque avis exige un reboot, les nuits se multiplient. L’équipe interne ou le fournisseur doivent les couvrir.
• Des tickets en rafale. Même un redémarrage propre produit des alertes de monitoring et des appels. Ça coûte plus que le correctif.

L’alternative n’est pas d’ignorer les CVE. C’est de séparer la correction du reboot : appliquer le correctif en mémoire quand c’est possible, et garder le redémarrage pour les cas où il faut un nouveau noyau, pas pour chaque ID publié un lundi matin.

Chez Host.it la stratégie est conçue pour l’uptime des Clients, pas pour le confort du calendrier interne. Quand un avis noyau pertinent arrive, nous appliquons la correction à chaud (live / hot patch) : le code vulnérable en mémoire est remplacé sans cycle d’arrêt. Les sites restent joignables. Ce n’est pas de la magie et ça n’efface pas tous les reboots de la vie d’un serveur : ça supprime le besoin de redémarrer en continu juste pour suivre le rythme des CVE.

Ce que nous faisons, concrètement

• Évaluation. Tous les CVE noyau n’ont pas le même impact sur notre stack. Nous priorisons ceux qui touchent l’exposition réelle des services.
• Correctif en temps réel. Là où le live patching couvre le défaut, la correction entre en production sans downtime d’hyperviseur ni de machine.
• Reboot seulement si besoin. Un nouveau noyau, une dépendance que le patch à chaud ne couvre pas, une fenêtre planifiée : le redémarrage reste un outil, pas la réponse par défaut.
• Observabilité. Nous surveillons que les services restent sains après le correctif. L’uptime, nous le mesurons, nous ne le déclarons pas sur une slide : voir transparence uptime.

Cela vaut pour l’infrastructure d’hébergement, cloud et VPS : le client final n’a pas à apprendre ce qu’est un live patch. Il doit trouver le site allumé. Si vous gérez le parc en agence, la différence se voit dans les tickets qui n’arrivent pas. Détails sur la sécurité Host.it et les VPS.

Le CVE noyau est un sujet gênant en réunion tant que vous le racontez comme de la techno. Il devient une ligne de tarif si vous le traduisez en continuité, responsabilité et forfait.

• Une clause d’uptime honnête. Ne promettez pas 100 %. Expliquez que les mises à jour de sécurité système ne coïncident pas avec des fenêtres de site éteint à chaque avis. C’est une raison concrète de rester chez un hébergeur qui patche à chaud.
• Un rapport de maintenance. Une ligne dans le rapport mensuel : « noyau mis à jour, pas de downtime lié à un reboot ». Le client ne comprend pas le CVE ; il comprend que quelqu’un a fait le travail sans fermer la boutique.
• L’hébergement comme gouvernance. Avec Host Bucket vous isolez les clients, revendez sous votre marque et gardez une infra italienne. Le correctif noyau n’est pas un extra : il fait partie de la fiabilité que vous vendez.

Aucune de ces trois choses ne sort d’un prompt. Elles viennent d’une agence qui a choisi où tournent les sites et sait l’expliquer.

Les CVE du noyau Linux continueront d’arriver, en partie parce que la numérotation est plus large, en partie parce que l’IA aide à les trouver plus tôt. Qui répond par un reboot à chaque ID accumule du downtime. Qui ignore les avis accumule du risque. La troisième voie est celle que nous utilisons chez Host.it : correctif en temps réel, redémarrages seulement si besoin, uptime comme contrainte.

Si vous gérez des sites pour des tiers, c’est la conversation à avoir avec l’hébergeur, pas avec le CMS. Pour en parler sur votre parc : contactez-nous. Pour le programme revendeurs : hébergement pour agences web.