FR
live

Synology patches DSM vulnerabilities without naming them, and that is a problem for your NAS

On October 12, 2026, Synology shipped DSM 7.4.1-90080 Update 1, marked Important, without listing any CVE or detail on the fixed flaws. Install the update anyway, but demand transparency and harden your NAS like the target it is.

A small dark NAS enclosure on a metal shelf, one amber status LED glowing alone on its faceplate, the rest of the front panel in darkness.

October 12, 2026. Synology ships DSM 7.4.1-90080 Update 1, marked “Important”. The same day. The official release note amounts to one line: “Fixed multiple security vulnerabilities (undisclosed details).” October 2026. The specialist press notes that no CVE is listed. Why it matters: a NAS vendor — the device class ransomware and proxyjacking target first — is asking you to patch without telling you what it fixed.

A security update with no content

The observation is factual. Version DSM 7.4.1-90080 Update 1 fixes, according to the vendor, “several security vulnerabilities,” but the changelog provides no CVE identifier, no Synology-SA advisory number, no severity, no vector. Marius Hosting, which documents every system update, writes it plainly: “this update includes security enhancements, though Synology has not disclosed specific CVEs or detailed changelog entries.”

That silence is not trivial, because it breaks with the vendor’s usual practice. Synology regularly publishes Synology-SA advisories detailing flaws, their CVSS severity and the affected models — that channel is how an administrator learns whether their box is exposed and whether to patch urgently or schedule a maintenance window. An “Important” update tied to no advisory deprives the administrator of the information they need to prioritize. They are being asked to trust, not to decide.

Why the NAS can no longer be treated lightly

Context gives the problem its real weight. The NAS has become the favorite target of two distinct criminal economies. The first is ransomware: a storage device holds, by definition, the data a victim will pay to recover, and campaigns targeting Synology and QNAP boxes number in the dozens since 2021. The second is proxyjacking: hijacking a residential device’s bandwidth and compute to resell traffic, like the campaign that monetized 143 D-Link NAS and Ubiquiti NVRs in October — an episode we covered.

A device that stores everything and, too often, listens on the internet through QuickConnect, an open UPnP port or a poorly managed port-forward is a high-risk asset. That is exactly what makes Synology’s silence costly: the administrator of an exposed NAS needs to know whether the fixed flaw is remotely exploitable without authentication, to measure their exposure between publication day and their box’s reboot.

That exposure is not hypothetical. A device reachable on port 5001 behind a weak password is, to automated scanning, indistinguishable from thousands of others that fell the same way — the same scanning that feeds both ransomware and proxyjacking campaigns. The difference between a breached NAS and a safe one is rarely the firmware version alone: it is whether the box was ever exposed to the internet, and whether the administrator knew it was. A silent changelog hurts most precisely for the administrators in the first group, who need the clearest possible signal about how urgently to act.

What to do — and what to demand

The first reaction is counterintuitive but correct: install the update anyway. A silent security fix is still a security fix, and an unpatched NAS is a certain risk, where an opaque changelog is only an information risk. The right reflex breaks down like this:

  • Install the update on every model, starting with those reachable from outside.
  • Harden immediately after: disable QuickConnect and direct exposure, turn off UPnP, place the box in a dedicated VLAN, and enable two-factor authentication plus automatic login-attempt blocking.
  • Back up with the 3-2-1 rule, keeping an offsite copy that is not permanently mounted to the NAS — ransomware also encrypts local backup drives.
  • Monitor login logs and device alerts, and subscribe to the Synology-SA page so advisories reach you when they eventually land.

The second demand is editorial as much as technical. Hold the vendor to account. A “details undisclosed” note on an exposed storage device is not security communication: it is the absence of communication. Customer pressure — home users and businesses alike — is the only lever that pushes a vendor to publish, even late, the detail of a flaw it would rather keep quiet.

What normal transparency looks like

The comparison with the neighbor is instructive. QNAP, the other major NAS vendor, publishes a QSA (QNAP Security Advisory) for each fix, listing the CVEs, CVSS scores and affected models — the same standard as Synology-SA. That standard is what lets an administrator answer the only question that matters: is my box affected, and how fast must I patch?

The sector’s recent history explains why the question is not theoretical. The Deadbolt and Qlocker ransomware strains mass-encrypted NAS devices exposed through QuickConnect and myQNAPcloud between 2021 and 2022, and the campaigns never stopped. A NAS with a weak password or firmware that lags a few weeks is statistically a victim in waiting. When a fix arrives without explanation, the conscientious administrator has no choice but to patch — or cut external access while they wait.

A minimal hardening requires no particular expertise. Disabling the default admin account, enforcing strong authentication, restricting SSH access to an administration subnet, and confirming the box is not reachable from the internet are steps that take an hour:

bash
# Confirm the box does not answer from outside (run off the local network)
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://<public-ip>:5001 || echo "unreachable — that is the point"

The silent update is not a reason to skip patching. It is a reason to patch and shrink the exposure surface in the same pass — the two actions reinforce each other, and neither replaces the other.

The three questions Synology leaves unanswered

A “details undisclosed” note is not neutral: it strips an administrator of three pieces of information that determine their reaction. The first is scope: which models and components are affected — DSM itself, Surveillance Station, Drive, or an auxiliary service. The second is severity: a CVSS 9.8 flaw exploitable remotely without authentication is not handled like a local CVSS 5 flaw. The third is exploitability: if a proof of concept is already circulating, the patch window is measured in hours, not weeks.

Without those three answers, the administrator is forced into a worst-case stance — treating every update as if it closed a critical breach. Paradoxically, that is the right operational call: on an exposed device, the cost of an unplanned reboot is lower than the cost of a compromise. But forced caution has a price: improvised maintenance windows, interrupted services, and eroded trust in a vendor that turns a piece of security information into a black box.

The silence also has an invisible consequence. When a vendor does not publish details, it cannot correct its own communication later without admitting the omission. Every opaque update adds a layer of trust debt that will eventually come due the day a real incident hits — and customers demand to know, precisely, what had been silently fixed.

Verdict

If your NAS is exposed to the internet, patch today, without waiting to learn what the update fixes: the cost of one more unpatched day exceeds the cost of one missing detail. If your NAS is properly segmented and backed up, treat this silence as a governance signal — a storage vendor that does not document its security fixes deserves to be challenged every cycle, and replaced if it keeps treating you as a mere executor.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

FileBrowser Quantum 2.0 adds activity logs and per-source permissions

The FileBrowser Quantum fork reached 2.0 stable on October 9, 2026 with an activity log, per-storage-source permissions, and a BoltDB-to-SQLite migration, followed on October 13 by a fix for two security flaws. Prepare a real migration procedure before upgrading your 1.x instances.

Plex2Shell: the Plex Media Server exploit chain went from PoC to crypto mining in 24 hours

On October 16, 2026, researcher Zach Main published Plex2Shell, a chain of four flaws — CVE-2026-96652, 96654, 96655 and 96656 — enabling unauthenticated remote code execution on Plex Media Server. By October 17, attackers were deploying an XMRig miner and a residential proxy on exposed servers: update to 1.43.3.10861 and take Plex off the public internet.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss