Ransomware is locking Synology NAS drives — and Synology and 360 disagree on how it gets in

Since October, a ransomware strain called C3RB3R has been encrypting files on Synology network-attached storage (NAS) devices and renaming them with a .L0CK3D extension. Synology says the attackers exploit an old, patched flaw on devices running outdated software. Qihoo 360, which analysed infected devices, says they get in through two critical bugs Synology fixed only in September — CVE-2026-13639 and CVE-2026-13684, both rated 9.8 out of 10. You don't need to settle the argument to protect yourself: update DSM to the September builds, and take the NAS's admin interface off the internet.

What happened, in plain English

A NAS is a small file server — the box in the office or at home that holds shared folders, photo libraries and, often, the backups of everything else. Synology is one of the most common brands, and its operating system is called DSM (DiskStation Manager).

On September 18, 2026, Synology published security advisory SA-26:13, fixing eight flaws in DSM. Two were critical: one in the login logic, which uses values that are too predictable ("insufficient entropy"), and one in SCGI, the layer that passes web requests to DSM's internal programs. Both let a remote attacker who has no password read or write arbitrary files on the device. Being able to write any file on a server is usually one short step from taking it over.

Weeks later, owners started reporting locked files. On October 29, Synology issued a statement saying threat actors were "exploiting a vulnerability patched in December 2024 to target devices running outdated versions of DSM," linking to its 2024 advisory SA-24:20. The same day, Chinese security firm 360 published a warning based on devices it had examined, stating that "the entry point of this round of attacks was two high-risk remote vulnerabilities," naming the two September CVEs.

The attackers leave a note called read-me3.txt in every encrypted folder and sell a "C3rb3r Decryptor" through a dark-web portal, according to BleepingComputer. Neither Synology nor 360 has given a victim count; 360 says it received "multiple" requests for help.

Are you affected? What to do now

If your Synology NAS is reachable from the internet and has not been updated since mid-September, treat it as at risk.

Check and update DSM (Control Panel > Info Center shows the version; Control Panel > Update & Restore installs updates):

• 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 builds fix the September flaws and also include the 2024 fix, so they cover both explanations at once.

• On DSM 7.2.0, 7.1, 7.0 or 6.2? SA-26:13 does not list these branches, and the CVE record marks versions below 7.2.1 as "unknown." The 2024 fixes exist (7.2-64570-4, 7.1.1-42962-7, 6.2.4-25556-8), but that only addresses Synology's explanation. Move to a branch listed above if your model supports it; if it doesn't, keep the device off the internet entirely and plan to replace it.
• Turn on automatic DSM updates, as Synology recommends.

Close the door from the outside:

• Don't expose the DSM admin interface (ports 5000/5001 by default) to the internet. Check your router for port forwarding and UPnP rules that point at the NAS. For remote access, use a VPN or Synology's relay service instead, as 360 advises. Shadowserver tracks more than 380,000 internet-exposed Synology NAS devices.
• Disable the default admin account, use strong passwords, enable two-step verification and auto-block for repeated failed logins.
• Remove share links, packages and services you don't use.

Update the packages too. Synology's separate advisory SA-26:14 covers PHP2Shell in its PHP, Calendar and Mail Station packages. In Package Center, update PHP 7.4 through 8.4, Synology Calendar and Mail Station. PHP 7.3 gets no fix — uninstall it if nothing needs it. Synology says DSM's own built-in PHP is not exposed externally and rates that risk as very low.

Make sure you can recover:

• Enable Btrfs snapshots with immutable (tamper-protected) snapshots where your model supports them, and check they are actually being created.
• Keep at least one backup that is offline or disconnected. A NAS that syncs to the cloud or to another NAS can faithfully replicate encrypted files.

If your files are already .L0CK3D:

• Disconnect the NAS from the network and pause sync and backup jobs (Cloud Sync, Hyper Backup, Drive) so encrypted files don't overwrite good copies elsewhere.
• Don't reset or reformat. Preserve read-me3.txt, a few encrypted files and the logs.
• Check for snapshots taken before the encryption — on Btrfs volumes, these are often the fastest route back.
• Get incident response help before restoring, and patch before reconnecting. Paying is not a reliable route back, and an update does not decrypt files that are already locked.

The expert view

Both explanations are technically credible, and they may well both be true for different victims.

SA-24:20's critical bug, CVE-2024-10441, is a 9.8 unauthenticated code-execution flaw in DSM's system plugin daemon, demonstrated at Pwn2Own in 2024. Any device left on a 2024-era build is a straightforward target, and the population of NAS boxes that were set up once and never touched again is large. That fits Synology's framing of "outdated versions."

The September pair fits 360's evidence and a different population. An unauthenticated arbitrary file write — which both CVE-2026-13639 and CVE-2026-13684 provide — rarely stays a file-write bug for long: overwriting a script, a scheduled task or a configuration file that DSM executes turns it into code execution. The login-logic flaw is especially notable because predictable values in an authentication path tend to mean an attacker can forge or guess something that should be secret. If 360 is right, devices that were current in early September but missed the September 18 update were exposed — a group Synology's statement does not address.

Synology has not refuted 360's finding; its press release simply does not mention SA-26:13. Neither party has published a full technical analysis of the intrusion chain, so the honest position is that the entry vector is disputed and possibly plural. The practical consequence is the same either way — the current builds fix both — but the framing matters for risk assessment: "only neglected devices are at risk" is a less alarming message than "devices that missed one update in September are at risk."

The encryption itself leaves little room for a technical rescue. 360 describes per-file ChaCha8 keys and nonces protected with RSA-2048, a standard construction with no known weakness, and lists one sample hash (MD5 a1375e0f82ae86df528876c049b5a23c). Recovery will come from snapshots and offline backups, not cryptanalysis. That is the broader lesson of NAS ransomware: the device people use as their backup is often the one thing nobody backs up.

Official sources

• Synology-SA-26:13 DSM — Synology, September 18, 2026 (CVE-2026-13639, CVE-2026-13684 and six others; fixed builds)
• Synology statement on C3RB3R — Synology, October 29, 2026
• Synology-SA-24:20 DSM (Pwn2Own 2024) — Synology, November 5, 2024 (CVE-2024-10441; 2024 fixed builds)
• Cerber勒索攻击群晖NAS事件预警 — Qihoo 360, October 29, 2026 (entry-vector claim, encryption details, IOC)
• Synology-SA-26:14 PHP2Shell — Synology, October 22–31, 2026 (PHP, Calendar, Mail Station packages)
• Security Alert: Ransomware Attacks Targeting Synology NAS Devices — HKCERT, November 2, 2026

Coverage: BleepingComputer (ransom note, Shadowserver exposure figure); CSA Singapore alert (SA-26:13, September 23, 2026).