EN
en direct

Synology corrige des vulnérabilités dans DSM sans dire lesquelles, et c’est un problème pour vos NAS

Le 12 octobre 2026, Synology publie DSM 7.4.1-90080 Update 1, marquée « Important », sans lister aucune CVE ni détail sur les failles corrigées. Installez quand même la mise à jour, mais exigez de la transparence et durcissez votre NAS comme la cible qu’il est.

Un petit boîtier NAS sombre posé sur une étagère métallique, une seule LED d’état ambre allumée sur sa façade, le reste du panneau avant plongé dans l’obscurité.

12 octobre 2026. Synology publie DSM 7.4.1-90080 Update 1, marquée « Important ». Le même jour. La note de version officielle tient en une ligne : « Correction de plusieurs vulnérabilités de sécurité (détails non divulgués) ». Octobre 2026. La presse spécialisée relève qu’aucune CVE n’est listée. Pourquoi c’est important : un constructeur de NAS — la classe d’appareils que les rançongiciels et le proxyjacking ciblent en priorité — vous demande de patcher sans vous dire ce qu’il a corrigé.

Une mise à jour de sécurité sans contenu

Le constat est factuel. La version DSM 7.4.1-90080 Update 1 corrige, selon l’éditeur, « plusieurs vulnérabilités de sécurité », mais la liste des changements ne fournit aucun identifiant CVE, aucun numéro d’avis Synology-SA, aucune sévérité, aucun vecteur. Marius Hosting, qui documente chaque mise à jour du système, écrit noir sur blanc : « cette mise à jour inclut des améliorations de sécurité, bien que Synology n’ait pas divulgué de CVE spécifiques ni d’entrées détaillées dans le changelog ».

Ce silence n’est pas anodin, parce qu’il rompt avec la pratique habituelle de l’éditeur. Synology publie régulièrement des avis Synology-SA qui détaillent les failles, leur sévérité CVSS et les modèles affectés — c’est par ce canal qu’un administrateur sait si sa baie est exposée et s’il doit patcher en urgence ou planifier une fenêtre de maintenance. Une mise à jour « Important » qui n’est rattachée à aucun avis prive l’administrateur de l’information qui lui permet de prioriser. On lui demande de faire confiance, pas de décider.

Pourquoi le NAS est la cible qu’on ne peut plus traiter à la légère

Le contexte donne au problème son poids réel. Le NAS est devenu la cible de choix de deux économies criminelles distinctes. La première est le rançongiciel : un appareil de stockage contient par définition les données qu’une victime paiera pour récupérer, et les campagnes qui ciblent les baies Synology et QNAP se comptent par dizaines depuis 2021. La seconde est le proxyjacking : détourner la bande passante et la puissance d’un appareil résidentiel pour revendre du trafic, comme la campagne qui a monétisé 143 NAS D-Link et NVR Ubiquiti en octobre — un épisode que nous avons détaillé.

Un appareil qui stocke tout et qui, trop souvent, écoute sur Internet via QuickConnect, un port UPnP ouvert ou une redirection mal maîtrisée, est un actif à haut risque. C’est précisément ce qui rend le silence de Synology coûteux : l’administrateur d’un NAS exposé a besoin de savoir si la faille corrigée est exploitable à distance sans authentification, pour mesurer son exposition entre le jour de la publication et le redémarrage de sa baie.

Ce qu’il faut faire — et ce qu’il faut exiger

La première réaction est contre-intuitive, mais elle est juste : installez la mise à jour quand même. Une correction de sécurité silencieuse reste une correction de sécurité, et un NAS non patché est un risque certain, là où l’opacité du changelog n’est qu’un risque d’information. Le bon réflexe se décompose ainsi :

  • Installer la mise à jour sur tous les modèles, en commençant par ceux qui sont accessibles depuis l’extérieur.
  • Durcir dans la foulée : couper QuickConnect et l’exposition directe, désactiver UPnP, placer la baie dans un VLAN dédié, et activer l’authentification à deux facteurs ainsi que le blocage automatique des tentatives de connexion.
  • Sauvegarder selon la règle 3-2-1, avec une copie hors site qui n’est pas montée en permanence sur le NAS — un rançongiciel chiffre aussi les disques de sauvegarde locaux.
  • Surveiller les journaux de connexion et les alertes de l’appareil, et s’abonner à la page Synology-SA pour recevoir les avis quand ils finissent par sortir.

La seconde exigence est éditoriale autant que technique. Demandez des comptes au constructeur. Une note « détails non divulgués » sur un appareil de stockage exposé n’est pas une communication de sécurité : c’est l’absence de communication. La pression des clients — particuliers comme entreprises — est le seul levier qui pousse un éditeur à publier, même tardivement, le détail d’une faille qu’il préférerait taire.

