Mayday, May Day ! Mai : IA et vulnérabilités critiques : quand la fête du Travail devient un mirage pour les administrateurs système

Il ne s'agit pas simplement d'une série de bugs : c'est un changement de paradigme.

Le véritable problème n'est pas l'existence de vulnérabilités. Les vulnérabilités ont toujours existé et existeront toujours. Un logiciel complexe est imparfait par définition, surtout lorsqu'il est utilisé pendant des années, accumulant fonctionnalités, compatibilités, modules, couches, rétrocompatibilité et cas particuliers.

La différence aujourd'hui, c'est la vitesse.

Il y a encore quelques années, transformer un correctif en exploit exigeait des compétences très spécifiques. Il fallait maîtriser la lecture attentive du C et du C++, comprendre l'assembleur, la pile, le tas, les techniques de corruption de mémoire, GDB, le retour à la libc, les chaînes ROP, le contournement de l'ASLR, le shellcode, les séquences NOP, les primitives de lecture et d'écriture, les conditions de concurrence, l'utilisation après libération, la double libération, les dépassements d'entiers, le parcours de répertoires, la désérialisation, et toute cette matière grise qui, pendant des décennies, a distingué le simple « lecteur averti » du véritable développeur d'exploits.

Aujourd’hui, cette frontière n’a pas disparu, mais elle est devenue dangereusement mince.

Les modèles de langage ne transforment pas automatiquement n'importe qui en chercheur en sécurité de haut niveau. Ce serait une vision superficielle et erronée. En revanche, ils réduisent considérablement le coût de l'analyse préliminaire, de la compréhension des différences, de la classification des bogues, de la formulation d'hypothèses et de la création de preuves de concept. D'après l'article de Tom's Hardware dont nous nous inspirons, les modèles de langage peuvent réduire drastiquement le temps nécessaire pour transformer un correctif en exploit fonctionnel, remettant même en question le délai de divulgation traditionnel de 90 jours. Tom's Hardware Italia : Correctifs, exploits et IA.

C'est là tout l'intérêt : il n'est plus nécessaire d'analyser un code source entier de millions de lignes . La méthode la plus efficace et pragmatique est souvent bien plus simple : prendre la version précédente, prendre la version suivante, effectuer une comparaison, observer les modifications, isoler le code concerné et, à partir de là, tenter de comprendre quelle vulnérabilité a été corrigée.

Avant l'avènement de l'IA, ce processus exigeait du temps, de l'expertise et de l'intuition. Aujourd'hui, il peut être accéléré, parallélisé, automatisé, perfectionné et répété sur des centaines de projets, de versions et de correctifs.

Il n'est plus nécessaire d'imaginer des modèles secrets et mythiques dissimulés dans les laboratoires de grandes entreprises ou d'agences gouvernementales. Seuls des modèles courants, des outils de programmation assistée, des agents automatisés, des chaînes d'analyse et des budgets adéquats sont requis. La distinction entre attaquant et défenseur s'en trouve ainsi accentuée : le défenseur doit inventorier, évaluer, tester, corriger, redémarrer, communiquer, atténuer les risques et vérifier ; l'attaquant, quant à lui, doit trouver une faille de sécurité avant la fin de ce processus.

Chronologie d'un mois de mai tendu

Pour comprendre le degré de concentration du problème, il est utile de remettre les événements dans l'ordre.

Le 28 avril 2026, la vulnérabilité CVE-2026-41940 de cPanel/WHM a été découverte. Cette faille dans la couche de gestion des sessions est particulièrement grave car elle affecte un panneau de contrôle largement utilisé dans le secteur de l'hébergement. cPanel a indiqué avoir publié des mises à jour le 28 avril et déployé des correctifs environ 28 heures après la confirmation du signalement, couvrant les versions prises en charge et certaines versions plus anciennes. Mise à jour de sécurité cPanel : CVE-2026-41940.

Il 29 Avril Entrez Copy Fail, CVE-2026-31431, une vulnérabilité du noyau Linux permettant une élévation de privilèges locale. Le problème réside dans le sous-système cryptographique algif_aead et implique une interaction avec splice()Le cache de pages et les binaires privilégiés sont concernés. L'aspect le plus inquiétant n'est pas seulement l'impact technique, mais aussi la portabilité de l'exploit : Tom's Hardware a signalé que le code d'exploitation était public et fonctionnait sur plusieurs distributions majeures, facilitant ainsi son utilisation par d'éventuels attaquants. https://xint.io/blog/copy-fail-linux-distributions

