12 min de lectureIdentité et accès
Le 6 novembre 2026, la CISA a ajouté la CVE-2026-19868 à son catalogue KEV (Known Exploited Vulnerabilities), sur la foi d’éléments attestant une exploitation active. La faille touche le composant SSLVPN de SonicWall SonicOS. La CISA la classe en « Use of Single-factor Authentication », c’est-à-dire le recours à une authentification à facteur unique. Sur une passerelle d’accès distant, cette classification désigne une faiblesse dans le contrôle même que l’authentification multifacteur (MFA) est censée assurer.
La même semaine, OpenSSH a publié en urgence des correctifs pour « SSHole » (CVE-2026-123158, score CVSS 8,1). Sur certains systèmes Linux, cette faille permet à des comptes d’accepter n’importe quel mot de passe de 257 à 1 024 caractères. Le CERT-FR a publié une alerte à ce sujet le 5 novembre et l’a mise à jour le 6 novembre.
Les deux failles diffèrent par le produit, le mécanisme et le statut d’exploitation. Elles partagent pourtant un trait qui doit interpeller toute instance dirigeante : dans les deux cas, le contrôle d’authentification semblait en place. Une revue de configuration aurait constaté que la MFA était activée sur le VPN. Elle aurait constaté que l’authentification par mot de passe était encadrée par une politique sur le serveur SSH. Aucune de ces revues n’aurait révélé que le contrôle pouvait céder. Le sujet concerne les RSSI, les DSI, les directions des risques et de la conformité, ainsi que les membres des conseils d’administration des organisations régulées. Les passerelles d’accès distant et les accès d’administration SSH comptent parmi les points d’entrée les plus sensibles d’un système d’information. Au titre de l’article 20 de NIS2, les organes de direction des entités essentielles et importantes doivent approuver et superviser les mesures qui les protègent.
La plupart des organisations rendent compte de leur maturité en authentification sous forme de déclarations. La MFA est activée pour les accès distants. Le SSO est imposé par un fournisseur d’identité. Des politiques de mots de passe sont définies sur les serveurs. Ces affirmations alimentent les rapports d’audit, les registres de risques et les tableaux de bord du conseil. En tant que description de la configuration, elles sont généralement exactes.
Les failles de cette semaine montrent l’écart entre configuration et comportement. Une passerelle censée exiger plusieurs facteurs, mais affectée d’une faiblesse classée « authentification à facteur unique », n’impose pas la MFA de manière fiable. Un contrôle de mot de passe qui accepte n’importe quelle chaîne d’une certaine longueur ne contrôle pas les mots de passe. La configuration continue d’afficher la bonne réponse. Le système, lui, fait autre chose.
À retenir pour la direction : « MFA activée » et « politique de mots de passe SSH définie » décrivent ce que l’organisation a voulu. Ces mentions ne prouvent pas ce que fait le système lorsque quelqu’un tente de se connecter. Le conseil doit les traiter comme des affirmations à vérifier, non comme des preuves.
Il s’agit davantage d’un problème de gouvernance des identités que d’un problème de correctifs. Le correctif ferme ces deux failles précises. Il ne change pas la manière dont l’organisation sait si son authentification fonctionne, et cette question se reposera à la prochaine faille.
L’alerte de la CISA donne l’essentiel. La CVE-2026-19868 est une vulnérabilité du SSLVPN de SonicOS, classée comme recours à une authentification à facteur unique. Elle a été inscrite au catalogue KEV en raison d’éléments attestant une exploitation active. La CISA rappelle que ce type de faille constitue un vecteur d’attaque fréquent pour les acteurs malveillants.
C’est la classification qui compte pour la gouvernance. Beaucoup d’organisations déclarent une MFA sur tous les accès distants. Pour elles, une faiblesse exploitée de ce type sur le VPN correspond exactement au scénario que leurs tableaux de bord présentent comme impossible. Le détail des conditions relève du bulletin de l’éditeur. Le propriétaire de la passerelle doit confronter ce bulletin à la configuration de l’organisation, plutôt que de s’en remettre à des résumés.
Deux points méritent d’être soulignés. D’abord, une connexion à facteur unique suppose toujours que l’attaquant détienne un facteur, en général un identifiant. Ce n’est pas rassurant pour autant. Le vol et la réutilisation d’identifiants sont courants, et la MFA existe précisément parce que les mots de passe fuitent. Ensuite, aucune des sources dont nous disposons n’attribue cette exploitation à un acteur nommé, et cet article ne le fait pas davantage.
En vertu de la directive opérationnelle contraignante (BOD) 26-04, les agences fédérales civiles américaines doivent traiter en priorité les vulnérabilités KEV présentes sur des actifs exposés publiquement et qui donnent un contrôle total après exploitation. La CISA encourage toutes les organisations à adopter une gestion des vulnérabilités fondée sur le risque et à prioriser les entrées du catalogue KEV. La directive ne s’impose pas aux entités européennes. Sa logique de priorisation reste néanmoins pertinente pour elles.
Selon SecurityWeek, SSHole touche sshd sur les distributions Linux qui utilisent la bibliothèque musl libc avec PAM désactivé. Sur ces systèmes, certains comptes acceptent n’importe quel mot de passe de 257 à 1 024 caractères. La cause est décrite comme une erreur d’interprétation : le système se trompe sur le fait qu’une chaîne doive ou non être traitée comme une empreinte de mot de passe. Damien Miller, développeur d’OpenSSH, précise que la faille ne se situe pas dans sshd lui-même, mais qu’elle peut être exploitée par son intermédiaire. Les correctifs sont disponibles dans OpenSSH 10.6p2.
Le CERT-FR a publié l’alerte CERTFR-2026-ALE-015, signalée comme alerte en cours. Sa mise à jour du 6 novembre donne l’identifiant CVE et indique qu’Alpine a publié un bulletin de sécurité. Le CERT-FR insiste également sur la prudence nécessaire lors de toute installation de correctif ou modification de configuration.
Aucune des sources consultées ne confirme une exploitation de SSHole, et aucune ne signale d’organisation touchée en France. La faille importe par sa nature, non par des attaques observées. Elle se loge dans l’étape d’authentification la plus élémentaire d’un serveur, et une revue de configuration classique ne la détecterait pas.
Point clé : L’une des failles est exploitée, l’autre ne l’est pas à ce jour. Toutes deux montrent qu’un contrôle d’authentification peut être correctement configuré et céder malgré tout. Les seules preuves de configuration ne suffisent donc pas à établir que l’authentification est effective.
L’authentification cède rarement là où la politique est définie. Elle cède aux jointures :
Les passerelles d’accès distant acceptent souvent plusieurs méthodes de connexion et plusieurs facteurs en parallèle. Le contrôle ne tient que si l’exigence la plus forte ne peut pas être contournée par une voie voisine plus faible. La CVE-2026-19868 illustre l’enjeu lorsque cette hypothèse tombe : une passerelle censée imposer plus d’un facteur présente une faiblesse exploitée, classée « authentification à facteur unique ». Dans le cas de SSHole, un contrôle de mot de passe dépend de la manière dont un composant de plus bas niveau interprète des données. Cette dépendance n’apparaît que sur certaines combinaisons de plateforme, ici musl libc sans PAM.
Aucune de ces défaillances n’apparaît dans un document de politique, un export de configuration ou un questionnaire de conformité. Chacune ne se révèle que lorsque quelqu’un tente de s’authentifier d’une manière que le contrôle devrait refuser, et observe s’il refuse effectivement.
Implication de sécurité : Chaque chemin d’authentification exposé sur internet doit faire l’objet de tests négatifs, et pas seulement positifs. Vérifier qu’un utilisateur légitime muni de la MFA peut se connecter ne suffit pas. L’organisation doit aussi vérifier qu’un utilisateur ne disposant que d’un seul facteur, ou d’identifiants destinés à une autre méthode de connexion, ne le peut pas.
La plupart des audits de contrôle d’accès reposent sur des preuves de conception et de configuration. Les auditeurs échantillonnent des paramètres, examinent les politiques, vérifient que la MFA est « active » pour une population d’utilisateurs et s’assurent qu’un processus de gestion des correctifs existe. Cette approche est efficace et nécessaire. Elle détecte mal, en revanche, les contrôles correctement configurés mais qui se comportent mal.
Trois habitudes creusent l’écart.
Le cas SSHole ajoute une dimension liée aux plateformes. Les images de conteneurs et les distributions Linux allégées peuvent embarquer des bibliothèques système différentes de celles des distributions serveur courantes. Une organisation peut ignorer où tourne musl libc, ou sur quels systèmes PAM est désactivé. Ces choix ont été faits à la construction des images, par des équipes extérieures à la fonction sécurité.
D’après Security Affairs, l’article 20 de NIS2 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques de cybersécurité et d’en superviser la mise en œuvre. Leur responsabilité peut être engagée en cas de manquement, dans les conditions prévues par le droit national. L’obligation s’applique désormais dans la majeure partie de l’Union. En juillet, quatre États membres ont été renvoyés devant la Cour de justice pour ne pas avoir notifié une transposition complète.
L’article s’appuie sur un rapport consacré à la gestion des accès, publié par Passwork, un éditeur du secteur. Il doit donc être lu comme une source commerciale. Dans ce rapport, des représentants de deux autorités nationales de cybersécurité et des responsables sécurité indépendants décrivent une évolution : les conseils demandent désormais la preuve que les contrôles fonctionnent, là où ils se contentaient autrefois d’un résumé de la politique.
Cette évolution colle de près aux failles de la semaine. Prenons un conseil qui approuve « la MFA sur tous les accès distants », puis reçoit un tableau de bord confirmant que la MFA est activée. Il a approuvé une politique. Il n’en a pas supervisé la mise en œuvre au sens qui compte. Superviser, c’est demander comment l’organisation sait que le contrôle fonctionne, qui l’a vérifié, quand, et avec quel résultat.
Point de décision : Les organes de direction doivent arrêter le niveau de preuve qu’ils acceptent pour les contrôles d’authentification des chemins exposés sur internet et des accès d’administration. Pour ces chemins, les attestations de configuration ne devraient plus suffire à elles seules. Il faut exiger des résultats de tests, des propriétaires nommés et des décisions de remédiation datées.
Il ne s’agit pas d’attendre des administrateurs qu’ils maîtrisent les protocoles de fédération d’identité ou le comportement d’une libc. Il s’agit d’exiger une chaîne de responsabilité. Chaque chemin d’authentification critique a un propriétaire. Ce propriétaire peut présenter une preuve récente que le chemin refuse ce qu’il doit refuser. Lorsqu’une faille comme la CVE-2026-19868 apparaît, un délai est fixé et une décision sur le risque résiduel est consignée.
Inventorier tous les chemins d’authentification exposés sur internet. Le RSSI, avec les équipes réseau et IAM, dresse la liste des passerelles, portails et interfaces d’administration exposés. La liste recense, pour chacun, toutes les méthodes de connexion activées, y compris les méthodes de repli et les méthodes héritées.
Désigner un propriétaire par chemin. Chaque chemin a un responsable unique, nommé dans le registre des risques. Ce propriétaire répond du bon fonctionnement de l’authentification sur ce chemin, et pas seulement de sa configuration.
Fixer des délais de correction liés au statut d’exploitation. Le RSSI définit des délais de remédiation et les fait valider. Ces délais sont plus courts pour les vulnérabilités signalées comme exploitées, telles que les entrées du catalogue KEV, sur les composants d’authentification exposés. La CVE-2026-19868 relève du délai le plus court, conformément au bulletin de l’éditeur.
Tester négativement, à intervalles réguliers. Les équipes de tests de sécurité, ou des prestataires habilités, tentent régulièrement de s’authentifier avec un seul facteur et par les méthodes de connexion alternatives. Chaque résultat est consigné comme preuve à l’intention du propriétaire du chemin.
Repérer où se cachent les hypothèses de plateforme. Les équipes infrastructure et plateforme identifient les systèmes qui exécutent sshd sur musl libc avec PAM désactivé. Elles les mettent à niveau vers OpenSSH 10.6p2 ou une version corrigée par l’éditeur de la distribution, en procédant avec la prudence recommandée par le CERT-FR. Elles vérifient ensuite que la version corrigée est bien celle qui tourne.
Consigner explicitement le risque résiduel. Lorsqu’un correctif ne peut pas être appliqué immédiatement, le propriétaire du chemin documente la mesure compensatoire, le risque résiduel accepté et sa date d’échéance. La décision est signée au niveau de direction approprié.
Changer ce que reçoit le conseil. Le RSSI remplace les indicateurs « MFA activée » par des indicateurs fondés sur des preuves :
Ces deux failles seront corrigées, et l’attention se portera ailleurs. La question de fond, elle, demeurera. La plupart des organisations décrivent encore leur posture d’authentification par ce qui est activé, plutôt que par ce dont le fonctionnement a été démontré. Ce raccourci restait tolérable tant que la supervision des contrôles d’accès relevait de la technique. Il devient difficile à défendre dès lors que NIS2 confie l’approbation et la supervision aux organes de direction, et permet d’engager leur responsabilité.
L’ajustement ne demande aucune nouvelle technologie. Il demande un changement d’exigence :
Concrètement, cela signifie moins de chiffres rassurants dans les tableaux de bord et davantage de questions inconfortables, assorties de preuves. Cet arbitrage découle d’un principe simple : ne jamais faire confiance, toujours vérifier, y compris ses propres contrôles.
À retenir en pratique : Pour chaque chemin d’authentification exposé sur internet et chaque accès d’administration, exiger trois éléments :
Tant que ces éléments manquent, « MFA activée » reste une déclaration d’intention, et le conseil doit la traiter comme telle.
La mise en œuvre
Met en œuvre la sécurité conçue (migrer, déployer, intégrer) jusqu’à la mise en service, et prouve qu’elle fonctionne.
Découvrir Trusted IntegrationPreuve : Institution financière publique française
Pilotage et intégration de la migration de l’infrastructure à clés publiques d’une institution financière publique : les certificats de 140 applications migrés sans aucune interruption de service, dans les délais.
140 applications dont les certificats ont été migrés sans interruption de service
Les identifiants persistants des appareils Windows deviennent un problème crucial de cyber-gouvernance, redéfinissant la manière dont les organisations gèrent l’identité, la conformité, le suivi et les risques dans les environnements d’entreprise modernes.
FortiBleed met en évidence comment les pare-feu et les passerelles VPN sont devenus des cibles critiques de risque d’identité, exposant pourquoi les équipes de sécurité doivent repenser l’accès, la confiance et le renforcement des appareils.
Une vague de 24 milliards d’identifiants exposés oblige les dirigeants à repenser la sécurité et la gouvernance des identités, ainsi que les risques commerciaux croissants liés aux accès compromis.
Parlez-nous de votre contexte : un expert vous répond.
ou écrivez directement à trust@blooo.io
Votre e-mail part de votre propre messagerie : le site blooo.io ne stocke rien. Vos coordonnées servent uniquement à vous répondre. Politique de confidentialité.