Yaamlabs
Ransomware

C3RB3R ransomware is encrypting outdated Synology NAS

C3RB3R, a Cerber variant, is locking Synology NAS files as .L0CK3D. Which DSM builds to install, how to cut exposure, and how to check backups.

By Yaali. November 3, 2026, 6 min read, Ransomware, Patching, Resilience.

Cover illustration of a network storage server with drive bays sealed by glowing bands, with the Yaamlabs logo and the text: C3RB3R ransomware is locking Synology NAS files, 9.8 CVSS on the flaws named so far

Since early October 2026, Synology NAS owners have been finding their files renamed with a .L0CK3D extension (a zero, not the letter O) and a ransom note called read-me3.txt in every folder. The Chinese security firm 360 says the malware is C3RB3R, a variant of the Cerber ransomware family that has targeted NAS devices for years. On October 29, 360 published its findings and Synology published a notice telling owners to update DSM (DiskStation Manager, the NAS operating system).

If you run a Synology NAS on an older DSM build, and especially if its login page can be reached from the internet, treat this as urgent. Synology and 360 do not agree on which flaw the attackers use, and the two advisories they point to have different fixed builds. The safe course is to install builds that close both.

What Synology and 360 each say about the C3RB3R entry point, with the advisory, CVEs and CVSS scores each one names

Two different explanations of the entry point

Synology's October 29 notice says threat actors are "exploiting a vulnerability patched in December 2024" on devices running outdated DSM, and it links to advisory Synology-SA-24:20. That advisory came out of Pwn2Own 2024. Its critical item is CVE-2024-10441, CVSS 3.1 score 9.8: an output encoding flaw in DSM's system plugin daemon that lets an unauthenticated remote attacker run code. IT-Connect reports that a public proof of concept on GitHub abuses the "username" field on the DSM login page to inject environment variables into a daemon that runs as root. The notice itself does not name a CVE, list versions or publish indicators of compromise.

360 says the incidents it investigated came in through two newer flaws, CVE-2026-13639 and CVE-2026-13684, which Synology fixed on September 18, 2026 in advisory Synology-SA-26:13. Both are rated critical with CVSS 9.8 and need no login. CVE-2026-13639 is in DSM's login logic and CVE-2026-13684 is in its SCGI component (the interface between the web server and DSM's back-end programs). Either one lets a remote attacker read or write arbitrary files on the NAS.

Neither claim has been independently confirmed, and both may be true for different victims. What matters for defenders is that a box patched only against SA-24:20 is still open to the September flaws, and SA-26:13 lists no mitigation other than updating.

What the malware does once it is in

360's analysis describes a fairly conventional file locker. C3RB3R walks the directory tree recursively and skips 27 system directories, plus certain executables and scripts. For each file it generates its own key and nonce and encrypts the contents with ChaCha8, a fast stream cipher. The per-file key is then encrypted with an RSA-2048 public key embedded in the sample, and that wrapped key is appended to the end of the file. Some file types are encrypted in full; for others, how much is encrypted depends on file size.

The design means only the holder of the matching RSA private key can recover the per-file keys. Renaming files back does nothing, and none of the reports mentions a free decryptor. Synology does not offer one. The note offers a test decryption and points to a Tor payment page. 360 advises against paying.

What to do

1. Update DSM to builds that close both advisories

SA-26:13 is the newer and stricter of the two, so its builds are the floor for supported branches:

  • DSM 7.4: 7.4-90075 or later
  • DSM 7.3: 7.3.2-86009-4 or later
  • DSM 7.2.2: 7.2.2-72806-9 or later
  • DSM 7.2.1: 7.2.1-69057-12 or later

These are minimums, so take the newest build offered for your model. Devices on DSM 7.2, 7.1 or 6.2 are covered only by SA-24:20 (7.2-64570-4, 7.1.1-42962-7 and 6.2.4-25556-8 or later). SA-26:13 lists no fix for those branches, so move them to 7.2.1 or newer if the hardware allows it. Then turn on automatic updates, as Synology's notice asks, and update installed packages too.

2. If you cannot patch today, take DSM off the internet

Remove router port forwards to the DSM web interface (TCP 5000 and 5001 by default) and reach the NAS over a VPN instead. QuickConnect, Synology's relay service, also exposes the DSM sign-in page to the internet without any port forward. Neither vendor names it in this campaign, but if you do not need it, turn it off under Control Panel, External Access, QuickConnect by clearing "Enable QuickConnect". If you do need it, use its advanced settings to limit which services it relays. Also disable the default admin account, require two-factor sign-in and turn on auto block for repeated failed logins.

3. Check that your backups would survive

Snapshots on the same NAS are not a backup if an attacker can delete them. In Snapshot Replication, enable immutable snapshots, which use WORM (write once, read many) locking so nobody, including an admin, can change or delete a snapshot until its protection period ends. Synology's knowledge base suggests a protection period of 7 to 14 days. Set it under Snapshot Replication, Snapshots for local copies, or in the replication task schedule for remote ones. Keep at least one more copy offline or on a system that the NAS admin account cannot reach, and confirm you have restored from it recently.

4. Check whether you were already hit

Search shares for files ending in .L0CK3D and for read-me3.txt. Look for sudden mass file changes in the logs, unexpected packages under Package Center and new or changed accounts under Control Panel, User and Group. Note your DSM build: if it is older than the SA-26:13 builds above and DSM was reachable from the internet, assume the device may have been entered even if nothing is encrypted yet.

Response steps for a Synology NAS that shows .L0CK3D files: isolate, preserve, find the way in, restore clean, with the signs to search for

If you find encrypted files, pull the network cable first. Do not reboot, format or reset, because a shutdown destroys volatile evidence. Power down only if you cannot isolate the device. Before anyone rebuilds it, save the ransom note, a few encrypted files, the DSM version, the package list and the logs, and keep the encrypted originals. Restore only from a backup that predates the attack, into a rebuilt and fully patched system, after you know how the attacker got in. Patching an infected box will not decrypt anything.

Storage appliances need the same patch discipline as servers

A NAS often sits in a cupboard with automatic updates off because someone once worried an update would break a share. By Synology's account, this campaign works on devices still missing a fix from December 2024; by 360's, on devices that skipped a critical update released six weeks before the notice. Put every NAS on the same patch schedule and asset list as your servers, and keep its management page off the internet.

Our safeguarding and hardening work covers exposed management interfaces and backup design, and our attack surface management service finds the NAS login pages you did not know were public. Open the chat and Yaali, our AI agent, will pass your question to an engineer.


Sources: Synology notice, October 29, 2026, Synology-SA-26:13, Synology-SA-24:20, IT-Connect, Gridinsoft, Synology knowledge base: immutable snapshots.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.