Synology NAS Ransomware Attacks: C3RB3R, DSM Vulnerabilities, and What Is Confirmed

The late-October Synology NAS ransomware reports reveal a patching and recovery problem, but the public evidence does not establish one entry point for every affected device. Synology's October 29 statement points to a vulnerability patched in December 2024. Security firm 360 attributes the incidents it investigated to two flaws disclosed in September 2026. These statements must be examined separately, rather than joined into a confirmed attack chain.

The practical questions are which services an attacker could reach, what access was obtained, and which data that access could change. This analysis, checked on October 31, 2026, separates the vendor's statement, published vulnerability capabilities and researcher observations. The companion guide explains why RAID, snapshots and backups can still leave recovery exposed.

Header photograph: DYVER / Wikimedia Commons, CC BY-SA 4.0. Cropped and resized; the photographic crop retains that license. Contextual NAS hardware photography, not a verified affected device or incident scene.

What Happened in the 2026 Synology NAS Ransomware Attacks?

Synology's October 29 notice confirms attacks against outdated DSM installations intended to encrypt data and demand payment. It references SA-24:20, an advisory covering several vulnerabilities. The notice itself does not name the specific CVE used in these attacks.

Separately, 360's October 29 investigation identifies C3RB3R, a Cerber variant, in sampled incidents and attributes entry to CVE-2026-13639 and CVE-2026-13684. That is a researcher's incident attribution, not a statement that Synology confirmed those vulnerabilities as the entry point in every case.

The operational urgency does not depend on resolving every attribution question first. An administrator can reduce unnecessary exposure and identify applicable patches immediately. Explaining precisely how a particular NAS was compromised requires its own evidence.

What Is C3RB3R Ransomware and How Does It Affect Files?

The sample behavior described by 360 includes encrypted files renamed with .L0CK3D, using the digit zero, and a note named read-me3.txt. The analysis distinguishes full encryption of selected file types from selective encryption of other files. These are reported sample characteristics, not a guarantee that every incident leaves identical artifacts.

Renaming an affected file back to its original extension does not reverse changes to its contents. A filename is a label; an application also needs the underlying bytes to retain their expected structure. A photo can still appear in a directory listing while no longer containing a usable image. Partial encryption can likewise make a large file unusable without modifying every byte.

Indicators help investigations, but they have limits. A missing ransom note does not prove a NAS is clean, and a familiar extension alone does not identify the entry vulnerability. Preserve representative artifacts and relevant logs without treating a filename as a complete diagnosis.

Which DSM Vulnerabilities Are Involved?

The distinction between the advisories matters technically. SA-24:20 was initially published in November 2024 and records subsequent revisions. It includes CVE-2024-10441, a critical system-plugin-daemon issue described as allowing unauthenticated remote code execution. Synology's later reference to a December patch should not be rewritten as the advisory's initial publication date.

SA-26:13 is dated September 18, 2026. Its descriptions of CVE-2026-13639 and CVE-2026-13684 concern insufficient entropy in login logic and output encoding in SCGI, respectively. Both describe remote arbitrary-file read/write and denial-of-service impact. Those capabilities do not, by themselves, document how a ransomware executable was launched.

The September advisory's fixed builds include 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 and 7.2.1-69057-12. These are advisory-specific floors, not a promise that they address every later security issue. Check the current model-supported release and affected packages.

How Can an Outdated NAS Become Remotely Exploitable?

A NAS is a server with storage attached. Its browser interface, sharing protocols, remote-access components and installed applications expose different request-processing paths. A vulnerability becomes externally useful only when its prerequisites are met, including a reachable affected component. “Connected to the internet” is too vague to describe that condition accurately.

Port forwarding can make a management service reachable from outside the home or office. A reverse proxy can expose the same application through a different hostname and TLS endpoint. Neither configuration inherently patches an application behind it. Conversely, remote-access features differ in how they route and authorize traffic; their names alone do not establish that an attack path existed.

There is also an endpoint route: malware running under a user's account may modify a mounted share using permissions that account already holds. It need not compromise DSM to corrupt those writable files. This is a general threat scenario, not an attribution for the October reports.

Why Do NAS Devices Remain Exposed After Patches Are Released?

Patch availability and patch deployment are different events. A vendor can publish a fix while an installation remains on an older build, a deferred update policy or an unsupported branch. A NAS can continue serving files normally throughout that interval. Service availability therefore tells the owner little about security-patch status.

Common operational obstacles include applications with uncertain compatibility, remote administrators without a maintenance window, and appliances whose update ownership was never assigned. These are plausible reasons for delay, not measured findings about this campaign's victims. For a business, a scheduled change with a rollback and recovery plan is more sustainable than repeatedly postponing every restart.

Record the complete DSM version, build and update suffix rather than only “DSM 7.” Routine security updates and migrations between major releases also require different planning. Confirm what the model supports and what the configured update policy actually installs. Enabling automatic updates is valuable; it does not replace checking support status and successful installation.

