Une campagne de rançongiciel vise les serveurs de stockage Synology dont le système n’a pas été mis à jour. Les attaquants exploitent des failles déjà corrigées, chiffrent les fichiers et réclament une rançon. Pour une entreprise ou une collectivité, l’épisode oblige à vérifier si les sauvegardes conservées sur ces équipements protègent encore quoi que ce soit.
Depuis début octobre 2026, des propriétaires de NAS Synology découvrent que leurs fichiers sont devenus illisibles : documents de travail, dossiers administratifs, photos, et parfois les sauvegardes elles-mêmes. Le 29 octobre, Synology a confirmé des attaques contre des appareils fonctionnant sous d’anciennes versions de DiskStation Manager (DSM), parfois en fin de vie. Le fabricant pointe une faille corrigée fin 2024. L’éditeur de sécurité 360, qui a analysé des appareils touchés, met en cause deux failles corrigées en septembre 2026. Dans les deux cas, les NAS chiffrés n’avaient pas reçu les correctifs.
Pourquoi les NAS intéressent les attaquants
Un NAS (Network Attached Storage) sert à centraliser les documents, à les partager entre collègues et, très souvent, à stocker les sauvegardes. On en trouve dans beaucoup de PME, d’associations et de collectivités. Il s’installe facilement, tourne dans un placard, et on finit par l’oublier. En le chiffrant, un attaquant atteint d’un coup les fichiers de travail et leurs copies.
C3RB3R, .L0CK3D et read-me3.txt
Le rançongiciel identifié s’appelle C3RB3R. Il s’agit d’une variante de Cerber, une famille active depuis 2016 qui avait déjà visé des serveurs Confluence non corrigés début 2024. Les fichiers chiffrés prennent l’extension .L0CK3D, et une note intitulée read-me3.txt, déposée dans chaque dossier touché, renvoie vers une page Tor pour négocier l’outil de déchiffrement.
Payer ne garantit pas de récupérer les fichiers, ni de les récupérer intacts.
Rançongiciel Synology : quelles failles sont en cause ?
Synology renvoie à son bulletin Synology-SA-24:20. Publié le 5 novembre 2024 et complété jusqu’au 5 décembre 2024 pour DSM 6.2, il corrige notamment trois failles. CVE-2024-10441, notée 9,8 sur 10, permet à un attaquant distant d’exécuter du code. CVE-2024-50629 donne accès en lecture à certains fichiers. CVE-2024-10445 est un défaut de validation des certificats dans la fonction de mise à jour, exploitable depuis le réseau local pour écrire certains fichiers. Le communiqué du 29 octobre ne dit pas laquelle est exploitée.
360 attribue de son côté les intrusions qu’il a examinées à CVE-2026-13639 et CVE-2026-13684. Ces deux failles critiques, notées elles aussi 9,8, permettent de lire ou d’écrire des fichiers à distance sans authentification. Synology les a corrigées le 18 septembre 2026 dans le bulletin Synology-SA-26:13. Le CERT belge a mis à jour son alerte fin octobre pour signaler leur exploitation active. Les deux pistes ne s’excluent pas, puisque rien ne prouve que tous les appareils ont été compromis par la même porte d’entrée. Les vulnérabilités PHP2Shell, que Synology examinait au moment de sa découverte, concernent certains paquets qui dépendent de PHP (Web Station, WordPress, phpMyAdmin notamment). Le fabricant ne les présente pas comme la cause des infections.
Quelle que soit la faille utilisée, la consigne reste d’appliquer toutes les mises à jour de sécurité disponibles pour le modèle concerné.
Rançongiciel sur des données personnelles : une violation au sens du RGPD – Si vous utilisez ce système pour stocker les données des personnes concernées.
Dès qu’il touche des données à caractère personnel, un chiffrement malveillant peut constituer une violation de données au sens de l’article 4, paragraphe 12, du RGPD. Le règlement protège la confidentialité des données, leur intégrité et leur disponibilité. Un organisme privé de ses dossiers clients, de ses fichiers du personnel ou de données de santé peut donc faire face à une violation, même si aucune extraction de données vers l’extérieur n’est démontrée.
La perte de disponibilité se mesure à ce que l’organisme ne peut plus faire : suivre des personnes, verser les salaires, assurer la continuité d’un service. L’intégrité pose une autre question, car des fichiers ont pu être modifiés, corrompus ou détruits, et une restauration ne rend pas toujours un ensemble cohérent. Reste la confidentialité. Les attaquants ont pu accéder aux données, mais le chiffrement ne prouve pas à lui seul une exfiltration, et seules des investigations techniques permettent de trancher.
L’analyse doit donc séparer ce qui est établi, ce qui est supposé et ce qui reste à vérifier.
Article 32 : une sécurité adaptée au risque, et contrôlée
L’article 32 du RGPD demande au responsable de traitement et au sous-traitant de mettre en œuvre des mesures techniques et organisationnelles appropriées au risque. Le texte vise la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes, la capacité à rétablir l’accès aux données dans des délais appropriés après un incident, et une procédure pour tester et évaluer régulièrement l’efficacité de ces mesures.
Une sauvegarde qui n’a jamais été restaurée ne démontre rien sur la capacité réelle de reprise.
Qui installe et contrôle les correctifs de sécurité ? L’appareil est-il encore couvert par le support du fabricant ? Son interface d’administration est-elle joignable depuis Internet ? Les sauvegardes sont-elles isolées des systèmes de production ? La restauration a-t-elle été testée, et quand ? Les preuves de maintenance et de contrôle sont-elles conservées ? En cas de contrôle de la CNIL, l’organisme devra produire ces réponses, documentées.
Un NAS de sauvegarde n’est pas une sauvegarde sécurisée
Beaucoup d’organisations considèrent qu’un NAS qui reçoit des copies de fichiers suffit à les protéger contre la perte de données. Le jour où ce NAS est lui-même chiffré, la protection disparaît avec lui.
Le RAID permet de continuer à fonctionner après la panne d’un disque, il ne protège en rien contre un rançongiciel. Une synchronisation automatique, de son côté, propage les suppressions et les modifications malveillantes vers les copies. L’ANSSI, dans ses recommandations sur la sauvegarde des systèmes d’information, et la CNIL préconisent la règle 3-2-1 : trois copies distinctes des données (la production et deux sauvegardes), sur des supports différents, dont une hors ligne. Des sauvegardes immuables, impossibles à modifier ou à supprimer pendant une durée fixée, ajoutent une protection utile.
Il faut aussi tester les restaurations, séparer les comptes d’administration et fixer des objectifs de reprise. La fréquence des sauvegardes dépend de la quantité de données que l’organisme accepte de perdre et de la durée d’interruption qu’il peut supporter. Une sauvegarde quotidienne peut se révéler insuffisante, et aucun texte ne l’impose de manière générale.
Votre organisme possède un NAS Synology : les vérifications immédiates
Commencez par recenser les NAS de l’organisme et relevez la version de DSM de chacun. Installez ensuite les derniers correctifs, y compris ceux de septembre 2026, en suivant les recommandations de Synology et en vérifiant leur compatibilité avec chaque modèle. Synology conseille aussi d’activer les mises à jour automatiques.
Un appareil sous une version de DSM qui n’est plus maintenue mérite un examen à part. Un correctif publié ponctuellement pour un produit en fin de vie ne lui rend pas un support de sécurité complet. L’interface d’administration d’un NAS n’a rien à faire sur Internet. Pour les accès distants, passez par un VPN correctement configuré. Activez une authentification renforcée sur les comptes administrateurs et désactivez les services inutilisés. Si vous utilisez des paquets dépendant de PHP, mettez PHP à jour depuis le Centre de paquets.
Vérifiez enfin que les sauvegardes ne dépendent pas du NAS principal et qu’elles se restaurent réellement.
Le NAS est déjà compromis : contenir sans effacer les traces
Isolez l’équipement du réseau et suspendez les synchronisations et sauvegardes qui pourraient propager les dégâts. Conservez les journaux techniques, la note de rançon et tout ce qui aidera à reconstituer la chronologie. Une réinitialisation précipitée détruirait des éléments utiles à l’enquête. Identifiez ensuite les données touchées, mesurez ce que leur indisponibilité empêche de faire et cherchez à établir s’il y a eu accès non autorisé ou transfert de données. Restaurez à partir de sauvegardes vérifiées, une fois l’environnement sécurisé.
Mettre DSM à jour ne déchiffrera pas les fichiers déjà chiffrés.
Notification à la CNIL : 72 heures pour décider
Si le NAS compromis contient des données personnelles, l’organisme doit déterminer s’il s’agit d’une violation de données. L’article 33 du RGPD impose de la notifier à la CNIL lorsqu’elle est susceptible d’engendrer un risque pour les droits et libertés des personnes, dans les meilleurs délais et si possible dans les 72 heures après en avoir pris connaissance.
Une perte de disponibilité peut à elle seule exposer les personnes à un risque, même sans fuite démontrée. Si le risque est élevé, l’article 34 impose en plus d’informer les personnes concernées, sauf exceptions prévues par le texte.
Toute attaque n’appelle pas une notification. L’organisme évalue le risque et garde une trace écrite de cette évaluation. Même sans notification, la violation est inscrite dans la documentation interne prévue par l’article 33, paragraphe 5.
Le délégué à la protection des données doit être associé à l’évaluation des conséquences, à la documentation de l’incident et à la décision de notifier ou non.
Une conformité qu’il faut pouvoir prouver
Un pare-feu, un antivirus, une sauvegarde ou une procédure écrite ne prouvent pas que les risques sont maîtrisés. L’organisme doit pouvoir montrer, pièces à l’appui, que ses équipements sont recensés, que les mises à jour sont appliquées, que les vulnérabilités sont suivies et que les restaurations sont testées. DPO SUITE répond à ce besoin de preuve. L’outil centralise les analyses, les incidents et violations de données, les plans d’action, les audits et les pièces nécessaires au suivi de la conformité. Il s’ajoute aux outils de cybersécurité et de sauvegarde : il structure la documentation, suit les actions correctives et permet de démontrer les diligences accomplies.
Le RGPD demande un niveau de protection proportionné au risque, et la preuve que les mesures prévues sont réellement appliquées.
Conclusion : des correctifs disponibles, des NAS restés vulnérables
Le correctif cité par Synology date de fin 2024. Ceux que met en cause 360 datent du 18 septembre 2026, et les premières attaques ont été observées début octobre, soit moins de trois semaines plus tard. Un parc de NAS qui n’est mis à jour qu’au fil des alertes reste exposé pendant tout ce délai.
Appliquer le correctif après l’alerte est un minimum. Une protection durable suppose de suivre les vulnérabilités en continu, d’attribuer clairement les responsabilités, de garder des sauvegardes réellement indépendantes et de documenter chaque contrôle. La protection des données personnelles tient autant à l’entretien des équipements qu’aux équipements eux-mêmes.
Sources