Catégorie : Sécurité informatique

Une chaîne de caractères glissée dans le champ username d’une requête d’authentification, et sept jours plus tard un attaquant se retrouve avec root sur ton appliance NetScaler — sans avoir rien authentifié. C’est le mécanisme de CVE-2026-88771, une injection de commande (CWE-20) notée 9.5 en CVSS 4.0, divulguée par Citrix le 27 septembre 2026 et toujours activement exploitée six semaines plus tard : CrowdSec a compté 308 signaux correspondants entre le 28 septembre et le 18 octobre, avec un pic de 43 en une seule journée le 14 octobre. Si tu as patché la variante SAML CVE-2026-88779 couverte ici début octobre en pensant avoir réglé le dossier NetScaler, cet article-là concerne un autre trou, plus ancien et bien plus grave.

Un mécanisme d’exploitation qui vaut le détour technique

Ce n’est pas une injection SQL classique. Citrix journalise le nom d’utilisateur envoyé à l’endpoint /nf/auth/doAuthentication.do, sans validation. Un script de maintenance interne, ns_monuploadd_err.pl, relit ensuite ces lignes de log sur une base planifiée et les insère dans une commande shell sans les filtrer — la commande s’exécute alors en root. Comme ce script tourne sur un cron interne et pas à la réception de la requête, l’exécution peut survenir jusqu’à 24 heures après l’envoi de la charge, ce qui complique sérieusement la corrélation dans les logs si tu cherches l’origine après coup. D’après watchTowr, qui a documenté la chaîne complète, d’autres champs loggés comme le User-Agent peuvent porter la même charge. Et la configuration par défaut est vulnérable : aucune fonctionnalité optionnelle à activer pour être exposé, aucun prérequis particulier côté config NetScaler.

Chez Rapid7, l’analyse post-compromission d’une des deux organisations identifiées montre exactement ce que fait la commande injectée une fois exécutée : elle archive /flash/nsconfig — le dossier qui contient ns.conf — dans /var/netscaler/gui/vpn/c. Problème : le dossier /vpn/ est servi publiquement par l’appliance, sans authentification. N’importe qui peut donc récupérer cette archive avec un simple GET sur /vpn/c. Et le contenu n’est pas anodin : mots de passe admin chiffrés, identifiants de bind LDAP/RADIUS/TACACS, certificats SSL et clés privées, clés d’hôte SSH, fichiers de licence, paramètres de synchronisation HA. Autrement dit, de quoi relancer une attaque bien après le premier accès, même si la faille d’origine est corrigée depuis.

Versions concernées et correctif

Citrix a corrigé la faille dans les versions suivantes, publiées le 27 septembre 2026 (bulletin CTX697096) :

• NetScaler ADC et Gateway 14.1 : corrigé en 14.1-73.37 (vulnérable avant cette version)
• NetScaler ADC et Gateway 13.1 : corrigé en 13.1-64.23
• NetScaler ADC 14.1-FIPS : corrigé en 14.1-73.37 FIPS
• NetScaler ADC 13.1-FIPS et 13.1-NDcPP : corrigé en 13.1-37.279

Ces mêmes builds corrigent aussi CVE-2026-88772 (CVSS 9.5, débordement mémoire nécessitant DTLS activé) — les deux failles font partie du même lot de huit vulnérabilités publiées ce jour-là. Si ta version remonte seulement jusqu’à ces builds de septembre sans aller jusqu’à 14.1-73.41/13.1-64.28, tu restes en revanche exposé à CVE-2026-88779, patchée une semaine plus tard et déjà traitée dans l’article lié plus haut : deux lots de correctifs distincts, à appliquer dans l’ordre chronologique inverse de leur publication.

Chronologie de l’exploitation : plus ancienne que la divulgation

Rapid7 situe les premières tentatives d’exploitation de CVE-2026-88771 au 20 septembre 2026 — soit une semaine avant que Citrix ne publie l’avis officiel. Beazley Security date même une campagne probable dès le 20 septembre, et le chercheur Kevin Beaumont rapporte des webshells observés début septembre. Le 24 septembre, Rapid7 observe un webshell chez une deuxième organisation compromise, déposé à /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver (hash SHA256 ed082f744f035035900f67edf438f2f7d0528ac501234f63d476d65273cdb9a1 si tu veux le chercher dans tes propres logs). CISA a ajouté CVE-2026-88771 à son catalogue Known Exploited Vulnerabilities le jour même de la divulgation, avec une échéance de remédiation au 30 septembre pour les agences fédérales américaines — trois jours, pas trois semaines, ce qui donne une idée du niveau d’urgence perçu côté CISA.

Un détail qui change la donne pour qui doit juste patcher et passer à autre chose : un proof-of-concept public existe depuis le 28 septembre, le Detection Artefact Generator de watchTowr, qui se contente d’exécuter un id inoffensif en root pour confirmer la vulnérabilité sans causer de dégâts. Sa seule existence suffit à élargir le bassin d’attaquants capables de l’exploiter, bien au-delà du groupe qui l’a découverte.

Patcher ne suffit pas : l’ordre des opérations compte

Voilà le point sur lequel il ne faut pas se tromper : le correctif ferme la faille, il ne nettoie rien de ce qu’un attaquant a pu déposer avant. Et comme la mise à jour redémarre l’appliance — ce qui efface les implants purement en mémoire et une partie des preuves volatiles — patcher avant d’avoir cherché une compromission revient à détruire potentiellement les indices dont tu as besoin pour savoir si tu as été touché.

La bonne séquence, dans cet ordre précis :

• Fais d’abord une snapshot de l’appliance, puis cherche les indicateurs de compromission listés par Citrix dans l’article CTX694799 : comptes superutilisateur inconnus dans ns.conf (l’exemple cité par watchTowr est gw_health), fichiers inattendus dans /var/tmp et /var/vpn/ns_helper, fichiers cachés sous /var/netscaler/logon/LogonPoint/, un listener sur le port TCP 37512, des clés inconnues dans /root/.ssh/.
• Si tu trouves le moindre signe de compromission, ne patche pas en place : reconstruis depuis une image propre et fais tourner tous les secrets que l’appliance pouvait stocker — mots de passe LDAP/RADIUS/TACACS inclus, pas seulement le compte admin local.
• Si rien n’est trouvé, applique le correctif, vérifie la version avec show ns version en CLI, et reste vigilant : « rien trouvé » ne veut pas dire « rien n’est arrivé », juste que les indicateurs connus n’y sont pas.

CrowdSec a publié un scénario de détection dès le 28 septembre, mais signale ne disposer d’aucune règle de virtual patching (AppSec) spécifique à cette CVE à la date du 19 octobre — les listes de blocage couvrent une partie des IP malveillantes identifiées, pas la totalité. Côté chiffres d’exposition, CrowdSec a tracé 24 IP source distinctes entre le 22 septembre et le 18 octobre. Ce n’est pas massif comparé à une faille de masse exploitée par botnet, mais ça correspond à une activité ciblée et soutenue sur près d’un mois, pas à un test isolé qui se serait éteint tout seul.

FAQ

CVE-2026-88771 et CVE-2026-88779, c’est la même faille ?

Non. CVE-2026-88771 est une injection de commande exploitable sans authentification en configuration par défaut, corrigée le 27 septembre. CVE-2026-88779 est un déni de service lié à une configuration SAML spécifique, corrigée une semaine plus tard, le 4 octobre. Les deux appartiennent au même fournisseur et à des lots de correctifs rapprochés, mais ce sont deux failles distinctes avec deux surfaces d’exposition différentes.

Une authentification est-elle nécessaire pour exploiter CVE-2026-88771 ?

