Full Disclosure mailing list archives

# 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)