Le 5 mai, le correctif pour Apache HTTP Server 2.4.67 a été publié. Il corrige la vulnérabilité CVE-2026-23918 : double libération de mémoire et possible exécution de code à distance dans la gestion HTTP/2. Apache précise que ce problème affecte Apache HTTP Server 2.4.66 et recommande la mise à niveau vers la version 2.4.67. Vulnérabilités d'Apache HTTP Server 2.4.

Le 7 mai, la faille Dirty Frag a été révélée, avec les vulnérabilités CVE-2026-43284 et CVE-2026-43500, deux vulnérabilités d'élévation de privilèges locale (LPE) dans le noyau Linux. Ubuntu décrit CVE-2026-43284 comme un problème lié à la gestion des fragments partagés dans les skbs et au déchiffrement sur place dans ESP/IPsec, avec pour conséquence une élévation de privilèges locale. Sécurité Ubuntu : CVE-2026-43284.

Le 12 mai, le cas de contournement de la validation de réécriture d'URL NGINX a été ajouté. Cette vulnérabilité logique affecte la réécriture, la normalisation et les scénarios de désalignement entre le contrôle d'accès et la ressource réellement consultée. Pour les administrateurs de proxys inverses, de passerelles applicatives et d'architectures comportant plusieurs serveurs dorsaux, il s'agit d'un problème à ne pas sous-estimer : souvent, la simple mise à jour d'un paquet ne suffit pas ; les hypothèses architecturales, les règles de localisation, les passes de proxy, les réécritures et la validation doivent également être examinées. Ce problème est analysé en détail à l'adresse suivante : https://www.redhotcyber.com/post/un-bug-critico-per-18-anni-e-rimasto-nascosto-nelle-codice-di-nginx/

Il ne s'agit pas d'une suite aléatoire de petits incidents. C'est un véritable déluge d'attaques. Et ce déluge cible des composants essentiels utilisés par au moins 90 % des machines exposées au réseau et exécutant des serveurs web. Au moins 90 % !

Apache, Linux, NGINX, cPanel : pourquoi ces noms sont importants

Lorsqu'une vulnérabilité affecte un logiciel de niche, le problème reste limité. En revanche, lorsqu'elle touche Apache HTTP Server, NGINX, le noyau Linux ou cPanel/WHM, l'ampleur du problème change du tout au tout.

Apache demeure aujourd'hui une pierre angulaire du web. Même lorsqu'il n'est pas directement exposé comme interface utilisateur, on le retrouve derrière des proxys inverses, dans des environnements existants, des applications d'entreprise, des hébergements mutualisés, des systèmes de gestion de contenu (CMS) et des architectures LAMP. Une exécution de code à distance (RCE) potentielle sous HTTP/2 est loin d'être anodine. HTTP/2 est largement utilisé, et la gestion des trames, des flux et des réinitialisations anticipées est un domaine complexe où une erreur de mémoire peut avoir des conséquences importantes.

Le noyau Linux est le socle commun. Il est présent sous les conteneurs, les serveurs physiques, les VPS, les instances cloud, les hyperviseurs dans de nombreux cas, ainsi que dans les appliances et les distributions. Une élévation de privilèges locale n'est pas « moins grave » du simple fait qu'elle nécessite un accès local. En pratique, cet accès peut provenir d'un compte compromis, d'un shell web, d'un conteneur compromis, d'un utilisateur d'hébergement, d'une tâche CI/CD, d'un plugin vulnérable ou d'un CMS compromis. Une fois à l'intérieur, l'obtention des privilèges root change radicalement la portée de l'incident.

NGINX est le serveur web et proxy inverse de référence dans de nombreuses infrastructures modernes . Véritable étalon, il constitue souvent la première ligne de défense contre les applications PHP, Node.js, Python, Java, les microservices, les API et les panneaux d'administration. Un contournement du contrôle d'accès ou une traversée logique de chemin via la réécriture et la normalisation peut transformer une configuration apparemment sécurisée en un chemin alternatif vers les ressources internes.

Enfin, cPanel/WHM est l'un des panneaux de contrôle les plus populaires du secteur de l'hébergement. Une vulnérabilité de contournement d'authentification dans ce contexte est particulièrement préoccupante car elle n'affecte pas un seul site, mais potentiellement l'administration de serveurs entiers, de comptes, de DNS, de messagerie, de bases de données et de services associés.

La combinaison de ces quatre mondes raconte une histoire très simple : le mois de mai 2026 a touché presque tout ce qu’un administrateur de système Linux et d’hébergement doit superviser, et une combinaison d’événements de cette ampleur n’avait jamais été vue depuis 1994.