Non, c’est tout le problème : la charge part vers l’endpoint d’authentification lui-même, avant toute vérification d’identifiants. C’est ce qui explique le score CVSS de 9.5 et la complexité d’attaque qualifiée de faible par Citrix.

Comment savoir si mon appliance a déjà été compromise avant de patcher ?

Cherche les indicateurs listés plus haut (comptes superutilisateur inconnus, fichiers sous /var/tmp ou /var/netscaler/logon/LogonPoint/, listener sur le port 37512, clés SSH inconnues) avant d’appliquer le correctif, pas après — le redémarrage lié au patch peut effacer des preuves volatiles.

Le patch seul protège-t-il rétroactivement les secrets déjà exposés via /vpn/c ?

Non. Si l’archive de configuration a déjà pu être téléchargée par un attaquant, les secrets qu’elle contient (mots de passe, clés SSH, certificats) restent compromis tant qu’ils ne sont pas explicitement régénérés, même après la mise à jour.

Ce que ça dit sur les appliances exposées en 2026

Trois CVE NetScaler critiques en moins de six semaines sur le même produit, deux d’entre elles déjà exploitées avant même leur divulgation officielle : si ton NetScaler est exposé directement sur Internet sans WAF devant, ce n’est plus une question de « si » mais de « quand ». La bonne nouvelle, relative, c’est que Citrix documente ses indicateurs de compromission de façon précise à chaque fois — ce qui n’était pas toujours le cas il y a encore deux ou trois ans sur ce genre d’appliances. Prends le temps de l’audit avant de cocher la case « patché » dans ton tableau de suivi.

Le 13 octobre 2026, Microsoft a publié son plus gros Patch Tuesday à ce jour : 1 411 failles corrigées en une seule fournée, dont 70 classées critiques (57 d’exécution de code à distance, 11 d’élévation de privilèges, 2 de spoofing). Trois zero-days dans le lot. Une seule compte vraiment pour la priorisation immédiate : CVE-2026-96951, un contournement du Mark of the Web dans le Shell Windows, déjà exploité activement avant même la sortie du correctif. Le délai fixé par la CISA pour les agences fédérales américaines, le 16 octobre, est passé depuis quatre jours au moment où tu lis ces lignes. Si ce correctif n’est pas encore déployé chez toi, c’est le moment de remonter la pile des priorités.

Ce que fait CVE-2026-96951

Le Mark of the Web (MOTW) est l’attribut que Windows attache automatiquement à un fichier téléchargé depuis Internet — c’est lui qui déclenche l’avertissement SmartScreen, la Vue protégée d’Office, ou le blocage par défaut de certaines macros. Microsoft décrit CVE-2026-96951 comme une injection de commande dans le Shell Windows permettant à un attaquant non authentifié de contourner cette protection par le réseau. En clair : un fichier qui devrait être marqué comme non fiable passe au travers, et la victime se retrouve à exécuter un contenu que Windows aurait dû signaler.

Microsoft n’a publié aucun détail sur le vecteur d’exploitation exact ni sur qui a découvert la faille — une discrétion fréquente quand l’exploitation est déjà active et que communiquer le mécanisme risquerait d’accélérer sa diffusion. On sait en revanche, via le tracker de vulnérabilités Senserva, que le score CVSS retenu est de 8.8 et que la faille touche la quasi-totalité du parc Windows encore sous support : Windows 10 (1607, 1809, 21H2, 22H2), Windows 11 (23H2 à 26H2), et Windows Server de 2012 R2 à 2025, Server Core compris.

Le contournement MOTW ne sert quasiment jamais seul. C’est une brique qui désamorce une protection pour laisser passer l’étape suivante d’une attaque, typiquement un document ou un exécutable qui, une fois le marquage neutralisé, s’ouvre sans l’avertissement qui aurait dû faire hésiter l’utilisateur ou bloquer l’exécution. Le genre de brique qu’on retrouve en amont de campagnes de phishing livrant un chargeur ou un ransomware, même si Microsoft n’a lié cette CVE précise à aucune campagne nommée pour l’instant.

Les deux autres zero-days du mois

Contrairement à CVE-2026-96951, les deux autres ne sont pas exploitées activement : elles ont simplement été rendues publiques avant le correctif, ce qui justifie quand même une priorité au-dessus de la moyenne.

CVE-2026-108398 touche le .NET Framework : un chemin de recherche non fiable permet à un attaquant déjà authentifié localement de déposer un assembly .NET forgé et de contourner Windows Defender Application Control (WDAC), avec exécution de code dans un processus protégé, sans interaction de l’utilisateur. C’est James Forshaw, de Google Project Zero, qui l’a signalée ; son nom revient régulièrement sur ce type de faille touchant les mécanismes de confiance Windows.

CVE-2026-92707 est plus anodine : un déni de service dans MessagePack-CSharp, causé par une allocation mémoire séquentielle mal bornée côté .NET, exploitable à distance sans authentification. Microsoft la classe « modérée », loin derrière les deux premières en termes de priorité de correctif.

Patcher, concrètement

Les correctifs de CVE-2026-96951 sont répartis sur neuf mises à jour cumulatives selon la version visée : KB5126646, KB5126651, KB5126653, KB5126655, KB5126657, KB5126836, KB5126868, KB5127646 et KB5127648. Ces mêmes KB corrigent au passage huit autres CVE, dont CVE-2026-100202 et CVE-2026-105010 — appliquer la bonne mise à jour cumulative pour ta version de Windows règle donc plusieurs problèmes d’un coup, pas seulement le zero-day.

Pour prioriser sans tout relire ligne par ligne : commence par les postes et serveurs exposés à des téléchargements non maîtrisés (postes utilisateurs avec accès web large, serveurs de fichiers partagés avec l’extérieur), continue avec le reste du parc Windows selon ton cycle de déploiement habituel, et vérifie après coup que le niveau de patch correspond bien au KB attendu pour chaque version. Un inventaire rapide des mises à jour installées, via l’outil de gestion de patchs que tu utilises déjà, suffit pour un contrôle à l’échelle d’un parc.

Le catalogue KEV de la CISA référence CVE-2026-96951 depuis le 13 octobre avec exploitation active confirmée — c’est la source la plus fiable pour suivre l’évolution du statut si de nouvelles informations sortent. Pour le détail officiel complet de ce Patch Tuesday, le Security Update Guide de Microsoft reste la référence, même si l’interface n’est pas la plus agréable à parcourir en masse.

FAQ

Faut-il redémarrer les serveurs immédiatement après l’installation du correctif ?

Oui. Comme pour toute mise à jour cumulative Windows touchant un composant aussi bas niveau que le Shell, le correctif n’est actif qu’après redémarrage. Planifier une fenêtre de maintenance rapide prime sur l’attente d’un créneau plus confortable, vu l’exploitation déjà confirmée.

Les 1 411 failles corrigées concernent-elles toutes Windows ?

Non, ce chiffre couvre l’ensemble du portefeuille Microsoft pour ce Patch Tuesday — Windows, .NET, Office, Azure et autres produits — pas uniquement le système d’exploitation. Les trois zero-days de ce mois concernent spécifiquement Windows Shell et .NET Framework.

Le délai CISA du 16 octobre s’applique-t-il à mon entreprise si je ne suis pas une agence fédérale américaine ?

Non, la directive opérationnelle contraignante de la CISA ne vise que les agences fédérales civiles américaines. Mais le calendrier qu’elle fixe reste un bon repère de priorité pour n’importe quelle organisation : si une faille est jugée assez critique pour imposer une deadline légale à l’administration américaine, elle l’est probablement aussi pour ton infrastructure.

Si tu veux comparer avec le volume du mois précédent, on avait couvert le Patch Tuesday de septembre 2026 et ses 974 failles — la progression en un mois donne une idée de la cadence à laquelle le volant de correctifs continue de grossir. Et si le sujet des zero-days activement exploités t’intéresse plus largement, notre article sur le zero-day FortiMail CVE-2026-104286 suit le même type de mécanique de divulgation.

