{"id":"CVE-2026-59155","aliases":["EUVD-2026-43108","GHSA-ww5p-j6cj-6mqq","GO-2026-5832"],"status":"published","title":"Nezha Monitoring: DDNS and Notification credential exposure via unredacted list API","description":"Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O\u0026M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.","severity":{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00385,"percentile":0.32897,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-200"],"published":"2026-06-26T23:55:26Z","modified":"2026-10-28T02:30:40Z","fixes":[{"ecosystem":"Go","package":"github.com/nezhahq/nezha","fixed_in":["2.2.5"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/nezhahq/nezha","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.2.5"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/nezhahq/nezha","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.2.5"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/nezhahq/nezha","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]}],"products":[{"vendor":"nezhahq","product":"nezha"}],"references":[{"url":"https://github.com/nezhahq/nezha/security/advisories/GHSA-ww5p-j6cj-6mqq","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/nezhahq/nezha/commit/39d398066d8c644fe452f74704e34ada6c7ab61e","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/nezhahq/nezha/releases/tag/v2.2.5","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-ww5p-j6cj-6mqq"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/59xxx/CVE-2026-59155.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59155","tags":["advisory"]},{"url":"https://github.com/nezhahq/nezha","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-59155","title":"Nezha Monitoring: DDNS and Notification credential exposure via unredacted list API","description":"Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O\u0026M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.","status":"published","published":"2026-07-10T21:31:34.313Z","modified":"2026-07-13T17:56:44.683Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T14:19:58.944663Z"}],"euvd":[{"id":"EUVD-2026-43108","description":"Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O\u0026M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.","status":"published","published":"2026-07-10T21:31:34Z","modified":"2026-07-13T17:56:44Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:20:01.134466Z"}],"ghsa":[{"id":"GHSA-ww5p-j6cj-6mqq","title":"Nezha Dashboard: DDNS and Notification credential exposure via unredacted list API","description":"### Summary\n\nThe `GET /api/v1/ddns` and `GET /api/v1/notification` endpoints return full resource objects including plaintext third-party API credentials — Cloudflare API tokens, TencentCloud SecretKeys, Slack/Discord/Telegram webhook URLs with embedded bot tokens, and Authorization header values — without any field-level redaction. Any authenticated admin who calls these endpoints receives every stored credential in the system in a single API response. A compromised admin session or leaked PAT with `nezha:ddns:read` or `nezha:notification:read` scope exposes all third-party integration secrets.\n\n### Details\n\nThe `listDDNS` and `listNotification` handlers follow an identical pattern: they call the corresponding singleton `GetSortedList()`, `copier.Copy` the full in-memory structs into a response slice, and return them via `listHandler` with zero field stripping.\n\n**DDNS — `cmd/dashboard/controller/ddns.go:25–33`:**\n\n```go\nfunc listDDNS(c *gin.Context) ([]*model.DDNSProfile, error) {\n    var ddnsProfiles []*model.DDNSProfile\n    list := singleton.DDNSShared.GetSortedList()\n    if err := copier.Copy(\u0026ddnsProfiles, \u0026list); err != nil {\n        return nil, err\n    }\n    return ddnsProfiles, nil\n}\n```\n\nThe `DDNSProfile` struct (`model/ddns.go:20–36`) serializes `AccessSecret` with `json:\"access_secret,omitempty\"` — non-empty Cloudflare tokens and TencentCloud SecretKeys are returned in cleartext. The `WebhookURL` and `WebhookHeaders` fields may also contain embedded secrets.\n\n**Notification — `cmd/dashboard/controller/notification.go:25–33`:**\n\n```go\nfunc listNotification(c *gin.Context) ([]*model.Notification, error) {\n    slist := singleton.NotificationShared.GetSortedList()\n    var notifications []*model.Notification\n    if err := copier.Copy(\u0026notifications, \u0026slist); err != nil {\n        return nil, err\n    }\n    return notifications, nil\n}\n```\n\nThe `Notification` struct (`model/notification.go:34–44`) serializes `URL`, `RequestHeader`, and `RequestBody` — all of which commonly contain embedded bot tokens (Slack, Discord, Telegram), API keys in Authorization headers, and webhook secrets.\n\n**Route and authorization (`cmd/dashboard/controller/controller.go:155, 171`):**\n\n```go\nauth.GET(\"/notification\", restScopeMiddleware(model.ScopeNotificationRead), listHandler(listNotification))\nauth.GET(\"/ddns\", restScopeMiddleware(model.ScopeDDNSRead), listHandler(listDDNS))\n```\n\nBoth routes are behind `authMw` (JWT or PAT) and the corresponding read scope. The `listHandler` → `filter` chain uses `HasPermission` (`model/common.go:63–82`) which grants admins access to ALL profiles and restricts members to their own. No separate response struct or field masking exists anywhere in the codebase — confirmed by exhaustive search for `DDNSResponse`, `DDNSView`, `NotificationResponse`, `NotificationView`, or any JSON middleware that strips sensitive fields.\n\nThe codebase already demonstrates awareness of this pattern: `serverConfigSensitiveScope()` in `cmd/dashboard/controller/api_token_scope.go:117` was introduced to restrict `client_secret` exposure via `GET /server/config/:id`, tightening the scope from `ScopeServerRead` to `ScopeServerWrite`. No equivalent protection exists for the DDNS or Notification list endpoints.\n\n**Tested at commit `3d74cd94` (master, post v2.2.3).** The vulnerable pattern has existed since the DDNS and notification list endpoints were introduced.\n\n### PoC\n\n1. Deploy nezha with at least one admin user. Configure a DDNS profile with a Cloudflare API token (AccessSecret) and a Notification webhook pointing to a Slack incoming webhook URL (`https://hooks.slack.com/services/T.../B.../xxx...`).\n\n2. Authenticate as the admin user. Call:\n\n   ```bash\n   # DDNS credentials exposed\n   curl -s -H \"Authorization: Bearer \u003cadmin_jwt\u003e\" \\\n     https://dashboard.example.com/api/v1/ddns \\\n     | jq '.data[].access_secret'\n\n   # Notification webhook secrets exposed\n   curl -s -H \"Authorization: Bearer \u003cadmin_jwt\u003e\" \\\n     https://dashboard.example.com/api/v1/notification \\\n     | jq '.data[].url'\n   ```\n\n3. Observe the full Cloudflare API token, Slack webhook URL with embedded token, and any `RequestHeader` values (e.g., `Authorization: Bearer ...`) returned in cleartext.\n\n4. Alternatively, create a PAT with `nezha:ddns:read` scope:\n\n   ```bash\n   curl -s -H \"Authorization: Bearer nzp_\u003cpat_secret\u003e\" \\\n     https://dashboard.example.com/api/v1/ddns \\\n     | jq '.data[].access_secret'\n   ```\n\n   If the PAT creator is an admin, all DDNS secrets are returned in a single response.\n\n5. **Negative control:** A member (non-admin) calling the same endpoints only sees their own profiles due to the `HasPermission` filter (`model/common.go:63–82`). However, an admin sees ALL profiles with ALL secrets. The security boundary crossed is the credential confidentiality boundary — a read-only listing endpoint should not return write-capable credentials.\n\n### Impact\n\nAn attacker who compromises an admin session or obtains a PAT with the appropriate read scope can exfiltrate all third-party API credentials stored in the dashboard — Cloudflare API tokens, TencentCloud SecretKeys, Slack/Discord/Telegram bot tokens, and any secrets embedded in webhook URLs or Authorization headers. These credentials can then be used to:\n\n- Modify DNS records for any domain managed via Cloudflare/TencentCloud DDNS profiles\n- Send messages as the Slack/Discord/Telegram bot to any configured channel\n- Access any other API the compromised credentials grant access to\n\nThe attack requires high privileges (admin JWT or PAT with appropriate scope), but the impact is amplified because a single API call exposes ALL stored credentials across ALL DDNS profiles and ALL notification webhooks, with no field-level access control separating metadata from secrets.\n\n**Suggested remediation:** Introduce separate response structs (e.g., `DDNSProfileResponse`, `NotificationResponse`) that omit sensitive fields (`AccessSecret`, `WebhookHeaders`, `URL`, `RequestHeader`) from list/read endpoints, or use `json:\"-\"` tags on sensitive fields and provide them only through a dedicated credential-retrieval endpoint with stricter authorization (analogous to the existing `serverConfigSensitiveScope()` pattern).","status":"published","published":"2026-06-26T23:55:26Z","modified":"2026-06-26T23:55:28Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T14:40:34.713036Z"}],"nvd":[{"id":"CVE-2026-59155","description":"Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O\u0026M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.","status":"published","published":"2026-07-10T22:16:45.487Z","modified":"2026-10-25T15:10:00.147Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T14:12:28.771746Z"}],"osv":[{"id":"CVE-2026-59155","title":"Nezha Monitoring: DDNS and Notification credential exposure via unredacted list API","description":"Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O\u0026M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.","status":"published","published":"2026-07-10T21:31:34.313Z","modified":"2026-10-28T02:30:40.54013744Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T15:45:12.496548Z"},{"id":"GHSA-ww5p-j6cj-6mqq","title":"Nezha Dashboard: DDNS and Notification credential exposure via unredacted list API","description":"### Summary\n\nThe `GET /api/v1/ddns` and `GET /api/v1/notification` endpoints return full resource objects including plaintext third-party API credentials — Cloudflare API tokens, TencentCloud SecretKeys, Slack/Discord/Telegram webhook URLs with embedded bot tokens, and Authorization header values — without any field-level redaction. Any authenticated admin who calls these endpoints receives every stored credential in the system in a single API response. A compromised admin session or leaked PAT with `nezha:ddns:read` or `nezha:notification:read` scope exposes all third-party integration secrets.\n\n### Details\n\nThe `listDDNS` and `listNotification` handlers follow an identical pattern: they call the corresponding singleton `GetSortedList()`, `copier.Copy` the full in-memory structs into a response slice, and return them via `listHandler` with zero field stripping.\n\n**DDNS — `cmd/dashboard/controller/ddns.go:25–33`:**\n\n```go\nfunc listDDNS(c *gin.Context) ([]*model.DDNSProfile, error) {\n    var ddnsProfiles []*model.DDNSProfile\n    list := singleton.DDNSShared.GetSortedList()\n    if err := copier.Copy(\u0026ddnsProfiles, \u0026list); err != nil {\n        return nil, err\n    }\n    return ddnsProfiles, nil\n}\n```\n\nThe `DDNSProfile` struct (`model/ddns.go:20–36`) serializes `AccessSecret` with `json:\"access_secret,omitempty\"` — non-empty Cloudflare tokens and TencentCloud SecretKeys are returned in cleartext. The `WebhookURL` and `WebhookHeaders` fields may also contain embedded secrets.\n\n**Notification — `cmd/dashboard/controller/notification.go:25–33`:**\n\n```go\nfunc listNotification(c *gin.Context) ([]*model.Notification, error) {\n    slist := singleton.NotificationShared.GetSortedList()\n    var notifications []*model.Notification\n    if err := copier.Copy(\u0026notifications, \u0026slist); err != nil {\n        return nil, err\n    }\n    return notifications, nil\n}\n```\n\nThe `Notification` struct (`model/notification.go:34–44`) serializes `URL`, `RequestHeader`, and `RequestBody` — all of which commonly contain embedded bot tokens (Slack, Discord, Telegram), API keys in Authorization headers, and webhook secrets.\n\n**Route and authorization (`cmd/dashboard/controller/controller.go:155, 171`):**\n\n```go\nauth.GET(\"/notification\", restScopeMiddleware(model.ScopeNotificationRead), listHandler(listNotification))\nauth.GET(\"/ddns\", restScopeMiddleware(model.ScopeDDNSRead), listHandler(listDDNS))\n```\n\nBoth routes are behind `authMw` (JWT or PAT) and the corresponding read scope. The `listHandler` → `filter` chain uses `HasPermission` (`model/common.go:63–82`) which grants admins access to ALL profiles and restricts members to their own. No separate response struct or field masking exists anywhere in the codebase — confirmed by exhaustive search for `DDNSResponse`, `DDNSView`, `NotificationResponse`, `NotificationView`, or any JSON middleware that strips sensitive fields.\n\nThe codebase already demonstrates awareness of this pattern: `serverConfigSensitiveScope()` in `cmd/dashboard/controller/api_token_scope.go:117` was introduced to restrict `client_secret` exposure via `GET /server/config/:id`, tightening the scope from `ScopeServerRead` to `ScopeServerWrite`. No equivalent protection exists for the DDNS or Notification list endpoints.\n\n**Tested at commit `3d74cd94` (master, post v2.2.3).** The vulnerable pattern has existed since the DDNS and notification list endpoints were introduced.\n\n### PoC\n\n1. Deploy nezha with at least one admin user. Configure a DDNS profile with a Cloudflare API token (AccessSecret) and a Notification webhook pointing to a Slack incoming webhook URL (`https://hooks.slack.com/services/T.../B.../xxx...`).\n\n2. Authenticate as the admin user. Call:\n\n   ```bash\n   # DDNS credentials exposed\n   curl -s -H \"Authorization: Bearer \u003cadmin_jwt\u003e\" \\\n     https://dashboard.example.com/api/v1/ddns \\\n     | jq '.data[].access_secret'\n\n   # Notification webhook secrets exposed\n   curl -s -H \"Authorization: Bearer \u003cadmin_jwt\u003e\" \\\n     https://dashboard.example.com/api/v1/notification \\\n     | jq '.data[].url'\n   ```\n\n3. Observe the full Cloudflare API token, Slack webhook URL with embedded token, and any `RequestHeader` values (e.g., `Authorization: Bearer ...`) returned in cleartext.\n\n4. Alternatively, create a PAT with `nezha:ddns:read` scope:\n\n   ```bash\n   curl -s -H \"Authorization: Bearer nzp_\u003cpat_secret\u003e\" \\\n     https://dashboard.example.com/api/v1/ddns \\\n     | jq '.data[].access_secret'\n   ```\n\n   If the PAT creator is an admin, all DDNS secrets are returned in a single response.\n\n5. **Negative control:** A member (non-admin) calling the same endpoints only sees their own profiles due to the `HasPermission` filter (`model/common.go:63–82`). However, an admin sees ALL profiles with ALL secrets. The security boundary crossed is the credential confidentiality boundary — a read-only listing endpoint should not return write-capable credentials.\n\n### Impact\n\nAn attacker who compromises an admin session or obtains a PAT with the appropriate read scope can exfiltrate all third-party API credentials stored in the dashboard — Cloudflare API tokens, TencentCloud SecretKeys, Slack/Discord/Telegram bot tokens, and any secrets embedded in webhook URLs or Authorization headers. These credentials can then be used to:\n\n- Modify DNS records for any domain managed via Cloudflare/TencentCloud DDNS profiles\n- Send messages as the Slack/Discord/Telegram bot to any configured channel\n- Access any other API the compromised credentials grant access to\n\nThe attack requires high privileges (admin JWT or PAT with appropriate scope), but the impact is amplified because a single API call exposes ALL stored credentials across ALL DDNS profiles and ALL notification webhooks, with no field-level access control separating metadata from secrets.\n\n**Suggested remediation:** Introduce separate response structs (e.g., `DDNSProfileResponse`, `NotificationResponse`) that omit sensitive fields (`AccessSecret`, `WebhookHeaders`, `URL`, `RequestHeader`) from list/read endpoints, or use `json:\"-\"` tags on sensitive fields and provide them only through a dedicated credential-retrieval endpoint with stricter authorization (analogous to the existing `serverConfigSensitiveScope()` pattern).","status":"published","published":"2026-06-26T23:55:26Z","modified":"2026-07-12T04:11:12.353970407Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-200"],"updated_at":"2026-11-02T15:46:59.131095Z"},{"id":"GO-2026-5832","title":"Nezha Dashboard: DDNS and Notification credential exposure via unredacted list API in github.com/nezhahq/nezha","description":"Nezha Dashboard: DDNS and Notification credential exposure via unredacted list API in github.com/nezhahq/nezha.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: github.com/nezhahq/nezha before v2.2.5.","status":"published","published":"2026-07-07T15:26:32Z","modified":"2026-07-12T04:11:12.353970407Z","updated_at":"2026-11-02T15:47:02.838915Z"}]}}