We're a little late covering this one because we were patching clients' Synology boxes. The work came before the write-up.
Tom's Hardware reported on October 29 that an internet-accessible Synology DS918+ had been hit by ransomware. According to the owner's account described in the report, the NAS was well behind on security updates. Their investigation pointed to CVE-2024-10441 as the likely way in. That is a suspected entry point, not a confirmed forensic finding from Synology.
The uncomfortable part isn't that a clever new attack defeated a freshly maintained system. Synology had already issued an advisory and fixes for that vulnerability. This was an older problem arriving at a box that still had work to do.
A quiet NAS can hide a busy business
A NAS rarely gets much attention when it's doing its job. You open a shared folder, save a drawing, retrieve a document and move on. It doesn't ask for a seat at the management meeting.
But put payroll records, customer files, project drawings or the office's backup destination on it, and that little box has a surprisingly large job description. Losing access could interrupt several parts of the business at once. Those are examples of what businesses may store, not a claim about the contents of this owner's NAS.
That makes it still works a very incomplete health check. It tells you that today's task succeeded. It doesn't tell you whether the software is maintained, who can reach the device or how tomorrow's recovery would go.
Having users isn't the same as having an owner
The people opening those files are doing their jobs. They shouldn't have to infer from a working folder whether a security advisory applies, a backup failed overnight or a recovery copy is reachable by the same account as the original. Reporting a problem is a reasonable expectation of a user. Quietly becoming the administrator is a different job.
Someone needs explicit responsibility for the system's upkeep: an internal IT person, a managed service provider or another suitably qualified person with time and authority to do the work. That includes following advisories, planning updates, investigating failed backup jobs and testing restores. Somebody else also needs to know how to take over when that person is away.
This isn't a claim about who was responsible in the reported incident. It's the business question the story brings to mind: is the NAS actually managed, or does everyone simply know how to use it?
The fix was already on the shelf
Synology's advisory identifies CVE-2024-10441 as a critical remote code execution vulnerability and lists repaired DSM releases, including 7.2.2-72806-1, 7.2.1-69057-6 and 7.2-64570-4. These are historical minimum fixes for the listed branches, not a recommendation to stop updating at those versions. The appropriate supported release depends on the device and its upgrade path.
For a business, the useful conversation is wonderfully specific: which DSM build is running, which applicable advisory does it address, and what happened when someone checked after the update? A reassuring status message is a starting point. Comparing the installed build against the vendor's guidance is better evidence.
There can be perfectly sensible reasons to plan an upgrade carefully. Applications may depend on a particular release, and nobody enjoys discovering a compatibility problem halfway through the working day. But a delayed change still needs an owner, a date and a way to reduce exposure while it waits. Otherwise a temporary exception becomes the permanent arrangement nobody remembers approving.
Backups saved the files. What saves the working day?
The encouraging detail in the report is that the owner apparently avoided losing data because they had a 3-2-1 backup arrangement. That's worth more attention than another joke about somebody forgetting an update.
For a business, though, having recoverable files and being ready to resume work are different milestones. Where would you restore them? Who has the credentials? Can staff reach the replacement location? How long could invoicing, scheduling or production wait?
I'd rather find those answers during a small restore test than discover them with a customer waiting. Keep a recovery copy isolated from the access that could compromise the working system, and verify that the recovery process actually works. A successful backup notification is not a rehearsal.
Remote access deserves the same attention. If a NAS management interface is reachable directly from the internet, review whether that exposure is necessary. A properly maintained VPN or another controlled access path can reduce exposure, but it doesn't replace patching or make compromise impossible.
If there are signs of intrusion, patching is only part of the response. Preserve relevant evidence, investigate what was accessed and establish a clean recovery path; installing a fix doesn't remove whatever an attacker may already have left behind.
Managing that recovery is a job, too. Someone reviews failed backup jobs, decides what gets tested and makes sure the instructions and credentials are available when needed. Buying a backup product doesn't assign any of those responsibilities by itself.
The goal isn't to turn every employee into a Synology administrator. It's to give the technology a named caretaker, an agreed maintenance routine and a recovery plan somebody has tried. Your staff can get on with using the shared drive. Keeping it dependable is a job of its own.
Sources and further reading
