GCVE-1988-2026-0157
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-11 11:36
VLAI
EPSS
VEX
Title
Synology stale DNS allows practical interception of traffic from vulnerable DSM clients
Summary
# 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 t
Severity
No CVSS data available.
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://vuln.freearchive.org/archive/full-disclos… | technical-description |
| https://seclists.org/fulldisclosure/2026/Jul/28 | technical-description |
| https://nmap.org/mailman/listinfo/fulldisclosure | |
| https://seclists.org/fulldisclosure/ |
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"product": "stale DNS",
"vendor": "Synology",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "shed riot"
}
],
"descriptions": [
{
"lang": "en",
"value": "# Synology stale DNS allows practical interception of traffic from\nvulnerable DSM clients\n\nVendor case: 904909\nSuggested severity: High\n\n## Customer advisory\n\nSynology customers using the affected DSM and Relayd versions listed below\nshould upgrade immediately.\n\nThe relevant man-in-the-middle vulnerabilities were fixed in DSM\n6.2.3-25426 Update 3. Customers should install the latest DSM version\navailable for their device, and in no case remain on a version earlier than\nDSM 6.2.3-25426 Update 3 where that update is supported.\n\nDevices that cannot run this or a later version should be considered\nunsupported and unsafe for QuickConnect or relay-based communication. They\nshould be replaced, retired, or isolated from Synology cloud services.\n\n## Summary\n\nPreviously disclosed vulnerabilities in Synology DSM allowed an attacker\npositioned between a NAS and Synology\u0027s infrastructure to impersonate\nSynology servers, intercept sensitive information, and, in some cases,\nmanipulate traffic or execute commands.\n\nThose vulnerabilities included:\n\n* CVE-2021-26560, cleartext transmission by `synoagentregisterd`, allowing\nan attacker to spoof a Synology server.\n* CVE-2021-26561 and CVE-2021-26562, memory-corruption vulnerabilities\nreachable through the same man-in-the-middle position.\n* CVE-2021-26564 and CVE-2021-26565, allowing `synorelayd` traffic to be\nintercepted or redirected.\n* CVE-2021-26566, allowing manipulated inbound QuickConnect traffic to\nresult in command execution.\n\nSynology fixed these issues in DSM 6.2.3-25426 Update 3.\n\nThe new finding described in this advisory is a separate infrastructure\ncondition that makes exploitation of those old client vulnerabilities\npractical.\n\nSynology hostnames were observed resolving to ephemeral cloud IP addresses.\nSynology subsequently released those addresses back to the cloud provider\nwhile client devices continued to retain the old DNS result in cache. When\na released address was acquired by a third party, affected clients\ncontinued sending traffic intended for Synology to the new,\nattacker-controlled system.\n\nThis does not require DNS poisoning, ARP spoofing, phishing, a malicious\nwebsite, or a conventional on-path position. The stale DNS record itself\ndirects the client to the attacker.\n\n## Observed interception in the wild\n\nDuring a two-week period, four separately released cloud IP addresses\npreviously used by Synology infrastructure were acquired and monitored.\n\nThe supplied traffic captures cover four collection events between 7 July\nand 16 July 2026. They contain:\n\n* 28 HTTP or HTTPS requests intended for Synology services.\n* 23 distinct client endpoints.\n* 22 unique NAS serial numbers, plus one additional client that did not\ninclude its serial number in the captured request.\n* 10 plaintext `synoagentregisterd_dsm` requests.\n* 14 `Synology Relayd` requests.\n* Four additional QuickConnect requests.\n\nThe traffic was received without targeting individual customers and without\ninterfering with Synology\u0027s DNS records. The clients contacted addresses\nthat had legitimately been released by Synology and subsequently assigned\nto the collection system.\n\nThis is therefore not a theoretical attack scenario. It is a definitive\nexample of real Synology customer traffic being delivered to a\nthird-party-controlled endpoint.\n\n## Information exposed\n\nThe information varied by request type, but the captured traffic included:\n\n* Authentication keys and token values.\n* NAS serial numbers and model identifiers.\n* MAC addresses.\n* QuickConnect aliases and server identifiers.\n* HTTP session cookies.\n* Internal IPv4 and IPv6 addresses.\n* Internal gateways and network masks.\n* DDNS hostnames.\n* Enabled services and internal or externally mapped service ports.\n* DSM management ports.\n* Device time zones and other system metadata.\n\nThe plaintext `/finder/set.php` requests exposed device identifiers,\ntokens, internal addresses and management ports directly over HTTP.\n\nThe TLS-based requests successfully connected to a collection system using\na self-signed certificate. This demonstrates that the affected clients did\nnot meaningfully authenticate the remote server before transmitting request\ndata.\n\nWhether every captured token could subsequently be replayed is not\nnecessary to establish the confidentiality impact. The security failure\noccurred when private customer and device data intended for Synology was\ndelivered to an unauthorised third party.\n\n## Affected traffic paths\n\nThe intercepted requests were intended for hostnames including:\n\n* `relayinfo.synology.com`\n* `global.quickconnect.to`\n* `dec.quickconnect.to`\n* `ukc.synology.com`\n\nThe traffic included requests to:\n\n* `/finder/set.php`\n* `/Serv.php`\n* `/alias_update.php`\n\nCisco Talos previously documented the same `synoagentregisterd` sequence. A\nDSM device first requested a finder server from `global.quickconnect.to`,\nthen transmitted its serial number, token, network addresses and DSM ports\nusing plaintext HTTP. Talos concluded that both stages could be modified by\na man-in-the-middle attacker.\n\nTalos also documented QuickConnect server impersonation capable of stealing\ndevice credentials through the `synorelayd` and HTTP-redirection flow.\n\nThe stale-DNS condition supplies the attacker-controlled endpoint required\nby these vulnerabilities without requiring the attacker to compromise DNS\nor obtain an existing network position.\n\n## Captured client versions\n\nAll captured clients pre-date DSM 6.2.3-25426 Update 3.\n\n| Captured version | Identified models | Distinct endpoints |\n| ------------------------ | ----------------------- | -----------------: |\n| Synology Relayd 1.0-3211 | Model not disclosed | 1 |\n| Synology Relayd 1.0-3810 | Model not disclosed | 1 |\n| Synology Relayd 1.0-3827 | DS210j, DS212j, DS710+ | 4 |\n| Synology Relayd 1.0-4493 | DS214+, DS414slim | 5 |\n| DSM 5.0-4528 | DS214play | 1 |\n| DSM 5.0-4528 Update 1 | DS713+ | 1 |\n| DSM 5.0-4528 Update 2 | DS213j | 1 |\n| DSM 5.2-5592 Update 4 | DS214se | 1 |\n| DSM 5.2-5967 Update 9 | DS1010+, DS115j, RS815+ | 4 |\n| DSM 6.0-8451 | DS416j | 1 |\n| DSM 6.0-8754 Update 8 | DS215+, DS216j | 3 |\n| Total | | 23 |\n\n## Required remediation\n\n### Devices that support the patched DSM release\n\nThe following identified models can install DSM 6.2.3-25426 Update 3 or a\nlater DSM release:\n\n* DS212j\n* DS213j\n* DS214+\n* DS214play\n* DS214se\n* DS215+\n* DS216j\n* DS414slim\n* DS416j\n* DS713+\n* DS115j\n* RS815+\n\nOwners should install the latest DSM version currently offered for the\nspecific model. DSM 6.2.3-25426 Update 3 is only the minimum version known\nto contain the relevant fixes and should not be treated as the preferred\ncurrent version. Synology\u0027s model release notes confirm availability of the\nfixed branch for these hardware generations.\n\n### Devices with no patched DSM release\n\nThe following captured 10-series models are limited to DSM 5.2 and cannot\ninstall the fixed DSM branch:\n\n* DS1010+\n* DS210j\n* DS710+\n\nSynology states that DSM 5.2 was the final major DSM release for 10-series\ndevices.\n\nThere is therefore no safe software upgrade for these devices in relation\nto the vulnerabilities described in Synology-SA-20:26. Customers should\nreplace or retire them.\n\nUntil replacement, owners should disable QuickConnect and related relay\nfunctionality, restrict outbound connectivity to Synology relay and finder\nservices, and prevent the devices from transmitting sensitive registration\ndata over the internet.\n\nThe two unidentified clients using Relayd 1.0-3211 and 1.0-3810 should be\nidentified by their owners. If their hardware cannot install DSM\n6.2.3-25426 Update 3 or later, the same replacement recommendation applies.\n\n## Historical exposure\n\nIt is not known:\n\n* How long Synology\u0027s infrastructure has released ephemeral addresses while\nDNS caches remained valid.\n* How frequently previously used addresses have been acquired by unrelated\ncloud customers.\n* Whether other parties deliberately searched for and acquired released\nSynology addresses.\n* How many clients have previously sent requests to unintended recipients.\n* How much customer data may have been collected before this report.\n* Whether any exposed keys, tokens or session values were replayed or\notherwise abused.\n\nFour independent ephemeral addresses were encountered during a short\nobservation period. This suggests that the condition was repeatable rather\nthan an isolated cloud-allocation anomaly.\n\nThe absence of known reports of exploitation cannot establish that prior\ninterception did not occur. A party receiving this traffic would not need\nto interact with the affected NAS, modify a request, or trigger an\nobservable failure. Passive collection could occur without the customer or\nSynology becoming aware of it.\n\n## Vendor disclosure timeline\n\n| Date | Event\n\n |\n| ----------------- |\n----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n|\n| 7 July 2026 | Initial report submitted to Synology with a captured\ntraffic log.\n |\n| 8 July 2026 | Synology classified the issue as a hardening\nsuggestion, stating that a complete exploit had not been demonstrated and\nreferring to phishing or fake-site behaviour that was not part of the\nreport. |\n| 8 July 2026 | Synology was informed that the attachment contained\nlive third-party traffic, identifiers and token values, and was asked to\nconsider notifying the affected customers. |\n| 9 July 2026 | Synology acknowledged that the log contained live\ntraffic and token-like values, but said replay or account compromise had\nnot been demonstrated. |\n| 9 July 2026 | Synology was informed that its HTTPS traffic had\nconnected to a self-signed collection endpoint, demonstrating ineffective\ncertificate validation. |\n| 9 July 2026 | Synology described the result as, at most, limited\ninformation exposure.\n |\n| 9 to 16 July 2026 | Additional released IP addresses were acquired and\nfurther independent batches of customer traffic were captured and supplied.\n |\n| 22 July 2026 | Synology stated that the TLS certificate-validation\nbehaviour had been fixed in later DSM versions and maintained that the\nreport was not bounty eligible. |\n| 22 July 2026 | Synology was reminded that the stale-DNS condition\nmade the old client vulnerability practically exploitable and that the\nduration and historical extent of exposure were unknown. |\n| 22 July 2026 | Synology stated that it would adjust the\nconfiguration of `relayinfo.synology.com` to further reduce the risk.\n\n |\n| 22 July 2026 | Synology maintained the \"hardening suggestion\"\nclassification and declined a monetary reward.\n |\n\n\n## Assessment of Synology\u0027s response\n\nSynology is correct that every client observed in the captures was old and\npre-dated the relevant security update.\n\nThat fact does not invalidate the finding.\n\nThe stale-DNS condition was present in Synology-controlled infrastructure\nat the time of reporting. It t"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T11:36:42Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/28"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Jul/28"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Jul/28"
],
"discovery": "EXTERNAL"
},
"title": "Synology stale DNS allows practical interception of traffic from vulnerable DSM clients",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0157",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/28",
"automated": true,
"contentSha256": "bd8f367c2ed2bbbcd5c32d5122025267d13ee7dbffbbbc16a203899c4f1f006e",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/28",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-07-22T08:27:45Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:22Z",
"dateUpdated": "2026-09-11T11:36:42Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0157"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…