Ce qu’une transparence normale ressemble

La comparaison avec le voisin est instructive. QNAP, l’autre grand constructeur de NAS, publie pour chaque correctif des avis QSA (QNAP Security Advisory) qui listent les CVE, les scores CVSS et les modèles concernés — le même standard que Synology-SA. C’est ce standard qui permet à un administrateur de répondre à la seule question qui compte : ma baie est-elle concernée, et à quelle vitesse dois-je patcher ?

L’histoire récente du secteur explique pourquoi cette question n’est pas théorique. Les rançongiciels Deadbolt et Qlocker ont massivement chiffré des NAS exposés via QuickConnect et myQNAPcloud entre 2021 et 2022, et les campagnes n’ont jamais cessé. Un NAS dont le mot de passe est faible ou dont le micrologiciel traîne de quelques semaines est statistiquement une victime en attente. Quand le correctif arrive sans explication, l’administrateur consciencieux n’a d’autre choix que de patcher — ou de couper l’accès externe en attendant.

Un durcissement minimal ne demande aucune expertise particulière. Désactiver le compte admin par défaut, forcer une authentification forte, restreindre les connexions SSH à un sous-réseau d’administration et vérifier que la baie n’est pas joignable depuis Internet sont des gestes qui se font en une heure :

bash
# Vérifier que la baie ne répond pas depuis l’extérieur (à exécuter hors du réseau local)
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://<ip-publique>:5001 || echo "injoignable — c’est le but"

La mise à jour silencieuse n’est pas une raison de ne pas patcher. C’est une raison de patcher et de réduire la surface d’exposition dans la foulée — les deux gestes se renforcent, et aucun ne remplace l’autre.

Les trois questions que Synology laisse sans réponse

Une note « détails non divulgués » n’est pas neutre : elle retire à l’administrateur trois informations qui déterminent sa réaction. La première est le périmètre : quels modèles et quels composants sont concernés — DSM lui-même, Surveillance Station, Drive, ou un service annexe. La deuxième est la sévérité : une faille CVSS 9,8 exploitable à distance sans authentification ne se traite pas comme une faille locale à CVSS 5. La troisième est l’exploitabilité : si une preuve de concept circule déjà, la fenêtre de correction se compte en heures, pas en semaines.

Sans ces trois réponses, l’administrateur est contraint au scénario du pire — traiter chaque mise à jour comme si elle colmatait une brèche critique. Paradoxalement, c’est la bonne décision opérationnelle : sur un appareil exposé, le coût d’un redémarrage non planifié est inférieur au coût d’une compromission. Mais cette prudence forcée a un prix : des fenêtres de maintenance improvisées, des services interrompus, et une confiance entamée envers un constructeur qui transforme une information de sécurité en boîte noire.

Le silence a aussi une conséquence invisible. Quand un éditeur ne publie pas les détails, il ne peut pas non plus corriger sa propre communication plus tard sans reconnaître l’omission. Chaque mise à jour opaque ajoute une couche de dette de confiance qui finira par se payer au moment où un incident réel surviendra — et où les clients exigeront de savoir, précisément, ce qui avait été corrigé en silence.

Verdict

Si votre NAS est exposé sur Internet, patchez aujourd’hui, sans attendre de savoir ce que la mise à jour corrige : le coût d’un jour de plus sans correctif dépasse le coût d’une information manquante. Si votre NAS est correctement segmenté et sauvegardé, prenez ce silence comme un signal de gouvernance — un fournisseur de stockage qui ne documente pas ses correctifs de sécurité mérite d’être challengé à chaque cycle, et remplacé s’il persiste à vous traiter comme un simple exécutant.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

FileBrowser Quantum 2.0 ajoute les journaux d’activité et les permissions par source

Le fork FileBrowser Quantum passe en 2.0 stable le 9 octobre 2026 avec un journal d’activité, des permissions par source de stockage et une migration de BoltDB vers SQLite, suivie le 13 octobre d’un correctif pour deux failles de sécurité. Préparez une vraie procédure de migration avant de mettre à jour vos instances 1.x.

Plex2Shell : la chaîne d’exploitation de Plex Media Server passe du PoC au minage en 24 heures

Le 16 octobre 2026, le chercheur Zach Main publie Plex2Shell, une chaîne de quatre failles — CVE-2026-96652, 96654, 96655 et 96656 — permettant une exécution de code non authentifiée sur Plex Media Server. Dès le 17 octobre, des attaquants déploient un mineur XMRig et un proxy résidentiel sur les serveurs exposés : passez à la version 1.43.3.10861 et sortez Plex d’Internet.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer