Si votre entreprise utilise un pare-feu SonicWall, ou si vous externalisez votre informatique auprès d'un fournisseur de services gérés (MSP) qui se connecte à distance pour maintenir vos systèmes à jour et sauvegardés, vous avez deux raisons distinctes de passer un appel cette semaine. Toutes deux concernent des vulnérabilités que des attaquants exploitent actuellement, et non des risques théoriques mentionnés dans un bulletin fournisseur que personne ne lit. Aucune ne vous oblige à devenir un expert en sécurité. Vous devez poser des questions précises et exiger des réponses précises — des dates, des numéros de version, des confirmations — et non des paroles rassurantes.

Voici ce qui se passe dans chaque cas, ainsi qu'une liste de contrôle que vous pouvez copier, coller et envoyer à la personne qui gère votre réseau.

Problème 1 : votre pare-feu SonicWall (CVE-2026-15409 et CVE-2026-15410)

SonicWall a divulgué et corrigé deux vulnérabilités le 14 juillet 2026 — mais selon la chronologie même de l'entreprise, des attaquants les exploitaient déjà depuis environ trois semaines avant leur divulgation publique. Cela signifie que « corrigé maintenant » et « sûr maintenant » ne sont pas automatiquement synonymes pour un équipement qui était exposé à Internet pendant cette période.

L'acteur malveillant le plus régulièrement cité en lien avec cette chaîne de vulnérabilités est INC, une organisation de rançongiciel en tant que service que les chercheurs de Rapid7 décrivent comme l'un des groupes de ce type les plus actifs au monde actuellement (même si toutes les attaques exploitant ces failles n'ont pas été définitivement attribuées à INC — d'autres attaquants opportunistes sont presque certainement impliqués eux aussi). Par ailleurs, la société de sécurité Huntress a signalé une vague d'attaques rapide au cours de laquelle 30 clients de SonicWall ont été compromis en moins de deux jours. Il ne s'agit pas d'un risque qui se manifeste lentement.

Il existe également un précédent pertinent ici : SonicWall a précédemment divulgué un incident au cours duquel un groupe soutenu par un État a dérobé les fichiers de configuration des pare-feu de tous les clients de SonicWall utilisant sa fonctionnalité de sauvegarde cloud. Un fichier de configuration volé peut contenir des identifiants de comptes locaux et des paramètres VPN. Si la configuration de votre pare-feu a déjà été sauvegardée sur le service cloud de SonicWall avant que cet incident ne soit maîtrisé, corriger les failles actuelles n'annule pas ce qui a déjà été exposé — les identifiants contenus dans cette configuration doivent peut-être encore être renouvelés.

Liste de contrôle à envoyer à votre fournisseur informatique ou MSP :

  • « Quel modèle de SonicWall et quelle version du micrologiciel utilisons-nous actuellement, et cette version corrige-t-elle CVE-2026-15409 et CVE-2026-15410 ? » (Demandez-leur de vérifier dans l'avis officiel de SonicWall — n'acceptez pas « nous avons la dernière version » sans numéro de version.)
  • « À quelle date avons-nous installé le correctif ? » Si cette date est postérieure au 14 juillet 2026, demandez-leur de vérifier les journaux couvrant les quelques semaines précédentes afin de rechercher des signes d'accès non autorisé — connexions d'administrateurs inattendues, nouveaux comptes locaux ou sessions SSLVPN provenant d'adresses IP inconnues.
  • « Notre portail SSLVPN ou d'accès à distance était-il exposé à Internet pendant cette période ? » Si oui, demandez une réinitialisation forcée du mot de passe pour chaque compte qui s'y authentifie, et pas seulement l'installation d'un correctif.
  • « La configuration de notre pare-feu a-t-elle déjà été sauvegardée sur le service cloud de SonicWall et, si oui, les identifiants contenus dans ce fichier de configuration ont-ils été renouvelés depuis ? »
  • « L'authentification multifacteur est-elle activée pour tous les comptes d'accès à distance via le pare-feu ? » Si ce n'est pas le cas, demandez-leur de l'activer cette semaine.

