Synology: three accounts of the attack, and a patch your screen never shows

On 29 October 2026 the vendor and the researchers published two different explanations of the same encryption campaign on the same day. The next day a third appeared that fits neither. Nobody is lying, and the interesting part is not who is right: it is what the three together say about the screen you look at to know whether you are up to date.

The case, in three lines. Since early October, a ransomware family called C3RB3R — a Cerber variant — has been encrypting Synology NAS devices and renaming files with the .L0CK3D extension. On 29 October, the anti-ransomware team at Chinese firm 360 published that the entry point was two flaws fixed on 18 September. That same day, Synology published a note on its own site saying attackers are exploiting "a vulnerability patched in December 2024" and linking to an advisory from two years ago. Both texts exist, both are signed, and neither cites the other.

The three accounts, side by side

The first two both fit

The contradiction dissolves in the build numbers. In SA-24:20, the version that fixes the 2024 flaw for the DSM 7.2.2 branch is 7.2.2-72806-1 or above. In SA-26:13, the one that fixes the September flaws for that same branch is 7.2.2-72806-9 or above. Counting -1 itself, that is eight builds where a device is current on the 2024 flaw and exposed to the 2026 one — assuming the numbering does not skip, which is our assumption.

The answer is boring: there are two different fleets. One has not been touched in two years and the 2024 flaw opens it; another was updated at some point, stalled before September, and the 2026 one opens it. Synology sees its cases, 360 sees its own, and both can be right about what they looked at. This reading is ours and nobody has confirmed it to us, but it is version arithmetic, not speculation.

The third one needs no zero day

The victim the response team documents was running DSM 7.4.1-90080 Update 1, a build published on 12 October and later than the one fixing the September flaws (7.4-90075). The comfortable reading is "so there is a zero day". But the report itself does not claim that: it warns it could not establish zero-day exploitation, nor whether the device was already compromised before it updated. That second door is the most mundane and the most likely: the campaign started in early October and the patch arrived mid-month.

And there is a third door that requires inventing nothing, because it is published and dated. On 22 October 2026, ten days after that build, Synology published advisory SA-26:14: two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both CVSS 9.8, remote code execution. And they are not in DSM.

Two patch inventories, one screen

The products affected by SA-26:14 are Synology Calendar, Mail Station and the PHP 7.3 to 8.4 runtimes. That is: packages. They are fixed by updating packages, each with its own version number, on a different screen. The DSM build can be spotless and those two nine-point-eights still be there. The advisory adds two details worth not skipping: Hyper Backup is not affected, and PHP 7.3 gets no fix because it is end of life. If one of your packages drags that PHP along, there is no button to press.

The 2024 flaw was on nobody's priority list

If Synology's account is the right one for your device, there is a detail worth facing. CVE-2024-10441 came out of a contest: the advisory is literally titled "DSM (PWN2OWN 2024)" and DEVCORE's research team appears in the acknowledgements, though the advisory does not say which team found which CVE. It has never entered CISA's known exploited vulnerabilities catalogue. For almost two years, anyone prioritising by that catalogue — and plenty do, reasonably — had this flaw below the cut line.

A note on dates, for honesty. Synology's note says "December 2024", but the SA-24:20 advisory page is dated 5 November 2024 and marked as updated on 28 March 2025. Synology advisories grow over time — products and fixed versions get added — so the note's date may refer to a later extension. We are not resolving it, because we do not have the advisory's change history. From the publication date to 29 October 2026 there are 723 days; counting from December, 693. The order of magnitude does not change.

This is not about a NAS. It is about where your backup lives

In most small companies we have come across, the same box does two jobs nobody decided to combine: it is the day-to-day file server and it is the backup target. Usually because it grew that way. Somebody bought a NAS to share folders, then somebody pointed the backup job at it because there was room, and nobody looked again.

Now look at what the middle column's vulnerabilities allow: arbitrary file write, unauthenticated, on that box. When the incident and the loss of your recovery happen on the same piece of metal, you do not have an incident with a backup: you have an incident. It is the same design error we described when we wrote about the backup server sitting inside the domain it has to rescue: the thing that saves you cannot depend on the thing that breaks.

And before somebody answers "sure, but my snapshots are immutable": immutability falls through the permission door far more often than through the encryption door, and we devoted a whole article to it — your immutable backup has a permission that deletes it. If the account that can switch retention off lives on the same box that just fell, retention is a preference.

Seven checks that hold under all three accounts

None of them depends on getting the entry route right. They take an afternoon.

When this does not apply to you

If your NAS is a secondary target, nothing reaches it from the internet, the backup job logs in with a dedicated account, and there is one more copy somewhere that box cannot touch, you do not have a problem this week: you have a free drill. Run the seven checks in an hour and get back to work. Saying so seems more useful to us than turning every piece of news into an emergency.

And the other way round: if the box is your only storage and you published it on the internet so somebody could work from home, the brand does not matter. This month it was one vendor's turn; the architecture of "a web-managed box that holds everything and updates through two different places" is identical across all of them.

Where this leaves us

We have not responded to any of these incidents and we have no telemetry of our own on the campaign: what we have is three advisory pages read in full and a calendar. But the conclusion is one we apply every day when we build a disaster recovery plan: the design is validated against the case where you do not know how they got in. If your plan only works when the forensic report arrives on time, it has a dependency you do not control.

The boring part — the box being inventoried, somebody knowing it has two update lists rather than one, and there being a window with an owner who signs off on it — is IT maintenance. If reading the seven points left you stuck on the fifth, which is where nearly everybody gets stuck, drop us a line and we will look at it together.