SonicWall SonicOS: le contournement MFA du SSL-VPN exploité

Ce qui se passe

SonicWall a publié le 6 novembre un avis corrigeant sept vulnérabilités de SonicOS, dont CVE-2026-19868: lorsqu’un service SSL-VPN est configuré avec l’authentification SAML, un attaquant qui possède des identifiants valides pour une méthode d’authentification alternative peut contourner les contrôles SAML, y compris le double facteur imposé par le fournisseur d’identité. Le PSIRT de SonicWall indique avoir examiné « un signalement indiquant une exploitation potentielle » de la faille. Le 6 novembre également, la CISA l’a ajoutée à son catalogue des vulnérabilités exploitées (KEV), avec remise en conformité exigée des agences fédérales américaines avant le 20 novembre; le Centre pour la cybersécurité du Canada confirme l’exploitation signalée par l’éditeur. L’avis corrige aussi deux failles d’interface de gestion notées 8,8, des débordements de tampon pré-authentification en déni de service et un hachage de mots de passe faible sur les appliances virtuelles.

Pourquoi c’est grave pour un hôtel

Le SSL-VPN SonicWall est l’une des portes d’accès distant les plus déployées dans les hôtels: prestataire informatique qui pilote le PMS à distance, centrale de réservation, équipe comptable en télétravail, intégrateur qui touche le contrôleur d’accès. Tout ce trafic passe par un tunnel dont le double facteur est précisément la garantie qu’un vol de mot de passe ne suffit pas. Cette faille retire cette garantie: une fois un identifiant local ou LDAP volé, l’attaquant ouvre un tunnel VPN légitime aux yeux des journaux, sans jamais subir le second facteur. Un accès VPN hotel-side, c’est typiquement le réseau back-office, à quelques bonds du PMS, du serveur de clés et de la caisse.

Qui est concerné

SonicOS Gen7 jusqu’à 7.3.3-7015 et Gen8 jusqu’à 8.2.2-8015, gammes TZ, NSa, NSsp et NSv, dans le seul cas où le service SSL-VPN utilise SAML comme méthode d’authentification. Les appliances dont le SSL-VPN n’existe pas ou n’utilise pas SAML ne sont pas exposées par cette faille. Les versions corrigées sont 7.3.4-7013 (Gen7) et 8.2.3-8015 (Gen8); l’éditeur ne propose aucun contournement. Ce champ d’application étroit explique que certaines appliances soient hors de cause: vérifiez la configuration du service avant de conclure.

Comment corriger

1. Identifier toutes les appliances SonicWall du parc et leur version de SonicOS, y compris celles administrées par un prestataire.
2. Mettre à niveau vers 7.3.4-7013 (Gen7) ou 8.2.3-8015 (Gen8) au minimum, fenêtre de maintenance à la clé car la mise à jour redémarre l’appliance.
3. Auditer les journaux SSL-VPN depuis le 6 novembre: sessions SAML validées, connexions depuis des adresses inhabituelles, créations de comptes ou de règles.
4. Faire pivoter les identifiants de toutes les méthodes d’authentification alternatives encore actives sur les boîtiers non corrigés, et supprimer les comptes de prestataires dormants.
5. Si la mise à jour doit attendre: désactiver temporairement le SSL-VPN ou basculer l’accès distant indispensable sur un autre canal, le temps de patcher.
6. En profiter pour vérifier que l’interface d’administration n’est pas exposée sur l’internet, condition des autres failles du même avis.

Contexte

L’annonce s’inscrit dans une série d’attaques contre la gamme d’accès distant SonicWall: deux zero-days chaînés en septembre pour obtenir l’exécution de code sur SMA1000, puis des tentatives contre CVE-2026-102255 en octobre. SonicWall n’a pas détaillé l’exploitation liée à CVE-2026-19868; la qualification « exploitée dans la nature » repose ici sur l’ajout au catalogue KEV de la CISA et sur le signalement examiné par le PSIRT.