Problème 2 : l'outil de gestion à distance de votre MSP (CVE-2026-18577 dans N-able N-central)

Celui-ci est différent, car il ne s'agit pas de votre équipement — c'est un outil que votre fournisseur informatique peut utiliser pour gérer des dizaines ou des centaines d'entreprises clientes, dont la vôtre, depuis une console centrale. N-able N-central est l'une de ces plateformes, et la CISA (l'Agence américaine de cybersécurité et de sécurité des infrastructures) a ajouté une vulnérabilité qui l'affecte — CVE-2026-18577, évaluée à 8,2 sur 10 en termes de gravité — à son catalogue des vulnérabilités connues comme exploitées, après avoir confirmé une exploitation active depuis le 31 juillet 2026. Cette faille permettrait à un attaquant d'obtenir un accès administratif complet à la console N-central elle-même.

Cela compte en raison de ce qu'un attaquant peut faire depuis cette console. Huntress a signalé que les attaques réussies se sont propagées depuis la console compromise vers les terminaux gérés par son intermédiaire — ce qui signifie qu'une compromission de l'outil du MSP peut devenir une compromission de vos systèmes sans qu'un attaquant ne vous cible directement. Huntress a également constaté que des attaquants créaient des tunnels Cloudflare sur les systèmes compromis, une technique qui leur fournit un moyen persistant et chiffré de revenir, pouvant ressembler à du trafic web ordinaire pour un pare-feu.

Vous n'avez pas besoin de savoir si votre fournisseur utilise N-central. Vous devez le demander, et poser la question plus largement que sous le seul nom de ce produit.

Liste de contrôle à envoyer à votre fournisseur informatique ou MSP :

  • « Utilisez-vous N-able N-central, ou un autre produit N-able, pour gérer nos systèmes ? » Si oui : « Est-il corrigé contre CVE-2026-18577 et, à quelle date l'a-t-il été ? »
  • « Avez-vous audité l'activité des comptes administrateurs et les journaux d'accès de votre console de gestion depuis le 31 juillet 2026, afin d'y rechercher tout élément que vous ne pouvez pas expliquer ? »
  • « Avez-vous vérifié spécifiquement si nos systèmes établissent des connexions sortantes inattendues — en particulier des processus de tunnel Cloudflare (parfois affichés sous le nom “cloudflared”) ou des domaines de tunnel que vous n'avez pas configurés ? »
  • « De nouveaux comptes administrateurs locaux, tâches planifiées ou stratégies de gestion à distance ont-ils été déployés sur nos systèmes sans que vous puissiez les attribuer à votre propre équipe ? »
  • « Si vous n'utilisez pas N-central, quel outil de gestion à distance utilisez-vous à la place, et a-t-il récemment fait l'objet de l'ajout d'une vulnérabilité au catalogue des vulnérabilités connues comme exploitées de la CISA ? »

Que faire des réponses

Un bon fournisseur informatique répondra à ces questions avec des dates et des détails, souvent dans la journée, car il devrait déjà connaître ces informations ou être en mesure de les extraire rapidement des journaux. Une réponse vague — « nous maîtrisons la situation », « nos systèmes sont sécurisés », aucune date fournie — constitue en soi une information utile : elle vous indique que cette conversation doit avoir lieu à nouveau, par écrit, avec une échéance précise.

Si vous gérez vous-même votre SonicWall sans MSP, la liste de contrôle ci-dessus s'applique tout de même directement à vous — connectez-vous vous-même à la console de gestion, vérifiez la version du micrologiciel et consultez la page d'avis de SonicWall pour connaître la version qui corrige les deux CVE.

Aucun de ces défauts ne vous oblige à vous débarrasser d’un fournisseur ni à en licencier un. Ils exigent de confirmer que la faille précise a été comblée et que rien ne s’y est faufilé pendant qu’elle était ouverte. Posez les questions, obtenez les dates et mettez un rappel dans votre agenda pour les poser à nouveau la prochaine fois qu’un fournisseur révèle qu’une faille est « activement exploitée ». Cela se reproduira.