archive234. Si ce nom de compte apparaît dans les logs CLI de ta passerelle FortiMail, arrête ce que tu fais et traite ta machine comme compromise. C’est l’un des indicateurs que Fortinet a publiés le 1er octobre 2026 pour CVE-2026-104286, une faille critique activement exploitée en zero-day sur l’interface d’administration de FortiMail — et plus de dix jours plus tard, le correctif complet n’est toujours pas confirmé disponible pour trois des quatre branches concernées.

Ce que permet la faille, techniquement

CVE-2026-104286 cumule deux faiblesses : un path traversal classique (CWE-22) et un défaut de neutralisation des octets NULL (CWE-158) dans l’interface de management de FortiMail. L’effet combiné permet à un attaquant non authentifié d’écrire des fichiers arbitraires sur le système sous-jacent via une requête HTTP ou HTTPS forgée — pas de credentials nécessaires, pas d’interaction utilisateur. Le CVSS atteint 9.8, et pour une fois le chiffre n’est pas gonflé : écrire où on veut sur le disque d’une passerelle mail qui voit passer toute ta messagerie, c’est à peu près le pire scénario d’accès initial qu’on puisse avoir sur ce type d’appliance.

Fortinet l’a découverte en interne (l’équipe Product Security, pas un chercheur externe ni un rapport de compromission), ce qui n’a pas empêché l’exploitation active d’être confirmée dès la publication de l’avis FG-IR-26-175. Les versions concernées couvrent large : FortiMail 8.0.0 à 8.0.1, 7.6.0 à 7.6.6, 7.4.0 à 7.4.8, et 7.2.0 à 7.2.9.

Le patch n’est pas complètement sorti — et c’est le vrai problème

Voilà le point sur lequel il faut être précis plutôt qu’optimiste. Pour la branche 7.2, Fortinet donne une réponse claire : il n’y aura pas de correctif dédié, il faut migrer vers la 7.4 ou une version ultérieure. Pour les branches 7.4, 7.6 et 8.0, les versions corrigées annoncées sont respectivement 7.4.9, 7.6.7 et 8.0.2 — mais au 5 octobre, elles restaient documentées comme « à venir » plutôt que confirmées disponibles au téléchargement. Avant de planifier ta fenêtre de maintenance, vérifie toi-même sur le portail de support Fortinet et sur l’avis FG-IR-26-175 que la version ciblée est bien publiée : ne te fie pas à un numéro de version lu sur un blog tiers, y compris celui-ci.

En attendant un correctif confirmé, Fortinet recommande deux mitigations qui se combinent bien : désactiver le support IBE si tu ne l’utilises pas,

config system encryption ibe
    set status disable
end

et surtout bloquer l’accès à l’interface de management depuis Internet, ou la restreindre à des réseaux privés de confiance. C’est la mitigation qui compte le plus, parce que l’exploitation passe précisément par cette interface — et c’est une règle qui devrait de toute façon s’appliquer à toute interface d’administration, faille ou pas.

Comment savoir si tu as déjà été touché

Fortinet a publié une liste d’indicateurs de compromission assez précise pour que ça vaille le coup de les chercher maintenant plutôt que d’attendre un incident confirmé. Côté fichiers, surveille la présence de /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice et /data/etc/ld.so.preload, ainsi que des modifications sur /bin/smit, /data/etc/httpd.conf et /data/migadmin.tar.gz. Côté logs, trois signaux se recoupent dans les cas documentés : la création d’un compte d’archivage nommé archive234 pointant vers un serveur distant à l’adresse 79.141.169.187 (répertoire /uploads — un signe net d’exfiltration de données), une tâche cron liée à /migadmin, et des erreurs de déchiffrement IBE causées par un encodage Base64 invalide. Une seconde adresse IP, 45.129.0.192, apparaît aussi dans les communications associées à l’attaque.

CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities, avec une échéance au 4 octobre pour les agences fédérales américaines — triage forensique et mitigation. Cette échéance ne te concerne pas directement si tu n’es pas une agence fédérale US, mais l’inscription au catalogue KEV reste un signal fiable que l’exploitation est confirmée et active, pas hypothétique. BleepingComputer a publié l’analyse technique complète le jour de la divulgation, avec le détail des hachages SHA-256 pour chaque fichier IOC.

FAQ

Dois-je couper FortiMail en attendant le correctif ?

Pas nécessairement. La mitigation recommandée par Fortinet — restreindre l’accès à l’interface de management aux réseaux de confiance — neutralise le vecteur d’attaque sans arrêter le service de messagerie lui-même, à condition que cette interface ne soit pas déjà exposée publiquement (et elle ne devrait jamais l’être).

Comment savoir si mon interface de management FortiMail est exposée sur Internet ?

Vérifie les règles de pare-feu en amont de l’appliance et teste l’accès depuis une IP externe à ton réseau. Si tu peux atteindre l’interface d’admin sans être sur le VPN ou le réseau interne, elle est exposée — referme-la avant toute autre action.

La version 7.2 de FortiMail aura-t-elle un correctif ?

Non, Fortinet ne prévoit pas de correctif pour la branche 7.2. La migration vers la 7.4 (ou ultérieure) est la seule voie indiquée.

Passe à l’action

Si tu gères une passerelle FortiMail, la priorité n’est pas le patch — il n’est pas encore confirmé disponible pour ta version — c’est de vérifier dès aujourd’hui que l’interface de management n’est accessible que depuis un réseau de confiance, puis de chercher les IOC listés plus haut dans tes logs. On avait déjà couvert un lot de failles Fortinet ajoutées au catalogue CISA KEV mi-septembre, et le même réflexe de vérification d’exposition s’appliquait déjà à la faille SAML NetScaler traitée début octobre : les interfaces d’administration exposées sont, mois après mois, le point d’entrée le plus rentable pour un attaquant.

CISA a ajouté CVE-2026-88779 à son catalogue KEV le 4 octobre 2026, avec une échéance de remédiation fixée au 7 octobre pour les agences fédérales américaines. La faille touche NetScaler ADC et NetScaler Gateway, affiche un CVSS 4.0 de 8.7, et Citrix confirme des attaques ciblées déjà observées contre des appliances non corrigées. Si tu gères un NetScaler exposé sur Internet, ce n’est pas un correctif à mettre dans le backlog du mois prochain.

Ce que fait réellement la faille

C’est un débordement mémoire (CWE-119) qui provoque un déni de service : Citrix indique qu’un déclenchement répété peut rendre le service indisponible, sans impact constaté sur l’intégrité des données. Aucun détail technique d’exploitation n’a été publié par Citrix ni par CISA — seule la conséquence (DoS) est confirmée.

Qui est concerné : la précondition SAML

Toutes les appliances NetScaler ne sont pas exposées. Seules celles configurées en authentification SAML sont vulnérables — soit comme Service Provider (SP), soit comme Identity Provider (IdP) — utilisée en combinaison avec un virtual server Gateway ou AAA. Secure Private Access en déploiement hybride utilisant des instances NetScaler est également concerné.

Pour savoir si tu es exposé, cherche ces deux lignes dans ta configuration running :

add authentication samlAction
add authentication samlIdPProfile

Si l’une des deux apparaît et que du SAML tourne derrière un virtual server Gateway ou AAA, tu es dans le périmètre à patcher en priorité.

Versions affectées et correctifs

Ligne	Versions vulnérables	Version corrigée
NetScaler ADC/Gateway 14.1	avant 14.1-73.41	14.1-73.41
NetScaler ADC/Gateway 13.1	avant 13.1-64.28	13.1-64.28
14.1 FIPS	avant 14.1-73.41 FIPS	14.1-73.41 FIPS
13.1 FIPS/NDcPP	avant 13.1-37.282	13.1-37.282 FIPS/NDcPP

