Une faille critique met en péril les serveurs CentOS 9 sous Linux

Une faille critique déchire le kernel Linux et les serveurs CentOS 9 vacillent. L’exploitation publique circule déjà, root en trois secondes chrono. Tant que le correctif officiel tarde, la panique gagne les salles machines !

Faille critique CAKE : un trou béant dans le cœur de CentOS 9

Le coup vient du scheduler réseau CAKE : une opération qui échoue, un faux retour “OK”, et hop, un pointeur orphelin qui flotte comme un packet perdu sur l’Ethernet. Je déclenche le “use-after-free”, je rebondis sur modprobe_path, et me voilà kernel side avec tous les privilèges. Même la sacro-sainte KASLR se fait doubler ; c’est Mr. Robot qui déroule son script pendant que le SOC sirote un café. Le PoC balancé le 5 février 2026 montre une fiabilité indécente : un simple utilisateur local transforme sa session en root avant que sudo n’ait le temps de demander son mot de passe.

Pourquoi les serveurs CentOS 9 encaissent la tempête en premier

CentOS 9, clone docile de RHEL, trône dans les datacenters depuis deux ans. Build pipelines, bases de données, VM Kubernetes : tout tourne dessus parce que “stable, long support”. Sauf qu’un bug au niveau kernel ne respecte pas les SLA : un container mal isolé ou un dev trop curieux suffit pour amorcer l’attaque informatique. D’après un rapport 2026, 73 % des PME n’ont toujours pas de patch-management sérieux ; résultat, un shell malveillant se propage plus vite qu’un meme sur Mastodon. Vous pensiez que le compile-time hustle des archers était excessif ? Aujourd’hui il sauve leur peau, car ils rebuildent leur kernel entre deux tasses de maté.

Étapes immédiates pour contenir la vulnérabilité pendant que le patch arrive

Je surveille obsessionnellement les avis de Red Hat, GitLab CI tourne déjà sur un kernel custom coupant CAKE à la racine. Vous n’avez pas la fibre bricoleuse ? Alors désactivez cette qdisc, limitez chaque accès local, cloisonnez vos comptes de build, et activez un auditd qui hurle dès qu’un binaire non signé se faufile. Les fans de hardening gratteront encore quelques points en verrouillant la variable modprobe_path en lecture-seule, histoire de fermer la porte au PoC public. Oui, ce n’est qu’un pansement, mais en sécurité informatique l’imperfection contrôlée vaut mieux que l’inertie.

Surveiller les logs n’est pas négociable : un spike de CPU hors heures ouvrées ou un chargement inattendu de module est votre premier rencard avec l’ennemi. Pas besoin de SIEM hors de prix pour ça ; un vieux script bash qui switche en mode verbeux, quelques chronos, et le tour est joué. L’enjeu, c’est la vitesse : plus l’exploitation reste active, plus la cybersécurité interne s’effrite, et bientôt c’est tout le cluster qui part en fumée.

Le correctif, ou comment regagner la confiance perdue

Les mainteneurs upstream bossent à la hache : un patch circule déjà sur LKML, encore marqué RFC. J’ai testé le diff : il replace le test de retour, nettoie la file avant le free, et ajoute une vérif’ qui tue le pointeur baladeur. Compilée sur un ThinkPad rouillé, la nouvelle build tient la charge sans plomber la latence réseau ; pas mal ! Pourtant, le vrai challenge commence quand les repos Enterprise pousseront la mise à jour : convaincre les équipes qu’un reboot en pleine journée vaut mieux qu’un deface sur le portail client. À ceux qui hésitent encore : rappelez-vous Heartbleed, rappelez-vous Log4Shell. Chaque minute perdue est une ligne de commande offerte à l’attaquant.

Alors oui, rebooter un hyperviseur plein de VM c’est le stress. Pourtant, laisser un kernel troué, c’est accepter qu’un pentester mal intentionné orchestre votre infra comme un DJ. Cette vulnérabilité rappelle que le mythe “Linux invulnérable” ne tient pas face à un dev distrait et un pointer qui dérive. Patchons vite, patchons bien, et retournons bricoler nos scripts, parce qu’au fond, compiler c’est la méditation du peuple pingouin.

Source: www.ad-hoc-news.de