SURIQ
The Synology boxes now being encrypted by C3RB3R ransomware were not hit by anything new. Synology says the attackers are using a DSM flaw it fixed in late 2024, which, if that holds, means infected units sat on a known, patchable hole for close to two years. On a device that often holds the backups for everything else, that gap is the whole story: when the NAS goes, the recovery copy goes with it.
Synology published its warning on October 29, 2026, urging owners of outdated DiskStation Manager (DSM) installs to update immediately and turn on automatic updates. BleepingComputer reported that the first victim reports surfaced over two weeks ahead of the advisory, and owners have posted infection reports on Reddit's r/synology forum.
Which DSM flaw is C3RB3R exploiting?
Synology has not named the CVE. Its statement points to advisory Synology-SA-24:20, which bundles three bugs from the Pwn2Own 2024 contest. The serious one is CVE-2024-10441, a critical (CVSS 9.8) remote code execution flaw in the DSM system plugin daemon.
The other two are moderate: CVE-2024-50629 lets a remote attacker read limited files through the webapi component, and CVE-2024-10445 lets an attacker on an adjacent network write limited files by abusing weak certificate checks in the update function. Researchers from DEVCORE, Ryan Emmons, and Team Smoking Barrels are credited.
Both news reports flagged a date mismatch: Synology says the flaw was "patched in December 2024," yet the advisory went out on November 5, 2024. The advisory's own revision log explains it. Fixes rolled out branch by branch, and the last one, for DSM 6.2, landed on December 5, 2024. So "December" is when the final branch was covered, not a sign of a different bug. That still leaves the exact CVE unconfirmed, which is why the safe move is to patch every branch past all three, not to guess which one is in play.
| DSM branch | Advisory severity | Minimum fixed build |
|---|---|---|
| DSM 7.2.2 | Critical | 7.2.2-72806-1 |
| DSM 7.2.1 | Critical | 7.2.1-69057-6 |
| DSM 7.2 | Critical | 7.2-64570-4 |
| DSM 7.1 | Critical | 7.1.1-42962-7 |
| DSM 6.2 | Moderate | 6.2.4-25556-8 |
The fixed builds are 7.2.2-72806-1 for DSM 7.2.2, 7.2.1-69057-6 for 7.2.1, 7.2-64570-4 for 7.2, 7.1.1-42962-7 for 7.1, and 6.2.4-25556-8 for 6.2. Synology rates DSM 6.2 moderate because only the lower-severity bug reaches that branch.
That is roughly 23 months from the first fix to the ransomware warning, and about 19 months after Synology published the technical details in March 2025. A patch that old with public details is exactly what an opportunistic crew scans for.
Why an old patch still lands ransomware
C3RB3R fits that pattern. Since late 2021 it has been dropped on Atlassian Confluence and GitLab servers through long-patched bugs such as CVE-2021-26084, CVE-2021-22205, and CVE-2023-22518, according to BleepingComputer. The operators do not need fresh exploits. They need devices nobody updates, and consumer and small-business NAS units are full of them.
The Shadowserver Foundation counts upward of 380,000 Synology NAS units reachable from the internet, per BleepingComputer, though it cannot say how many are patched or how many are honeypots. Even a small unpatched share is a large target pool.
Three things make a NAS a worse victim than a typical server, and none of them is in the vendor statement:
-
It is usually the backup. Hosting shops and small teams point Hyper Backup jobs, rsync targets, and VM exports at the NAS. Ransomware there removes the copy you planned to restore from. If your only backup lives on the box being encrypted, you do not have a backup.
-
It is rarely monitored. Servers send logs somewhere. A NAS in a closet often sends nothing, so the first alert is a user who cannot open a file.
-
It drifts off the update track. Owners disable auto-update to avoid surprise reboots, or keep an older model on DSM 6.2 or 7.1 because it works. Those are the installs this campaign is finding.
We have seen the same shape elsewhere this year: INC ransomware ran on patch backlogs, not zero-days, and the Flax Typhoon scanning wave went after server bugs dating back as far as 2015. Old bugs on unwatched devices keep paying.
How to tell if a Synology NAS is already hit
Look for the file extension and ransom note BleepingComputer documented: encrypted files end in .L0CK3D, and the attackers leave a ransom note called read-me3.txt. The note points to a payment site on the dark web that sells a decryption tool, and offers to decrypt a single file at no cost to prove it works. Synology has not published hashes, IP addresses, or the exploitation log trail, so file artifacts are the reliable signal for now.
From an SSH session on the NAS (enable SSH only for the check if you normally keep it off), confirm the build and sweep the volumes:
grep -E '^(productversion|buildnumber|smallfixnumber)' /etc.defaults/VERSION find /volume* -xdev \( -name '*.L0CK3D' -o -name 'read-me3.txt' \) 2>/dev/null | head -50
Compare the build number and update level against the fixed builds above. Any hit from the find means the box is compromised: take it off the network before it reaches mapped shares on other machines, and treat every credential stored on it as exposed.
If your servers ship logs to central monitoring, add the NAS as a source too. A burst of file renames to one new extension, or a note file appearing in many folders at once, is a cheap detection to write and a far earlier signal than a support ticket. For background on watching file changes at scale, see our file integrity monitoring overview.
Get the DSM admin panel off the open internet
Updating DSM to the fixed build for your branch is the fix. Do it today, then turn on automatic updates as Synology advises, and schedule reboots so nobody turns them off again.
BleepingComputer also reports Synology's advice to block internet access to the management web interface. That deserves more weight than it gets. DSM's admin panel has no business being reachable from the open internet; put it behind a VPN or an allowlist so the next DSM bug is not one scan away.
Then fix the backup problem. Keep at least one copy of anything that matters off the NAS, on storage the NAS cannot write to or delete. A compromised backup system gives an attacker the strongest hand, because it takes away the option to restore. Patch the box, hide the panel, and make sure the backup of last resort is not the device being attacked.