Le piège pour qui a déjà patché la semaine dernière

Citrix avait publié, la semaine précédente, un lot de 8 vulnérabilités NetScaler incluant deux failles critiques déjà exploitées, CVE-2026-88771 et CVE-2026-88772, corrigées en 14.1-73.37 et 13.1-64.23. Si tu as appliqué ce correctif et que tu coches la case SAML ci-dessus, tu dois remonter une deuxième fois vers 14.1-73.41 ou 13.1-64.28 : être sur 73.37/64.23 ne protège pas contre CVE-2026-88779, qui est sortie après.

Mitigation temporaire si tu ne peux pas patcher immédiatement

Sur les versions intermédiaires 14.1-73.37 à 73.40 et 13.1-64.23 à 64.27, les signatures Global Deny List réduisent l’exposition si le virtual patching est activé. Vérifie leur présence avec :

show appfw signatures

Ce n’est qu’un pansement. Citrix le dit lui-même : la mise à jour reste nécessaire partout où c’est possible, et les signatures ne remplacent pas le correctif sur les versions plus anciennes que 73.37/64.23.

Pourquoi ne pas se contenter des signatures

Parce qu’un DoS sur une Gateway exposée, ce n’est pas qu’une question de disponibilité du service — c’est l’accès distant de toute ton organisation qui tombe, potentiellement en pleine journée de production. Entre une fenêtre de maintenance programmée pour la mise à jour et une coupure non planifiée pendant les heures ouvrées, le choix ne devrait pas traîner. Priorise les appliances internet-facing et celles qui portent de l’authentification critique (VPN, SSO) avant les instances internes.

FAQ

Mon NetScaler n’utilise pas SAML, suis-je concerné ?

Non, d’après les informations publiées par Citrix : la précondition d’exploitation est la présence d’une configuration SAML (SP ou IdP) associée à un virtual server Gateway ou AAA. Sans SAML, cette CVE précise ne s’applique pas à ton appliance.

J’ai déjà patché en 14.1-73.37 la semaine dernière, c’est suffisant ?

Non si tu utilises SAML : 73.37 corrige CVE-2026-88771 et CVE-2026-88772, pas CVE-2026-88779. Il faut remonter à 14.1-73.41 (ou 13.1-64.28 côté branche 13.1).

Le DoS peut-il être exploité sans authentification préalable ?

Citrix et CISA n’ont publié aucun détail technique sur le vecteur d’exploitation précis — seule la conséquence (déni de service) est confirmée publiquement à ce stade.

Où trouver l’avis officiel complet ?

Dans l’article de support Citrix CTX697174, qui liste les versions exactes et les instructions de mise à niveau pour chaque branche.

Ce n’est pas la première fois cette année qu’un boîtier d’accès distant très répandu se retrouve dans le viseur de CISA à quelques semaines d’intervalle — Cisco, Citrix et Fortinet avaient déjà cumulé trois entrées au catalogue KEV mi-septembre, et la faille ScreenConnect CVSS 9.9 début octobre suit le même schéma : un outil d’accès à distance massivement déployé, une fenêtre de correction courte imposée par une exploitation active. Si tu administres plusieurs appliances NetScaler, le réflexe à prendre maintenant : grep ta config pour la précondition SAML sur chacune, planifie l’upgrade en priorité sur les appliances exposées, et ne t’arrête pas à la fenêtre de remédiation fédérale du 7 octobre — elle ne concerne que les agences US, pas le niveau de risque réel pour ton infrastructure.

Un client de support à distance compromis ne reste pas un problème isolé : il devient le vecteur qui infecte tous les postes qu’il touche ensuite. C’est exactement ce qui s’est passé avec CVE-2026-84869, la faille CVSS 9.9 corrigée début septembre dans ConnectWise ScreenConnect — un des outils RMM les plus utilisés par les MSP et les équipes IT internes pour le support à distance.

Le vecteur d’attaque, en clair

Techniquement, il s’agit d’une mauvaise gestion des privilèges combinée à une absence de contrôle d’autorisation (improper privilege management / missing authorization) dans le mécanisme de transfert de fichiers de ScreenConnect. Concrètement : un attaquant qui a accès à une session active — parce qu’il a convaincu un utilisateur d’installer un client ScreenConnect « maison » par ingénierie sociale, par exemple — peut pousser des fichiers vers l’hôte distant et déclencher leur exécution sans confirmation de l’opérateur. Pas de popup, pas de validation manuelle : le fichier arrive et s’exécute.

Seul le client est concerné, pas les serveurs ScreenConnect. Toutes les versions antérieures à la 26.6.5, publiée le 8 septembre 2026 et listée sur le Trust Center de ConnectWise, sont vulnérables.

Chronologie du traitement

Le calendrier est serré, ce qui en dit long sur la gravité perçue par les équipes de sécurité :

• 8 septembre 2026 — ConnectWise publie le bulletin de sécurité (Priority 1, le niveau le plus élevé de son échelle interne) et la version corrigée 26.6.5.
• 11 septembre 2026 — la CISA ajoute la faille à son catalogue Known Exploited Vulnerabilities (KEV), aux côtés de deux autres failles activement exploitées.
• 14 septembre 2026 — expiration du délai de remédiation imposé aux agences fédérales américaines (BOD 22-01) : trois jours ouvrés, signe d’une exploitation déjà massive au moment de l’ajout au KEV.

Ce que Huntress a vu sur le terrain

Les équipes de Huntress, citées par Help Net Security, ont documenté plusieurs intrusions construites sur ce même schéma, toutes initiées par de l’ingénierie sociale pour faire installer un client ScreenConnect détourné. Une fois la session active, l’attaque pousse quatre scripts VBScript — nommés sobrement 1.vbs à 4.vbs — chargés de profiler la machine, dissimuler l’activité, effectuer de la reconnaissance système et récupérer des composants supplémentaires. La suite est éloquente : persistance, installation d’instances ScreenConnect additionnelles sur la machine compromise, tunneling réseau, modification des contrôles de sécurité, et dans certains cas du minage de cryptomonnaie.

Le détail le plus préoccupant pour qui gère un parc multi-sites : les clients modifiés propagent ensuite les mêmes scripts aux nouveaux systèmes qu’ils touchent, créant une diffusion de type ver. Un seul poste compromis par social engineering peut donc contaminer en cascade tout un environnement géré à distance.

Comment réagir maintenant

Si ton parc utilise ScreenConnect, l’ordre de priorité est simple :

• Mettre à jour immédiatement tous les clients vers la version 26.6.5, pas seulement le serveur.
• Passer en revue les journaux d’audit ScreenConnect des sept derniers jours à la recherche d’entrées RunFiles/RanFiles associées à des processus invités (guest) — c’est la signature directe de cette technique d’exploitation.
• Chercher spécifiquement des transferts de fichiers .vbs, .js, .ps1 ou .bat initiés hors des opérations de support habituelles.
• Restreindre les permissions de transfert de fichiers aux seuls utilisateurs qui en ont réellement besoin, plutôt que de les laisser ouvertes par défaut à toute session active.
• Pour toute machine où une activité suspecte est confirmée, la réimager à partir d’un support fiable — un nettoyage partiel ne suffit pas face à une persistance de ce niveau.

Si tu es MSP et que ScreenConnect sert à administrer les postes de plusieurs clients, le risque de propagation inter-clients mérite une communication proactive plutôt que d’attendre qu’un incident remonte de lui-même.

FAQ

Les serveurs ScreenConnect sont-ils concernés par cette faille ?

