Synology DSM flaw lets remote attackers run commands without logging in

Synology has warned that a critical flaw in DiskStation Manager can let unauthenticated remote attackers execute arbitrary commands on affected systems. The issue, tracked as CVE-2026-32746, affects the telnetd component from GNU Inetutils and carries a CVSS v3.1 score of 9.8, which puts it in the critical tier.

For admins, the immediate takeaway is simple. Patch DSM now if your NAS runs an affected release, and disable Telnet if you cannot update right away. Synology says DSM 7.3 should move to 7.3.2-86009-3 or newer, DSM 7.2.2 should move to 7.2.2-72806-8 or newer, and DSM 7.2.1 should move to 7.2.1-69057-11 or newer. DSMUC 3.1 remains under ongoing remediation.

The vulnerability matters because NAS boxes often hold backups, shared files, and business data in one place. A pre-auth remote code execution bug on an internet-exposed or internally reachable storage appliance can give an attacker a fast path to ransomware deployment, data theft, or long-term persistence inside a network. That risk becomes even harder to justify because the affected service is Telnet, an older plaintext protocol that many organizations no longer need.

What the Synology vulnerability does

Synology’s advisory says CVE-2026-32746 may allow unauthenticated remote attackers to execute arbitrary commands. The underlying bug sits in GNU Inetutils telnetd through version 2.7, where the LINEMODE SLC handler can write out of bounds because the add_slc function does not verify that the buffer is already full.

In plain terms, an attacker can send specially crafted input to the Telnet service and trigger memory corruption before any login happens. That makes the issue especially serious on systems where Telnet remains enabled and reachable over the network.

Why admins should treat this as urgent

A CVSS score of 9.8 usually means the flaw checks all the wrong boxes at once: remote access, no authentication, no user interaction, and high impact across confidentiality, integrity, and availability. NVD lists the vector as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which matches that risk profile.

For Synology customers, the danger does not come from a complicated multi-step exploit chain. It comes from an exposed service that should not stay on any longer than necessary. If Telnet is enabled on a NAS appliance that stores core business data, the exposure can turn a single software flaw into a much larger incident.

Affected products and fixed versions

Source: Synology security advisory.

What Synology says you should do now

Synology recommends disabling the Telnet service to reduce risk. The company says admins can do that by going to Control Panel, then Terminal, unchecking Enable Telnet service, and clicking Apply.

That advice matters even if you plan to patch quickly. Turning off Telnet cuts off the specific exposure path tied to this flaw, which gives teams a cleaner window to schedule upgrades and verify which systems still rely on the service.

Practical response checklist

• Identify every Synology device running DSM 7.3, 7.2.2, 7.2.1, or DSMUC 3.1
• Check whether Telnet is enabled on any of those systems
• Disable Telnet immediately where business operations allow
• Upgrade affected DSM releases to Synology’s fixed builds
• Keep watch for the DSMUC 3.1 patch if you run that platform
• Review firewall rules and exposure to port 23
• Audit logs and admin activity for unusual access or configuration changes

What security teams should watch for

• NAS appliances with Telnet enabled
• Internet-facing management services on Synology devices
• Old operational scripts that still depend on Telnet
• Delayed patching on backup or archival appliances
• Systems running DSMUC 3.1 while Synology finishes remediation

FAQ