L'ingénieur système pris entre le marteau et l'enclume

Dans le récit simplifié de la cybersécurité, on trouve d'un côté les pirates informatiques et de l'autre les développeurs. Les pirates informatiques découvrent les failles de sécurité, les développeurs les corrigent. Mais au milieu, souvent oublié, se trouve l'administrateur système.

L'administrateur système reçoit le correctif une fois la vulnérabilité rendue publique. Il doit déterminer si le parc informatique est concerné. Il doit également faire la distinction entre les systèmes vulnérables, les systèmes non vulnérables, les systèmes dont la vulnérabilité peut être corrigée, les systèmes nécessitant un redémarrage immédiat, les systèmes nécessitant une fenêtre de redémarrage prédéfinie, les systèmes hérités, les systèmes avec des dépendances applicatives, les serveurs à disponibilité critique, les environnements de production, les environnements de préproduction et les environnements oubliés depuis des années mais « ne pouvant être arrêtés ».

C’est à l’administrateur système qu’il incombe d’expliquer au client la nécessité du redémarrage. Il doit choisir entre le risque d’indisponibilité du service et le risque de compromission. Il doit consulter les avis de sécurité, les journaux de modifications, les CVE, les listes de diffusion, les outils de suivi des problèmes, les packages de distribution, les rétroportages, les correctifs spécifiques aux fournisseurs, les notes de compatibilité, les faux positifs des scanners et les rapports incomplets.

Et aujourd'hui, elle doit le faire alors que, de l'autre côté, les attaquants, ou même simplement les chercheurs les plus agressifs, peuvent utiliser l'IA pour réduire considérablement les temps d'analyse.

C’est ce point qui est souvent mal compris par ceux qui observent la sécurité de l’extérieur. Le problème n’est pas la « mise à jour » en elle-même, mais la mise à jour efficace et rapide, sans interruption de production , sans perte de données, sans régression, sans négliger les systèmes secondaires, sans créer de panique et sans transformer une simple journée de déploiement de correctifs en catastrophe opérationnelle.

Pourquoi nous avons refusé les devis et l'intégration

Récemment, chez Managed Server Srl, nous avons pris une décision qui n'était pas agréable, mais que nous pensons être la bonne : nous avons délibérément refusé d'envoyer des devis urgents et d'intégrer de nouveaux clients, en donnant la priorité absolue à la résolution des problèmes, aux correctifs, aux tests et au développement d'outils internes pour accélérer les activités futures.

Certains clients potentiels ont très, très, TRÈS mal pris cette décision. Nous comprenons. Nous en sommes sincèrement désolés. Ceux qui demandent un devis urgent ont souvent un besoin urgent. Il peut s'agir d'un projet au point mort, d'un site web lent, d'une infrastructure instable, d'un site e-commerce à migrer, d'une échéance de vente à respecter ou d'un problème technique à résoudre.

Parfois, c'est un simple caprice, on souhaite juste un devis sous 24 à 48 heures, car après tout, c'est le client qui décide, et le client, comme chacun sait, a « toujours raison ». Dans le secteur des systèmes, cependant, nous ne sommes pas un magasin d'électroménager, ni une épicerie fine qui vend ses produits à prix d'or, mais plutôt un service d'urgences, avec un système de triage, où les clients ayant des problèmes sérieux sont prioritaires sur ceux qui cèdent à une simple envie et veulent passer outre les cas graves sous prétexte qu'ils sont « clients payants ». Malheureusement, il y a certains détails en coulisses, que nous expliquerons dans cet article, qui n'est pas tant une excuse qu'un compte rendu de ce qui s'est passé et de ce qui risque de se reproduire.

Nous en sommes sincèrement désolés. Nous sommes désolés pour notre nouveau client potentiel, car ne pas recevoir de réponse commerciale dans les délais souhaités peut être frustrant. Nous sommes également désolés pour le manque à gagner, car chaque devis non traité représente une opportunité manquée.

Mais la sécurité et la continuité des activités des clients existants passent avant tout.

Une entreprise d'hébergement et d'ingénierie système ne se contente pas de vendre de l'espace disque, du processeur, de la mémoire vive ou du trafic. Elle vend du support technique, de la responsabilité, de l'attention, de l'expertise et de la réactivité. Face aux graves vulnérabilités des composants critiques à l'échelle mondiale, la priorité ne peut être de conclure de nouveaux contrats pendant que les clients existants attendent les correctifs, les analyses, les mesures d'atténuation et la vérification.