Non, uniquement les clients. Mais la mise à jour des clients reste indispensable sur l’ensemble du parc, pas seulement sur les machines visiblement affectées.

Un antivirus classique aurait-il bloqué cette attaque ?

Pas nécessairement au moment du transfert initial : le fichier arrive via un canal de support légitime et sans confirmation utilisateur. La détection repose davantage sur l’analyse des journaux ScreenConnect et le comportement réseau post-compromission que sur la signature du fichier lui-même.

Comment savoir si mon organisation a déjà été ciblée ?

Cherche dans tes journaux ScreenConnect toute entrée RunFiles/RanFiles initiée par un compte invité plutôt qu’un opérateur authentifié, sur les sept à trente derniers jours selon ta politique de rétention de logs.

Et ensuite

Cette faille s’ajoute à la liste déjà longue des vulnérabilités critiques traitées en urgence ce trimestre — après les failles Cisco, Citrix et Fortinet ajoutées au catalogue CISA KEV mi-septembre et la faille critique GitLab CVSS 10. Le point commun : à chaque fois, l’écart entre divulgation et exploitation active se compte en jours, pas en semaines. Si tu n’as pas encore vérifié la version de tes clients ScreenConnect, c’est le moment de le faire avant de passer à autre chose.

Trois éditeurs, trois pare-feux ou passerelles d’accès, une seule urgence commune : la CISA a ajouté début septembre 2026 des vulnérabilités Cisco, Citrix et Fortinet à son catalogue Known Exploited Vulnerabilities (KEV), avec un délai de correction fixé au 12 septembre 2026 pour les agences fédérales américaines. Ce délai ne s’applique pas à toi si tu n’es pas une agence fédérale US — mais l’exploitation active, elle, ne fait pas de distinction de juridiction.

La plus critique des trois n’a même pas besoin qu’on discute de son score : CVSS 10.0, le maximum de l’échelle. Détail de ce qu’il faut corriger, et dans quel ordre.

CVE-2026-20079 : Cisco Secure FMC, root sans authentification

La faille touche Cisco Secure Firewall Management Center (toutes versions antérieures aux correctifs listés ci-dessous) ainsi que la gestion de pare-feu via Security Cloud Control (SCC). Elle ne concerne pas Firewall Device Manager, ASA, FTD ni SCC Defense Orchestrator — si tu gères tes pare-feux Cisco uniquement via FDM, tu n’es pas dans le périmètre de cette CVE précise (mais garde un œil sur les autres).

Le problème : un attaquant non authentifié peut contourner l’authentification de l’interface web et exécuter des scripts avec des privilèges root. Pas de contournement de configuration possible — l’avis officiel Cisco est catégorique : aucun workaround, seule la mise à jour logicielle corrige le problème. La vulnérabilité était en fait publiée depuis le 4 mars 2026, mais son exploitation active n’a été confirmée qu’en août, avec trois clusters de post-compromission identifiés déployant web shells et malwares.

Version installée	Corrigée à partir de
7.0 et antérieures	7.0.10
7.2	7.2.12
7.4	7.4.8
7.6	7.6.6
7.7	7.7.13
10.0	10.0.2
10.1	10.1.0

Si ton FMC n’a pas reçu de mise à jour depuis mars, ce n’est plus une tâche de maintenance planifiable au prochain sprint. C’est un patch d’urgence, au même titre que ce qu’on décrivait pour la faille GitLab CVSS 10 de septembre — même score, même logique : root ou accès administrateur sans mot de passe valide, ça ne se traite pas en fin de semaine.

CVE-2026-19490 : Citrix NetScaler, l’autre porte d’entrée

Deuxième dossier, chez Citrix cette fois : CVE-2026-19490 (score CVSS 9.3, contournement d’authentification) et sa voisine CVE-2026-19489 (score 8.8, dépassement de mémoire tampon) touchent NetScaler ADC et NetScaler Gateway configurés en serveur AAA ou Gateway, y compris les déploiements Secure Private Access Hybrid qui s’appuient sur des instances NetScaler.

Versions concernées et correctifs, d’après le bulletin de sécurité officiel Citrix (publié le 19 août 2026) :

• NetScaler ADC/Gateway 14.1 antérieur à 14.1-73.32 → corrigé en 14.1-73.32
• NetScaler ADC/Gateway 13.1 antérieur à 13.1-63.21 → corrigé en 13.1-63.21
• Variantes FIPS 14.1 antérieures à 14.1-73.32 FIPS → corrigées en 14.1-73.32 FIPS
• Variantes FIPS/NDcPP 13.1 antérieures à 13.1-37.277 → corrigées en 13.1-37.277

La CISA a recensé 56 tentatives d’exploitation via honeypot depuis le 3 septembre, dont 36 en une seule journée le 8 septembre — la courbe monte, elle ne redescend pas. Si ton NetScaler expose une interface de gestion ou un portail Gateway côté internet sans être à jour, ce n’est plus une question de « si » mais de « quand ».

CVE-2025-25249 : la doyenne, mais toujours active

La troisième CVE de la liste, CVE-2025-25249 (CVSS 7.3, dépassement de tampon basé sur le tas), touche FortiOS, FortiSwitchManager et FortiSASE, avec un risque d’exécution de code à distance. Contrairement aux deux précédentes, cette faille est plus ancienne — mais elle reste activement exploitée depuis juillet 2026 pour déployer le malware PivotC2, avec plus de 3 000 adresses IP visées et 178 appareils confirmés infectés. Les acteurs identifiés sont majoritairement russophones.

Score plus bas que les deux autres, certes, mais ne t’y trompe pas : une backdoor persistante sur un pare-feu périmétrique vaut largement le déplacement, même à CVSS 7.3.

Ce que ça dit de la tendance 2026

Trois vulnérabilités, trois éditeurs différents, tous dans la même famille de produits : des équipements de sécurité périmétrique — pare-feu, passerelle d’accès distant, gestion de firewall. Le motif se répète depuis le début de l’année : les attaquants ciblent en priorité les briques censées protéger le réseau, précisément parce qu’elles sont exposées sur internet et détiennent des privilèges élevés une fois compromises. Un contournement d’authentification sur un firewall manager, c’est directement les clés du réseau — pas une simple fuite d’information à corriger « quand on aura le temps ».

Si ton organisation applique déjà une cadence de patch mensuelle façon Patch Tuesday, ces trois CVE ne rentrent pas dans ce cycle : une exploitation active confirmée par la CISA justifie un correctif hors cycle, dans les jours qui suivent l’alerte, pas au prochain calendrier de maintenance.

FAQ

Comment savoir si mon FMC ou mon NetScaler a déjà été compromis ?

Cisco et Citrix publient tous les deux des indicateurs de compromission dans leurs avis respectifs (logs d’authentification anormaux, fichiers webshell déposés, comptes créés hors process). Vérifie en priorité les connexions administratives depuis des IP inhabituelles sur les fenêtres correspondant aux dates d’exploitation active mentionnées (août 2026 pour Cisco, début septembre pour Citrix).

Le patch seul suffit-il, ou faut-il aussi vérifier une compromission préalable ?

Le patch corrige la vulnérabilité, pas une éventuelle compromission déjà en place. Si ton équipement était exposé et non patché avant l’alerte, une vérification de compromission (logs, intégrité des fichiers, comptes administrateurs) est indispensable avant de considérer l’incident clos.

Ces CVE concernent-elles aussi les petites structures, ou seulement les grandes entreprises ?

L’exploitation observée par la CISA (honeypots, campagnes à large échelle façon PivotC2) cible des IP exposées sans distinction de taille d’organisation. Un NetScaler ou un FMC non patché reste une cible, quel que soit l’effectif derrière.

Faut-il redémarrer les équipements après le correctif ?

