Des NAS Synology non corrigés sont ciblés depuis la fin octobre 2026 par un ransomware baptisé C3RB3R, variante de la famille Cerber, qui chiffre les fichiers et ajoute l’extension .L0CK3D. Synology confirme l’attaque et l’attribue à une faille critique corrigée depuis 2024, tandis que d’autres chercheurs pointent des vulnérabilités plus récentes : les sources ne s’accordent pas encore sur la vulnérabilité réellement exploitée, mais toutes recommandent la même réponse, mettre à jour sans attendre.
Qu’est-ce que le ransomware C3RB3R ? #
C3RB3R est un ransomware de la famille Cerber qui chiffre les fichiers d’un NAS Synology et dépose un fichier read-me3.txt dans chaque dossier concerné, avec une demande de rançon initiale d’environ 0,037 bitcoin (environ 2 950 dollars au moment des faits), qui double si elle n’est pas payée dans les cinq jours. Aucun déchiffreur gratuit n’est disponible à ce jour. L’éditeur a confirmé l’attaque dans une déclaration du 29 octobre 2026, rapportée notamment par Techaeris.
Le point de divergence porte sur la vulnérabilité réellement exploitée :
- Synology attribue l’attaque à CVE-2024-10441 (CVSS 9,8), une exécution de code à distance non authentifiée découverte lors du concours Pwn2Own 2024 par les chercheurs de DEVCORE, corrigée en novembre 2024 par le bulletin officiel Synology-SA-24:20. Un exploit public pour cette faille serait apparu sur GitHub le 25 octobre 2026, ce qui expliquerait le regain d’attaques.
- Le chercheur chinois 360 attribue plutôt l’attaque à CVE-2026-13639 et CVE-2026-13684 (CVSS 9,8 également), corrigées le 18 septembre 2026, et parle d’une exploitation de type « 1-day ».
- L’équipe de réponse à incident Solar rapporte avoir observé le ransomware sur un NAS déjà sous une version récente de DSM (7.4.1), ce qui ne correspond à aucune des deux hypothèses précédentes sans écarter des identifiants volés, des paquets tiers ou des conteneurs compromis.
À retenir : aucune source ne publie de preuve technique tranchant entre ces hypothèses. Dans le doute, la seule mesure sûre est de corriger toutes les failles connues du DSM installé, pas uniquement celle citée par un communiqué.
Synology écarte explicitement un lien avec les failles PHP2Shell (CVE-2026-109618 et CVE-2026-109619), déjà traitées sur ce blog pour d’autres contextes d’exploitation, tout en rappelant qu’elles doivent elles aussi être corrigées.
Versions concernées et correctifs #
| DSM | Statut | Version minimale recommandée |
|---|---|---|
| DSM 7.4 | Vulnérable si antérieure | 7.4-90075 |
| DSM 7.3.2 | Vulnérable si antérieure | 7.3.2-86009-4 |
| DSM 7.2.2 | Vulnérable si antérieure | 7.2.2-72806-9 |
| DSM 7.2.1 | Vulnérable si antérieure | 7.2.1-69057-12 |
Ces versions corrigent à la fois la faille de 2024 et les CVE plus récentes évoquées par 360. Un NAS dont le DSM est en fin de vie (non mis à jour depuis plusieurs versions majeures) est le profil le plus exposé : c’est justement ce que visent la majorité des signalements actuels.
Comment se protéger ? #
- Mettre à jour DSM immédiatement, via Panneau de configuration > Mise à jour et restauration, en vérifiant le numéro de build complet (pas seulement le numéro de version affiché).
- Mettre à jour tous les paquets installés depuis le Centre de paquets : un paquet tiers obsolète peut rester un point d’entrée même après la mise à jour du système.
- Lancer une analyse avec Security Advisor, l’outil de diagnostic intégré de Synology, pour repérer une configuration à risque.
- Vérifier le planificateur de tâches à la recherche de scripts inconnus, et la liste des comptes administrateurs dans Utilisateur et groupe.
- Ne jamais exposer directement la page de connexion du NAS sur Internet : privilégier un VPN ou le reverse proxy fourni par Synology plutôt qu’une redirection de port directe.
- Vérifier que les sauvegardes fonctionnent réellement (Hyper Backup, Snapshot Replication) et qu’au moins une copie est hors ligne ou hors site, hors de portée d’un chiffrement du NAS lui-même.
- En cas de doute sur une compromission déjà en cours, contacter le support Synology plutôt que de tenter un nettoyage manuel, qui peut détruire des preuves utiles à l’investigation.
L’avis du CSIRT #
Ce type d’incident rappelle une règle simple : un NAS en fin de vie, jamais mis à jour parce qu'« il fonctionne », est une cible de choix précisément parce que les correctifs existent depuis longtemps et que les attaquants savent qu’une partie du parc ne les a jamais appliqués. La priorité absolue va aux NAS exposés directement sur Internet, avec un service de connexion distante activé sans VPN : ce sont eux qui doivent être traités dans la journée. Un NAS strictement interne, isolé derrière un pare-feu correctement configuré, peut suivre un calendrier de mise à jour plus classique, sans pour autant être négligé.
Côté détection, la vigilance porte sur des signaux génériques plutôt que sur un indicateur unique : apparition de fichiers avec une extension inhabituelle, dépôt d’un fichier texte identique dans plusieurs dossiers, tâches planifiées créées sans action d’un administrateur connu, et pics d’activité disque ou réseau en dehors des horaires de sauvegarde habituels. Les journaux du planificateur de tâches et de connexion DSM sont les premiers à consulter.
Le piège le plus fréquent, sur ce genre d’affaire, consiste à corriger la seule faille citée par le communiqué le plus visible et à considérer l’incident clos. Ici, deux attributions différentes circulent pour le même ransomware : s’arrêter à l’une d’elles laisse ouvertes les failles évoquées par l’autre source. Après toute mise à jour, il convient de vérifier qu’aucune sauvegarde n’a elle-même été altérée avant d’être restaurée, et de conserver une copie de l’état du NAS compromis avant tout nettoyage, au cas où une analyse plus poussée serait nécessaire.
Points clés #
- Le ransomware C3RB3R chiffre les NAS Synology non corrigés et ajoute l’extension .L0CK3D, sans déchiffreur gratuit disponible.
- Synology attribue l’attaque à une faille de 2024 (CVE-2024-10441) ; d’autres chercheurs évoquent des CVE plus récentes de septembre 2026 : l’attribution exacte reste disputée.
- La version DSM minimale recommandée dépend de la branche installée ; un NAS en fin de vie, jamais mis à jour, est le profil le plus exposé.
- La protection repose sur la mise à jour complète de DSM et des paquets, l’absence d’exposition directe à Internet, et des sauvegardes hors ligne vérifiées.
- Aucune ampleur chiffrée de la campagne n’est publiée : seule la Corée du Sud (KISA) confirme avoir reçu des signalements, sans préciser leur nombre.
La base CVE de ForenShield permet de retrouver le détail de chaque identifiant cité ici. Un autre exemple récent de serveurs de sauvegarde ciblés après la publication d’un correctif se trouve dans notre article sur la faille AhsayCBS.