Nous sommes convaincus d'avoir agi avec diligence pour protéger notre activité et, surtout, celle de nos clients actuels. Un nouveau client peut attendre un devis. Un serveur vulnérable en production, lui, ne le peut pas.

Outils internes, automatisation et mise à jour rapide

L'un des effets secondaires de cette vague a été l'accélération du développement d'outils internes pour le correctif rapide, l'inventaire et la vérification.

C’est un point crucial. Dans un monde où des failles de sécurité peuvent apparaître quelques heures seulement après la publication d’un correctif, la réponse ne peut reposer uniquement sur la mémoire d’un seul administrateur système ni sur des procédures manuelles répétées serveur par serveur.

Nous avons besoin d'outils qui nous permettent de savoir rapidement où une version donnée d'Apache est installée, où HTTP/2 est activé, quels serveurs utilisent NGINX avec des règles de réécriture complexes, quels noyaux sont en cours d'exécution, quelles machines nécessitent un redémarrage forcé après une mise à niveau, quelles versions de cPanel sont encore vulnérables, quels nœuds sont couverts par des correctifs du fournisseur et lesquels nécessitent des mesures d'atténuation temporaires.

Nous avons besoin d'une cartographie. Nous avons besoin d'automatisation. Nous avons besoin de la capacité d'effectuer des contrôles en masse sans perte de qualité. Nous avons également besoin de la capacité de produire des rapports, car la sécurité ne se résume pas à « nous avons mis à jour », mais à « nous avons mis à jour, vérifié, documenté et nous savons ce qui reste à faire ».

Par exemple, nous avons étendu notre outil de gestion, de surveillance et d'inventaire des pare-feu avec un système d'exécution SSH multiple afin de pouvoir identifier immédiatement les systèmes et procéder à l'application massive de correctifs.

Le concept de base consistait à déployer un effort initial plus important pour adapter ce que nous souhaitions, afin de gagner du temps à chaque fois que des situations similaires pourraient survenir, dans lesquelles des correctifs doivent être appliqués non pas en plusieurs jours, mais en quelques heures sur l'ensemble du parc de machines, qu'il s'agisse de centaines, de milliers ou de dizaines de milliers de systèmes et de nœuds.

En résumé, l'IA peut être utilisée par les attaquants, mais elle doit également l'être par les défenseurs. Non pas pour remplacer le jugement technique, mais pour accélérer l'analyse, la corrélation, la lecture des journaux de modifications, la synthèse des avis, la génération de listes de contrôle, la gestion de la configuration et l'exécution des tâches répétitives. L'essentiel est de ne pas déléguer aveuglément, mais d'utiliser l'automatisation comme un exosquelette opérationnel.

Le problème des cycles de publication open source

Ceci nous amène au sujet le plus délicat : le modèle traditionnel de publication open source est-il encore adapté dans un monde où l’IA peut rapidement transformer un correctif en faille de sécurité ?

La question est provocatrice, mais on ne peut plus l'ignorer.

L'open source repose sur la transparence. Le code est public, les correctifs sont publics, les différences sont publiques. Cela présente d'énormes avantages : auditabilité, confiance, collaboration, vérification indépendante, possibilité de rétroportage, contrôle communautaire et absence de zones d'ombre. Mais dès qu'un correctif de sécurité est publié, même un attaquant peut voir précisément ce qui a changé.

Auparavant, cette transparence nécessitait une expertise pointue pour être exploitée. Aujourd'hui, l'IA abaisse ce seuil. Une petite différence constitue un contexte idéal pour une analyse de code : quelques lignes modifiées, fonctions associées, messages de commit, tests ajoutés, correctifs apportés. Il est bien plus facile d'analyser une centaine de lignes de code qu'une base de code de plusieurs millions.

Cela soulève un dilemme : est-il toujours judicieux de publier simultanément des correctifs binaires, le code source et suffisamment d’informations pour permettre une reconstitution rapide de la vulnérabilité ? Ou, pour certaines catégories de bogues critiques, faudrait-il privilégier des fenêtres de publication différentes, une distribution coordonnée aux fournisseurs, une publication binaire préalable suivie d’une publication du code source ?

La réponse n'est pas simple.

Retarder la publication du code source peut protéger temporairement les utilisateurs finaux, mais cela crée des tensions avec les principes de l'open source, complique la vérification indépendante, pénalise les distributions et les responsables de la maintenance, introduit des problèmes de confiance et risque de créer des asymétries entre ceux qui y ont un accès anticipé et ceux qui n'y ont pas accès.