Ça dépend de la version et du mode de mise à jour (mise à jour à chaud vs. remplacement d’image) — suis strictement la procédure indiquée dans l’avis de sécurité de l’éditeur concerné plutôt qu’une procédure générique, les impacts de service diffèrent d’un produit à l’autre.

Dans les trois cas, la marche à suivre est la même : vérifie ta version installée, compare-la à la table des correctifs, et planifie la mise à jour hors cycle si tu es exposé. Un firewall ou une passerelle qui protège ton réseau ne doit jamais être, lui-même, le point d’entrée le plus simple.

Si tu gères une instance GitLab self-managed (Community ou Enterprise Edition), il y a de fortes chances que tu aies déjà vu passer une alerte cette semaine : CVE-2026-85706, une faille de traversée de répertoire notée 10.0 sur 10 à l’échelle CVSS — le score maximal possible. Elle permet à un attaquant non authentifié de lire n’importe quel fichier sur ton serveur, y compris du code source et des identifiants, avec une simple requête HTTP. Elle est activement exploitée, elle figure dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA, et GitLab a publié un correctif d’urgence le 10 septembre 2026.

Si ce n’est pas déjà fait, ce qui suit est prioritaire sur à peu près tout le reste de ta liste de tâches du jour.

Ce que fait exactement la faille

CVE-2026-85706 se situe dans l’API des commits de dépôt de GitLab. Le problème vient d’un défaut de confinement de chemin combiné à une absence de vérification d’authentification sur cet endpoint : un attaquant peut construire une requête qui sort du répertoire attendu pour aller lire des fichiers arbitraires sur le système de fichiers du serveur — configuration, clés, code source privé, tout ce qui est accessible au compte de service GitLab.

Contrairement à beaucoup de vulnérabilités « critiques » qui nécessitent des conditions particulières pour être exploitables, celle-ci ne demande aucune authentification préalable. C’est ce qui explique à la fois le score CVSS maximal et la vitesse à laquelle l’exploitation active a démarré : des chercheurs ont observé du sondage actif dans les jours qui ont suivi la publication du correctif, le temps que les attaquants fassent de la rétro-ingénierie du patch pour reconstruire l’exploit.

Es-tu concerné ?

La faille touche les déploiements self-managed uniquement :

• GitLab CE/EE versions 18.7 à 19.1 (avant 19.1.8)
• GitLab CE/EE versions 19.2 (avant 19.2.6)
• GitLab CE/EE versions 19.3 (avant 19.3.2)

Tous les modes d’installation sont concernés — Omnibus, installation depuis les sources, Helm chart. GitLab.com et les instances Dedicated sont déjà protégées côté GitLab, tu n’as rien à faire pour ces offres managées. Si tu héberges toi-même ton instance, en revanche, la responsabilité du correctif t’incombe entièrement.

Comment corriger

Mets à jour vers l’une des versions patchées selon ta branche actuelle :

# Vérifie ta version actuelle
sudo gitlab-rake gitlab:env:info

# Cible une des versions corrigées selon ta branche
# 19.1.x -> 19.1.8
# 19.2.x -> 19.2.6
# 19.3.x -> 19.3.2

GitLab est explicite sur ce point dans son avis de sécurité officiel : toutes les installations concernées doivent être mises à niveau vers la dernière version dès que possible, en dehors du cycle de correctifs habituel si nécessaire. Ce patch corrige aussi 19 autres vulnérabilités dans la même publication, dont deux autres failles critiques (désérialisation GraphQL et un dépassement de tampon) — une bonne raison supplémentaire de ne pas traîner.

Point opérationnel à anticiper : le correctif inclut des migrations de base de données. Sur une installation mono-nœud, ça se traduit par une interruption de service pendant la mise à jour. Si tu es en configuration multi-nœuds, tu peux appliquer la procédure de mise à niveau zéro downtime documentée par GitLab pour éviter la coupure.

Si tu ne peux pas patcher immédiatement

Une mise à jour d’urgence n’est pas toujours possible dans l’instant, surtout un week-end ou sur une instance avec des dépendances lourdes. En attendant de patcher :

• Restreins l’exposition réseau de ton instance GitLab à un VPN ou une liste d’IP de confiance si ce n’est pas déjà le cas — cette faille ne nécessitant aucune authentification, réduire la surface réseau exposée limite directement le risque
• Surveille tes logs d’accès pour des motifs de requêtes suspectes sur l’API des commits (séquences `../` ou équivalents encodés dans les paramètres d’URL)
• Considère une règle WAF temporaire bloquant les tentatives de traversée de chemin sur les endpoints de l’API des commits, en sachant que ce n’est qu’une mesure d’atténuation, pas un correctif

Aucune de ces mesures ne remplace la mise à jour — elles réduisent la fenêtre de risque, elles ne la ferment pas.

Après le patch : ne t’arrête pas là

Vu la nature de la faille — lecture arbitraire de fichiers, potentiellement des identifiants ou des clés — patcher ne suffit pas si ton instance a été exposée avant la mise à jour. Il est recommandé de traiter cet incident comme une possible compromission :

• Fais tourner (rotate) les secrets et identifiants stockés sur le serveur : clés SSH de déploiement, tokens d’intégration, secrets de variables CI/CD
• Vérifie tes logs d’accès sur la période où ton instance a été exposée pour repérer des requêtes anormales vers l’API des commits
• Si tu disposes d’outils de détection, des règles Sigma et Suricata/Snort spécifiques à cette CVE circulent déjà dans la communauté sécurité pour faciliter la chasse aux indicateurs de compromission

Ce réflexe « patch + rotation + vérification des logs » rejoint directement la logique qu’on avait détaillée pour le Patch Tuesday de septembre : une faille critique activement exploitée se traite comme un incident potentiel, pas comme une simple case à cocher dans un tableau de suivi de patchs.

FAQ

GitLab.com est-il concerné ?

Non. GitLab.com et les instances GitLab Dedicated sont des offres managées par GitLab et ont déjà été protégées côté éditeur. Seules les instances self-managed (que tu héberges et administres toi-même) nécessitent une action de ta part.

Comment savoir si mon instance a déjà été ciblée ?

Recherche dans tes logs d’accès des requêtes vers l’API des commits contenant des séquences de traversée de chemin (`../` ou leurs variantes encodées en URL) sur la période depuis la divulgation de la faille début septembre. Des scanners de détection dédiés à cette CVE sont disponibles publiquement si tu veux automatiser cette recherche.

La CISA impose-t-elle un délai pour ce correctif ?

La CISA a fixé une échéance de remédiation obligatoire au 14 septembre 2026, mais uniquement pour les agences fédérales américaines relevant de sa directive opérationnelle contraignante. Pour toute autre organisation, il n’y a pas d’obligation légale liée à la CISA — ce qui ne change rien à l’urgence réelle, vu l’exploitation active confirmée.

En résumé

Un CVSS de 10.0 combiné à une exploitation active et une absence totale de prérequis d’authentification, c’est la définition même d’une urgence à traiter en dehors des fenêtres de maintenance habituelles. Si tu gères une instance GitLab self-managed en version 19.3.1 ou antérieure, vérifie ta version dès maintenant, planifie la fenêtre de mise à jour si tu es en mono-nœud, et prévois la rotation de tes secrets si l’exposition a duré plus de quelques heures depuis la divulgation.

Le Patch Tuesday de septembre 2026 vient de battre un record peu enviable : 974 vulnérabilités corrigées en un seul mois, dont deux zero-days activement exploités. Si tu gères des serveurs Windows, des contrôleurs de domaine ou de l’infrastructure Azure, voici ce qu’il faut retenir pour prioriser tes déploiements sans te noyer dans la liste complète des CVE.

Un volume de correctifs inédit

