Full Disclosure mailing list archives

Synology stale DNS allows practical interception of traffic from vulnerable DSM clients

From: shed riot

Date: Wed, 22 Jul 2026 09:27:45 +0100

Synology stale DNS allows practical interception of traffic from vulnerable DSM clients Vendor case: 904909 Suggested severity: High ## Customer advisory Synology customers using the affected DSM and Relayd versions listed below should upgrade immediately. The relevant man-in-the-middle vulnerabilities were fixed in DSM 6.2.3-25426 Update 3. Customers should install the latest DSM version available for their device, and in no case remain on a version earlier than DSM 6.2.3-25426 Update 3 where that update is supported. Devices that cannot run this or a later version should be considered unsupported and unsafe for QuickConnect or relay-based communication. They should be replaced, retired, or isolated from Synology cloud services. ## Summary Previously disclosed vulnerabilities in Synology DSM allowed an attacker positioned between a NAS and Synology's infrastructure to impersonate Synology servers, intercept sensitive information, and, in some cases, manipulate traffic or execute commands. Those vulnerabilities included: CVE-2021-26560, cleartext transmission by `synoagentregisterd`, allowing an attacker to spoof a Synology server. CVE-2021-26561 and CVE-2021-26562, memory-corruption vulnerabilities reachable through the same man-in-the-middle position. CVE-2021-26564 and CVE-2021-26565, allowing `synorelayd` traffic to be intercepted or redirected. CVE-2021-26566, allowing manipulated inbound QuickConnect traffic to result in command execution. Synology fixed these issues in DSM 6.2.3-25426 Update 3. The new finding described in this advisory is a separate infrastructure condition that makes exploitation of those old client vulnerabilities practical. Synology hostnames were observed resolving to ephemeral cloud IP addresses. Synology subsequently released those addresses back to the cloud provider while client devices continued to retain the old DNS result in cache. When a released address was acquired by a third party, affected clients continued sending traffic intended for Synology to the new, attacker-controlled system. This does not require DNS poisoning, ARP spoofing, phishing, a malicious website, or a conventional on-path position. The stale DNS record itself directs the client to the attacker. ## Observed interception in the wild During a two-week period, four separately released cloud IP addresses previously used by Synology infrastructure were acquired and monitored. The supplied traffic captures cover four collection events between 7 July and 16 July 2026. They contain: 28 HTTP or HTTPS requests intended for Synology services. 23 distinct client endpoints. 22 unique NAS serial numbers, plus one additional client that did not include its serial number in the captured request. 10 plaintext `synoagentregisterd_dsm` requests. 14 `Synology Relayd` requests. Four additional QuickConnect requests. The traffic was received without targeting individual customers and without interfering with Synology's DNS records. The clients contacted addresses that had legitimately been released by Synology and subsequently assigned to the collection system. This is therefore not a theoretical attack scenario. It is a definitive example of real Synology customer traffic being delivered to a third-party-controlled endpoint. ## Information exposed The information varied by request type, but the captured traffic included: Authentication keys and token values. NAS serial numbers and model identifiers. MAC addresses. QuickConnect aliases and server identifiers. HTTP session cookies. Internal IPv4 and IPv6 addresses. Internal gateways and network masks. DDNS hostnames. Enabled services and internal or externally mapped service ports. DSM management ports. Device time zones and other system metadata. The plaintext `/finder/set.php` requests exposed device identifiers, tokens, internal addresses and management ports directly over HTTP. The TLS-based requests successfully connected to a collection system using a self-signed certificate. This demonstrates that the affected clients did not meaningfully authenticate the remote server before transmitting request data. Whether every captured token could subsequently be replayed is not necessary to establish the confidentiality impact. The security failure occurred when private customer and device data intended for Synology was delivered to an unauthorised third party. ## Affected traffic paths The intercepted requests were intended for hostnames including: `relayinfo.synology.com` `global.quickconnect.to` `dec.quickconnect.to` `ukc.synology.com` The traffic included requests to: `/finder/set.php` `/Serv.php` `/alias_update.php` Cisco Talos previously documented the same `synoagentregisterd` sequence. A DSM device first requested a finder server from `global.quickconnect.to`, then transmitted its serial number, token, network addresses and DSM ports using plaintext HTTP. Talos concluded that both stages could be modified by a man-in-the-middle attacker. Talos also documented QuickConnect server impersonation capable of stealing device credentials through the `synorelayd` and HTTP-redirection flow. The stale-DNS condition supplies the attacker-controlled endpoint required by these vulnerabilities without requiring the attacker to compromise DNS or obtain an existing network position. ## Captured client versions All captured clients pre-date DSM 6.2.3-25426 Update 3. | Captured version | Identified models | Distinct endpoints | | ------------------------ | ----------------------- | -----------------: | | Synology Relayd 1.0-3211 | Model not disclosed | 1 | | Synology Relayd 1.0-3810 | Model not disclosed | 1 | | Synology Relayd 1.0-3827 | DS210j, DS212j, DS710+ | 4 | | Synology Relayd 1.0-4493 | DS214+, DS414slim | 5 | | DSM 5.0-4528 | DS214play | 1 | | DSM 5.0-4528 Update 1 | DS713+ | 1 | | DSM 5.0-4528 Update 2 | DS213j | 1 | | DSM 5.2-5592 Update 4 | DS214se | 1 | | DSM 5.2-5967 Update 9 | DS1010+, DS115j, RS815+ | 4 | | DSM 6.0-8451 | DS416j | 1 | | DSM 6.0-8754 Update 8 | DS215+, DS216j | 3 | | Total | | 23 | ## Required remediation ### Devices that support the patched DSM release The following identified models can install DSM 6.2.3-25426 Update 3 or a later DSM release: DS212j DS213j DS214+ DS214play DS214se DS215+ DS216j DS414slim DS416j DS713+ DS115j RS815+ Owners should install the latest DSM version currently offered for the specific model. DSM 6.2.3-25426 Update 3 is only the minimum version known to contain the relevant fixes and should not be treated as the preferred current version. Synology's model release notes confirm availability of the fixed branch for these hardware generations. ### Devices with no patched DSM release The following captured 10-series models are limited to DSM 5.2 and cannot install the fixed DSM branch: DS1010+ DS210j DS710+ Synology states that DSM 5.2 was the final major DSM release for 10-series devices. There is therefore no safe software upgrade for these devices in relation to the vulnerabilities described in Synology-SA-20:26. Customers should replace or retire them. Until replacement, owners should disable QuickConnect and related relay functionality, restrict outbound connectivity to Synology relay and finder services, and prevent the devices from transmitting sensitive registration data over the internet. The two unidentified clients using Relayd 1.0-3211 and 1.0-3810 should be identified by their owners. If their hardware cannot install DSM 6.2.3-25426 Update 3 or later, the same replacement recommendation applies. ## Historical exposure It is not known: How long Synology's infrastructure has released ephemeral addresses while DNS caches remained valid. How frequently previously used addresses have been acquired by unrelated cloud customers. Whether other parties deliberately searched for and acquired released Synology addresses. How many clients have previously sent requests to unintended recipients. How much customer data may have been collected before this report. Whether any exposed keys, tokens or session values were replayed or otherwise abused. Four independent ephemeral addresses were encountered during a short observation period. This suggests that the condition was repeatable rather than an isolated cloud-allocation anomaly. The absence of known reports of exploitation cannot establish that prior interception did not occur. A party receiving this traffic would not need to interact with the affected NAS, modify a request, or trigger an observable failure. Passive collection could occur without the customer or Synology becoming aware of it. ## Vendor disclosure timeline | Date | Event | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 7 July 2026 | Initial report submitted to Synology with a captured traffic log. | | 8 July 2026 | Synology classified the issue as a hardening suggestion, stating that a complete exploit had not been demonstrated and referring to phishing or fake-site behaviour that was not part of the report. | | 8 July 2026 | Synology was informed that the attachment contained live third-party traffic, identifiers and token values, and was asked to consider notifying the affected customers. | | 9 July 2026 | Synology acknowledged that the log contained live traffic and token-like values, but said replay or account compromise had not been demonstrated. | | 9 July 2026 | Synology was informed that its HTTPS traffic had connected to a self-signed collection endpoint, demonstrating ineffective certificate validation. | | 9 July 2026 | Synology described the result as, at most, limited information exposure. | | 9 to 16 July 2026 | Additional released IP addresses were acquired and further independent batches of customer traffic were captured and supplied. | | 22 July 2026 | Synology stated that the TLS certificate-validation behaviour had been fixed in later DSM versions and maintained that the report was not bounty eligible. | | 22 July 2026 | Synology was reminded that the stale-DNS condition made the old client vulnerability practically exploitable and that the duration and historical extent of exposure were unknown. | | 22 July 2026 | Synology stated that it would adjust the configuration of `relayinfo.synology.com` to further reduce the risk. | | 22 July 2026 | Synology maintained the "hardening suggestion" classification and declined a monetary reward. | ## Assessment of Synology's response Synology is correct that every client observed in the captures was old and pre-dated the relevant security update. That fact does not invalidate the finding. The stale-DNS condition was present in Synology-controlled infrastructure at the time of reporting. It transformed a previously patched client vulnerability into a practical mechanism through which real, still-operational customer devices delivered information to an attacker-controlled endpoint. Synology initially said the scenario had not demonstrated control of a released IP address, even though the supplied log existed because such an address had already been acquired. It subsequently acknowledged that the log contained live traffic, but required proof that the leaked values could be used for further unauthorised actions before accepting that meaningful impact existed. This conflates confidentiality impact with subsequent account compromise. The interception and unauthorised receipt of customer information is itself a security impact. Synology's current public bounty rules state that: Reports should demonstrate practical impact on customer data, devices or services. Critical findings involving outdated products may still be accepted depending on the circumstances. Synology web services under `.synology.com` are within scope. The programme exists to maintain the safety of Synology customers. The report demonstrated practical impact on customer data and involved the current configuration of a Synology web service. Synology then confirmed that it would change that configuration to reduce the reported risk, while retaining its position that the report was merely a non-rewardable hardening suggestion. In the researcher's view, repeatedly minimising the interception of live customer traffic, declining to treat confidentiality loss as impact, and applying an infrastructure change without recognising the reported vulnerability represents bad-faith operation of a bug bounty programme. This is an assessment of Synology's handling, not a claim that current DSM releases remain vulnerable to the already patched client flaw. ## Conclusion This disclosure does not claim that current patched DSM clients are vulnerable to CVE-2021-26560 or CVE-2021-26564 through CVE-2021-26566. It demonstrates that: 1. Vulnerable pre-patch Synology devices remain active on the public internet. 2. Synology's use and release of ephemeral cloud addresses created a repeatable stale-DNS condition. 3. The stale-DNS condition directed those vulnerable clients to unrelated third-party systems. 4. Four independently acquired addresses received 28 requests from 23 distinct client endpoints. 5. Those requests exposed real customer, device, network and authentication-related data. 6. It is not known how long this has been possible or how often similar interception has occurred. 7. Synology changed its infrastructure configuration only after the issue was reported, but declined to recognise the submission as a bounty-eligible vulnerability. Customers using DSM versions earlier than 6.2.3-25426 Update 3 should upgrade immediately. Customers whose hardware cannot run a patched version should replace or retire the affected device. _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

• Synology stale DNS allows practical interception of traffic from vulnerable DSM clients shed riot (Jul 22)