Cependant, dans certains cas, tout dévoiler d'un coup revient à donner aux attaquants une carte presque immédiatement.

Il n'existe pas de solution parfaite. Mais nier le problème serait irresponsable.

La période de divulgation de 90 jours est-elle toujours pertinente ?

Pendant des années, le délai de divulgation de 90 jours a été considéré comme un compromis raisonnable : suffisamment long pour permettre aux fournisseurs de corriger les problèmes, suffisamment court pour empêcher que les vulnérabilités ne restent secrètes indéfiniment.

Mais si l'IA permet de transformer les correctifs et les avis de sécurité en failles exploitables en un temps record, le problème se déplace. Il ne suffit plus de se demander « combien de temps le fournisseur a-t-il eu pour corriger la faille ? » Il faut se demander « combien de temps le défenseur a-t-il eu pour déployer le correctif avant que la faille ne soit largement exploitée ? »

Cette deuxième fenêtre est beaucoup plus étroite.

Dans les environnements réels, notamment pour l'hébergement et les infrastructures gérées, l'application de correctifs ne se résume pas à appuyer sur un bouton. Il est essentiel de prendre en compte la compatibilité, la charge, les fenêtres de maintenance, les redémarrages, les clusters, la haute disponibilité, les restaurations, les sauvegardes, les tests d'application, la communication avec les clients et la surveillance post-correctif.

Si le délai entre la publication d'un correctif et l'exploitation d'une faille se réduit à quelques heures seulement, le modèle opérationnel doit évoluer. Il ne suffit plus d'être « assez rapide », il faut se préparer à l'avance.

La sécurité n'est plus un département : c'est une posture permanente

La leçon de ce mois de mai est claire : la sécurité ne saurait être un événement ponctuel. Elle ne peut se résumer à un simple coup de pouce lors de la publication du CVE. Elle ne peut être la conséquence de la panique d'un vendredi soir ou d'un jour férié. Elle doit être une attitude permanente.

Cela implique un inventaire à jour, des procédures de correctifs testées, l'automatisation, la surveillance, des sauvegardes vérifiées, des capacités de restauration, la segmentation, la réduction de la surface d'attaque, le durcissement, le principe du moindre privilège, le contrôle d'accès, la journalisation centralisée, l'EDR le cas échéant, la mise à jour du noyau en direct lorsque cela est possible, des environnements de test réalistes, une documentation interne et un personnel formé.

Cela signifie aussi avoir le courage de dire non. Non aux nouvelles recrues lorsque l'équipe doit gérer une crise. Non aux devis urgents si la priorité technique est de protéger ceux qui nous ont déjà confié leur infrastructure. Non à la croissance commerciale lorsqu'elle risque de compromettre la qualité opérationnelle.

Dans un secteur mature, cela ne doit pas être perçu comme un manque d'attention commerciale, mais comme un signe de sérieux.

De toute évidence, cet engagement supplémentaire, et les risques accrus associés aux nouvelles directives NIS2, se traduiront nécessairement par un travail beaucoup plus important et entraîneront inévitablement des coûts de gestion supérieurs d'au moins 10 à 15 % aux coûts actuels, déjà majorés par la course au matériel dictée par la révolution de l'IA.

IA contre développeurs, hackers contre défenseurs : le nouvel équilibre

L'image symbolique de ce moment est celle d'un bras de fer : d'un côté les attaquants, de l'autre les développeurs et les mainteneurs, avec l'intelligence artificielle au milieu comme un arbitre ambigu, un accélérateur neutre qui ne fait pas de distinction entre ceux qui défendent et ceux qui attaquent.

Mais le tableau est peut-être encore incomplet. Car à côté de la table, sous pression, se trouve l'administrateur système. C'est lui qui doit traduire les résultats de ce bras de fer en actions concrètes sur les serveurs. C'est lui qui doit encaisser le coup de grâce.

L'IA n'est ni « bonne » ni « mauvaise ». C'est un outil. Mais comme tout outil puissant, elle modifie l'équilibre. Et en cybersécurité, l'équilibre compte plus que les intentions.

Si un attaquant peut analyser cent correctifs par jour et qu'un défenseur peut corriger correctement dix systèmes critiques par jour, le problème n'est pas moral : il est mathématique.

L'avantage revient à ceux qui automatisent mieux, font un meilleur inventaire, prennent des décisions plus rapidement, réduisent la complexité et ne sont pas pris au dépourvu.