Microsoft a corrigé 974 failles ce mois-ci, contre 570 en juillet et 400 en août 2026 — une hausse en partie attribuée au déploiement d’un système de découverte de vulnérabilités assisté par IA côté Microsoft. La répartition donne une idée de l’ampleur : 113 vulnérabilités critiques et 860 importantes, avec 253 failles d’exécution de code à distance (RCE) et 438 d’élévation de privilèges. Les zones les plus touchées : composants Windows (Hyper-V, DNS Server, ALPC), Office, SQL Server, Exchange Server, et les services cloud (Entra ID, Azure).

Les deux zero-days activement exploités

Deux failles sont d’ores et déjà exploitées dans la nature — c’est elles qu’il faut patcher en tout premier, avant même de regarder le reste de la liste.

CVE-2026-81963 — Windows Update Stack, élévation de privilèges

Une faille de résolution de lien qui permet à un attaquant d’obtenir des privilèges SYSTEM. C’est la première vulnérabilité d’élévation de privilèges du Windows Update Stack exploitée dans la nature depuis 2022 — un composant qui, par nature, tourne avec des droits élevés sur quasiment toutes les machines Windows du parc.

CVE-2026-85880 — Windows ALPC, élévation de privilèges

Un dépassement de tampon basé sur le tas (heap overflow) dans l’Advanced Local Procedure Call de Windows, exploitable localement pour obtenir SYSTEM. C’est le premier correctif touchant l’ALPC en plus de trois ans, et le deuxième zero-day sur ce composant depuis janvier 2023 — un signal que cette surface d’attaque reste activement ciblée par les chercheurs offensifs comme par les attaquants.

Les autres CVE critiques à ne pas laisser traîner

• CVE-2026-69730 — Windows DNS Server, RCE, CVSS 9.8, « exploitation plus probable » selon Microsoft. Si tu exposes un DNS Server Windows, en particulier sur un contrôleur de domaine, ce correctif passe avant tout le reste.
• CVE-2026-69676 — Windows Kerberos, RCE, CVSS 8.8. Kerberos étant au cœur de l’authentification Active Directory, une exploitation réussie a un impact potentiellement massif sur l’ensemble du domaine.

Comment prioriser sans tout patcher en urgence le même jour

Avec près de 1000 correctifs, il est illusoire de vouloir tout déployer en une nuit. Voici l’ordre de priorité qui ressort de l’analyse des éditeurs de sécurité (Qualys, Tenable, CrowdStrike) :

1. Immédiat : les deux zero-days (CVE-2026-81963 et CVE-2026-85880) sur l’ensemble du parc Windows, en particulier les machines avec des privilèges élevés ou exposées à des réseaux non fiables. Priorité absolue aux contrôleurs de domaine et à l’infrastructure d’authentification, puisque l’ALPC touche des processus Windows centraux.
2. Haute priorité : les RCE critiques exposées côté réseau — DNS Server (CVE-2026-69730) et Kerberos (CVE-2026-69676) — ainsi qu’Exchange Server et les applications Office directement exposées à du contenu externe.
3. Priorité secondaire : élévations de privilèges locales sans exploitation connue, divulgations d’information, et vulnérabilités de déni de service.

Comme toujours sur un volume aussi important, teste en environnement non-production avant un déploiement large, surtout pour les correctifs touchant des composants aussi sensibles que l’ALPC ou le DNS Server.

Automatiser le déploiement plutôt que courir après chaque Patch Tuesday

Si ton parc de postes Windows dépend encore de campagnes de patch manuelles, c’est le bon moment pour regarder du côté de Windows Autopatch, qui gère désormais le hotpatching par défaut et priorise automatiquement les correctifs de sécurité critiques sans redémarrage complet pour une bonne partie des CVE mensuelles — on en parlait plus en détail dans notre article sur l’évolution d’Intune et du bundling M365 E3/E5. Pour les contrôleurs de domaine et l’infrastructure Windows Server, notre guide sur les changements sécurité d’Active Directory dans Windows Server 2025 complète bien la priorisation ci-dessus.

FAQ

Faut-il patcher en urgence même hors fenêtre de maintenance habituelle ?

Pour les deux zero-days activement exploités, oui — un déploiement hors cycle est justifié sur les systèmes à risque (contrôleurs de domaine, serveurs exposés), quitte à planifier un redémarrage en heures creuses plutôt que d’attendre la prochaine fenêtre mensuelle.

Le volume record de ce mois signifie-t-il que Windows est devenu moins sûr ?

Pas nécessairement — la hausse est en grande partie due à l’intensification des efforts de découverte de vulnérabilités par Microsoft lui-même (recherche interne assistée par IA), ce qui tend plutôt à réduire le nombre de failles non découvertes exploitables par des tiers. Ça ne change rien à l’urgence de patcher, en revanche.

Où suivre les détails techniques de chaque CVE ?

Le security update guide officiel de Microsoft reste la référence pour le détail CVE par CVE ; les analyses d’éditeurs comme Tenable ou Qualys sont utiles pour une lecture priorisée rapide.

En résumé

Deux CVE à patcher aujourd’hui (CVE-2026-81963, CVE-2026-85880), deux RCE critiques à ne pas laisser traîner plus de quelques jours (DNS Server, Kerberos), et un volume global qui justifie plus que jamais un déploiement automatisé et priorisé plutôt qu’une gestion manuelle mois par mois. Si ce n’est pas déjà fait, c’est l’occasion de vérifier que ton dispositif de patch management priorise automatiquement les CVE avec exploitation active — c’est ce qui fait la différence entre un incident évité et un incident subi.

Si tu attends que la loi française de transposition de NIS2 soit votée pour t’en préoccuper, tu risques d’attendre longtemps — et de te retrouver à traiter dans l’urgence ce que tu aurais pu lisser sur plusieurs mois. Le texte accumule les reports depuis 2024, mais la directive européenne, elle, est déjà en vigueur, et tes clients ou donneurs d’ordre te demandent probablement déjà des garanties. Dans cet article, tu vas voir où en est exactement la loi en septembre 2026, qui sera concerné, quelles obligations concrètes t’attendent, et surtout ce que tu peux commencer à mettre en place dès aujourd’hui, indépendamment du calendrier parlementaire.

NIS2, un rappel en une minute

NIS2 (Network and Information Security 2) est la directive européenne (UE) 2022/2555 qui remplace la première directive NIS de 2016. Elle élargit fortement le périmètre des organisations concernées par des obligations de cybersécurité — on passe d’environ 500 entités régulées en France sous NIS1 à plusieurs milliers sous NIS2 — et durcit les obligations : gestion des risques, notification d’incidents, sécurité de la chaîne d’approvisionnement, et responsabilité personnelle des dirigeants en cas de manquement grave.

Le délai de transposition fixé par l’Union européenne était le 17 octobre 2024. La France ne l’a pas tenu, et ce n’est pas un cas isolé : plusieurs États membres sont dans la même situation. Ça ne dispense personne des obligations de fond, qui découlent directement de la directive.

Où en est réellement la loi française en septembre 2026 ?

C’est le point que beaucoup d’admins et de RSSI ont du mal à suivre, tant le calendrier a glissé. Voici l’état des lieux :

• Octobre 2024 : présentation du projet de loi de résilience (qui transpose NIS2 et intègre aussi une partie du règlement DORA) en Conseil des ministres.
• 12 mars 2025 : adoption du texte par le Sénat en première lecture.
• Septembre 2025 : fin de l’examen en commission spéciale à l’Assemblée nationale.
• Été 2026 : le texte n’est finalement pas inscrit à l’ordre du jour de la session extraordinaire de juillet — nouveau report.
• Septembre 2026 : un passage en séance publique à l’Assemblée est de nouveau annoncé, avec une promulgation qui pourrait suivre rapidement si le texte n’est pas trop amendé.