Why Is a NAS an Attractive Ransomware Target?

A NAS concentrates information that users cannot easily recreate: family photographs, project archives, shared work, accounting exports and endpoint backups. An attacker who can affect that collection may interrupt several activities at once. This concentration explains the potential leverage without assuming a specific ransom amount, victim count or criminal business model.

Always-on availability creates another asymmetry. The storage must be reachable to legitimate clients, often for years, while users may inspect its configuration only when something breaks. Each additional service can introduce a separate update and access-control responsibility. The relevant question is which functions genuinely need to be reachable, from where, and under whose credentials.

Storage and backup roles can also overlap. A device used to recover a workstation may contain the only remaining copy of older files. If the same compromise can modify both working data and recovery copies, the attacker gains leverage over availability and restoration together.

What Happens After Attackers Gain Access to NAS Storage?

The consequences depend on effective permissions, not simply on whether someone “got into the NAS.” A compromised ordinary account may affect its writable shares while leaving administration and inaccessible folders untouched. Broader privileges can expose additional paths. Backup repositories, attached drives and snapshot controls must each be evaluated rather than assumed to share one outcome.

This is why “MFA would have prevented it” and “MFA is useless” are both poor conclusions. MFA protects supported authentication flows against particular account attacks. It remains useful alongside patching and limited exposure. It cannot be assumed to interpose on an unauthenticated vulnerable operation.

What Do We Know, and What Remains Unconfirmed?

The existence of a patched vulnerability, an affected version and ransomware on the same device does not automatically prove causation. Investigators need a timeline connecting exposure, access and execution or file modification. Installation time matters too: a device updated after initial compromise may appear current when inspected later.

A claim involving a fully patched NAS deserves investigation, but does not establish a zero-day by itself. Relevant evidence includes the complete version at the suspected entry time, package versions, access logs, account activity and reachable services. A stolen credential or writable client share is a different explanation from a new DSM vulnerability.

Public reporting does not provide enough case-level evidence to assign one entry path, privilege level or recovery outcome to every affected NAS. This article therefore makes no campaign-wide claim about snapshot deletion, data exfiltration, infection totals or compromise of an entire product line.

What Does This Incident Reveal About NAS Security?

The wider lesson is a chain of operational responsibilities: know the appliance, know its reachable services, maintain supported software, and keep a recovery path outside the compromise's authority. These responsibilities reinforce one another. Reducing exposure can remove an entry path; restricted permissions can limit damage; independent recovery can reduce the consequences if prevention fails.

For an apparently unaffected system, verify installed builds and packages and reduce unnecessary access. For a system showing suspicious encryption or access activity, move into incident response rather than treating a routine update as cleanup. CISA's ransomware guide provides containment and recovery guidance. Isolate affected systems where practicable and preserve evidence with appropriate incident-response help.

Rebuilding a clean service and restoring trustworthy data are separate jobs. A successful update does not prove that access obtained earlier has been removed. The recovery side is examined in the companion analysis of NAS backup failure boundaries.

FAQ

Has Synology confirmed the two September 2026 CVEs as the entry point?

Not in the October 29 statement examined here. It references a December 2024 patch and SA-24:20. The two September CVEs are named in 360's attribution. Those observations should remain separate unless additional incident evidence connects them.

Does the incident prove every Synology NAS is vulnerable?

No. Applicability depends on the software branch, complete build, affected component and access conditions. A vendor-wide conclusion cannot be drawn from selected incident reports. Check the relevant advisory and the supported updates for the actual model.

Will MFA stop exploitation of an unauthenticated vulnerability?

MFA does not patch a vulnerability that can be reached without completing the protected login flow. It is still valuable against supported account-based attacks. Combine it with current software, restricted service exposure and appropriately limited permissions.

Can changing the .L0CK3D extension recover a file?

No. Restoring a filename does not decrypt or repair its contents. Preserve affected files and investigate recovery from a trustworthy earlier state. An indicator can guide investigation, but cannot determine the entry vulnerability on its own.

Does installing the latest update remove an existing compromise?

Not necessarily. Patching addresses covered vulnerable behavior; it does not establish whether an attacker already changed accounts, configuration or data. An affected installation needs containment, investigation and a clean recovery plan as well as supported updates.

Why discuss backup architecture alongside a software vulnerability?

Initial access and recovery failure are different problems. A single vulnerable service may start an incident, but shared credentials and reachable recovery copies can expand its consequences. Independent backups are intended to preserve a recovery option when another layer fails.

Conclusion

The Synology ransomware reports warrant urgent attention without requiring a simplified, unproven narrative. Keep the vendor's statement, advisory capabilities and researcher attribution distinct. Then examine the actual system: its complete software versions, exposed services, permissions and recoverable copies. A patch closes a documented weakness; a resilient storage design also limits the harm of an account compromise or another failure. The next article explains how to judge that recovery design.