Conclusion : Mai 2026, un signal d'alarme

Mai 2026 risque de rester dans les mémoires comme un signal d'alarme. Apache, NGINX, le noyau Linux, cPanel/WHM : des noms incontournables, des logiciels omniprésents, des vulnérabilités concentrées, des impacts significatifs, des correctifs urgents, des exploits et une analyse de plus en plus rapide.

Ce n'est pas la fin de l'open source. Ce n'est pas la preuve que Linux est vulnérable. Ce n'est pas le moment de s'alarmer inutilement.

Il est temps d'admettre que le modèle opérationnel de sécurité est en train de changer . L'intelligence artificielle a réduit le délai entre le déploiement des correctifs et la compréhension des vulnérabilités. Elle a abaissé les barrières techniques à l'analyse des vulnérabilités. Elle a simplifié l'automatisation des tâches fastidieuses qui nécessitaient auparavant des heures, voire des jours, de rétro-ingénierie manuelle.

De ce fait, les gestionnaires d'infrastructures ne peuvent plus se permettre la lenteur, l'improvisation ou les processus artisanaux.

Chez Managed Server Srl, nous avons passé la journée du 1er mai à travailler dur, et dix-sept jours plus tard, nous continuons à relever les défis que ce mois-ci nous a imposés : correctifs, vérifications, mesures d’atténuation, automatisation, outils internes, procédures plus rapides et réactivité accrue.

Nous aurions préféré un pique-nique, un goûter, une excursion d'une journée. Nous aurions également préféré envoyer davantage de devis, acquérir de nouveaux clients et explorer de nouvelles opportunités commerciales.

Mais lorsque la sécurité est primordiale, le devoir prime sur les recettes.

Et c’est peut-être là, en définitive, la manière la plus sérieuse d’honorer véritablement la Fête du Travail : travailler lorsque c’est nécessaire, protéger ceux qui se sont confiés à nous et se préparer à la prochaine attaque avant qu’elle ne survienne.

Et nous ne sommes qu'à la moitié du mois... à un jour près.

MISE À JOUR au 21 mai 2026, soit seulement 4 jours plus tard.

Comme nous l'avions déjà anticipé dans l'article publié dimanche, de nouvelles surprises étaient à prévoir, et elles ne se sont d'ailleurs pas fait attendre.

Pour la série Exploitation localeLundi 18 mai, pour bien commencer la journée et la semaine, nous nous sommes retrouvés confrontés à un nouveau virus appelé Décryptage saleIl s'agit d'une vulnérabilité de Escalade locale des privilèges dans le noyau Linux, identifié comme CVE-2026-31635Cette faille peut permettre à un utilisateur local non privilégié d'obtenir les droits d'administrateur sur des systèmes vulnérables. Elle affecte la gestion du déchiffrement des tampons réseau par le noyau et fait partie de la famille des vulnérabilités liées à… DirtyFrag / CopyFail, avec des preuves de concept publiques déjà disponibles et donc un niveau d'attention particulièrement élevé de la part de ceux qui gèrent des serveurs Linux en production.

Mais aujourd'hui, 21 mai 2026 , une nouvelle bien plus sérieuse nous attend : une nouvelle vulnérabilité d'exécution de code à distance (RCE) présumée sur NGINX , baptisée NGINX Poolslip . Il s'agit d'une possible vulnérabilité RCE , et non plus d'une simple faille locale ou d'une vulnérabilité exploitable uniquement par un utilisateur présent sur la machine. C'est une catégorie de bugs potentiellement beaucoup plus dangereuse, car elle peut théoriquement être activée à distance sur un service exposé sur Internet. NGINX, tout comme Apache, est l'un des serveurs web les plus populaires au monde. Il est souvent choisi pour ses performances, son efficacité dans la gestion des connexions simultanées et son utilisation répandue comme proxy inverse, répartiteur de charge et interface HTTP pour les applications PHP, Node.js, Python, les conteneurs et les environnements Kubernetes. D'après les premiers rapports publics, le problème affecte également NGINX 1.31.0 , la version principale la plus récente publiée avec des correctifs pour la vague précédente de vulnérabilités NGINX Rift / CVE-2026-42945.

Les principales distributions Linux ont commencé à publier des mises à jour correctives du noyau ; AlmaLinux, par exemple, signale l’impact sur AlmaLinux 9 et 10, et des correctifs sont également prévus pour AlmaLinux 8, même si les preuves de concept publiques ne semblent pas être immédiatement efficaces sur cette version.