Pendant ce temps, l’ANSSI n’a pas attendu le vote pour avancer sur le terrain technique : elle a publié en mars 2026 le référentiel ReCyF (Référentiel Cyber France), qui détaille une vingtaine d’objectifs de sécurité, et elle a ouvert la plateforme MonEspaceNIS2, qui permet à toute organisation de simuler son éligibilité et de s’enregistrer en amont. Concrètement : le texte de loi n’est pas encore promulgué, mais l’écosystème (ANSSI, secteurs régulés, grands donneurs d’ordre) fonctionne déjà largement comme si NIS2 s’appliquait.

Qui sera concerné : entités essentielles, importantes… et ta collectivité

Le texte français distingue deux catégories, reprises de la directive :

• Entités essentielles : grandes entreprises (250 salariés ou plus, ou plus de 50 M€ de chiffre d’affaires) dans les secteurs à très forts enjeux — énergie, transport, banque, santé, eau, infrastructures numériques, administration publique.
• Entités importantes : entreprises moyennes (50 salariés ou plus, ou plus de 10 M€ de chiffre d’affaires) dans ces mêmes secteurs, ou grandes entreprises dans des secteurs jugés moins critiques — postal, gestion des déchets, chimie, agroalimentaire, fabrication industrielle, services numériques.

Particularité française : le texte étend le périmètre aux collectivités territoriales de plus de 30 000 habitants, ce qui change la donne pour pas mal d’équipes IT de collectivités qui ne se sentaient pas concernées jusque-là.

Si tu es prestataire ou sous-traitant d’une entité régulée sans l’être toi-même directement, ne te crois pas hors sujet pour autant : la sécurité de la chaîne d’approvisionnement fait partie des obligations, ce qui veut dire que tes clients vont te demander des garanties contractuelles bien avant que la loi ne t’impose quoi que ce soit en direct.

Les obligations concrètes qui t’attendent

Les dix familles de mesures minimales

Le texte prévoit dix familles de mesures de sécurité à mettre en œuvre, de façon proportionnée à la taille et à la criticité de l’entité :

• Analyse des risques et politique de sécurité des systèmes d’information
• Gestion des incidents
• Continuité d’activité (sauvegardes, reprise après sinistre, gestion de crise)
• Sécurité de la chaîne d’approvisionnement
• Sécurité de l’acquisition, du développement et de la maintenance des systèmes
• Évaluation de l’efficacité des mesures de gestion des risques
• Hygiène informatique de base et formation à la cybersécurité
• Politiques de cryptographie
• Sécurité des ressources humaines et gestion des accès
• Authentification multifacteur et solutions de communication sécurisées

Notification d’incident : le calendrier qui ne pardonne pas

Autre point à anticiper dès maintenant, indépendamment du vote de la loi : le rythme de notification d’un incident significatif. Il faut compter une alerte précoce sous 24h, une notification complète sous 72h, puis un rapport final sous un mois. Ça suppose d’avoir déjà, avant l’incident, une procédure claire et testée — pas quelque chose que tu improvises le jour J.

Côté sanctions, le texte prévoit des montants dissuasifs : jusqu’à 10 M€ ou 2 % du chiffre d’affaires mondial pour les entités essentielles, 7 M€ ou 1,4 % pour les entités importantes, avec en plus des pouvoirs de suspension, d’injonction, et une responsabilité personnelle possible des dirigeants.

Comment t’y préparer dès maintenant, sans attendre le vote définitif

La bonne nouvelle, c’est qu’aucune des actions ci-dessous n’est perdue si la loi change encore de forme d’ici sa promulgation — ce sont des fondamentaux de sécurité que tu as intérêt à avoir de toute façon.

1. Vérifie ton statut sur MonEspaceNIS2

Le simulateur d’éligibilité de l’ANSSI te donne en quelques minutes une première indication de ta catégorie probable (essentielle, importante, ou hors périmètre). Ça t’évite de mobiliser du temps sur un sujet qui, potentiellement, ne te concerne pas encore directement.

2. Cartographie ton SI et tes fournisseurs

C’est le prérequis à peu près à toutes les mesures qui suivent : tu ne peux pas gérer un risque que tu n’as pas identifié. Liste tes systèmes critiques, leurs interdépendances, et surtout tes prestataires externes (hébergeur, éditeurs SaaS, intégrateurs) — c’est souvent le point aveugle.

3. Généralise le MFA avant qu’on te l’impose

L’authentification multifacteur fait partie des dix familles de mesures, et c’est aussi l’un des contrôles avec le meilleur rapport effort/protection contre les compromissions de comptes. Si tu es sur Microsoft Entra ID, le changement d’enforcement Conditional Access de juin 2026 pousse déjà dans ce sens côté Microsoft. Pour auditer rapidement qui n’a pas encore de méthode MFA robuste enregistrée dans ton tenant, un script PowerShell avec le module Microsoft Graph fait le travail :

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All", "User.Read.All"

Get-MgUser -All -Property Id, DisplayName, UserPrincipalName | ForEach-Object {
    $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
    $hasStrongMfa = $methods | Where-Object {
        $_.AdditionalProperties["@odata.type"] -match "microsoftAuthenticatorAuthenticationMethod|fido2AuthenticationMethod|windowsHelloForBusinessAuthenticationMethod"
    }
    [PSCustomObject]@{
        Utilisateur = $_.UserPrincipalName
        MfaRobuste  = [bool]$hasStrongMfa
    }
} | Where-Object { -not $_.MfaRobuste } | Export-Csv "audit-mfa-faible.csv" -NoTypeInformation -Encoding UTF8

La documentation complète de la cmdlet Get-MgUserAuthenticationMethod est disponible sur Microsoft Learn.

4. Durcis tes environnements techniques

Si une partie de ton infrastructure tourne sur Kubernetes, la sécurisation du cluster (RBAC, network policies, gestion des secrets, images signées) rentre directement dans les mesures de sécurité du développement et de la maintenance des systèmes exigées par NIS2. Notre guide complet pour sécuriser un cluster Kubernetes couvre ces points un par un si tu veux avancer concrètement sur ce chantier.

FAQ

NIS2 s’applique-t-elle déjà en France si la loi n’est pas votée ?

La directive européenne est en vigueur depuis 2023, mais elle ne devient contraignante en droit français qu’une fois transposée par une loi nationale. Tant que le texte n’est pas promulgué, il n’y a pas encore de base légale française pour sanctionner un manquement au titre de NIS2 spécifiquement. En revanche, des obligations proches existent déjà par ailleurs (LPM pour les OIV, RGPD pour les données personnelles), et attendre la loi pour agir revient à se donner très peu de temps une fois qu’elle sera votée.

Comment savoir si mon organisation est une entité essentielle ou importante ?

Le simulateur d’éligibilité de MonEspaceNIS2 est le point de départ le plus fiable, en croisant ton secteur d’activité, ta taille et ton chiffre d’affaires avec les annexes de la directive.

Le MFA seul suffit-il à être conforme ?

Non. C’est une des dix familles de mesures, pas la seule. La conformité suppose une démarche globale — analyse de risques, continuité d’activité, sécurité fournisseurs, etc. — mais le MFA reste un des contrôles les plus rapides à déployer largement et l’un de ceux qui réduisent le plus vite la surface d’attaque réelle.

En résumé

La loi française traîne, mais ni les obligations de fond de NIS2, ni la pression commerciale de tes clients et donneurs d’ordre n’attendent le vote définitif. Utilise ce délai à ton avantage : cartographie ton SI, généralise le MFA, avance sur le durcissement de tes environnements techniques, et suis l’avancement du texte via le site de l’ANSSI. Le jour où la loi sera promulguée, tu seras déjà bien avancé plutôt qu’en train de découvrir le sujet.