CVE-2026-59155

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M 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.

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M 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.

Summary

The 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.

Details

The 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.

DDNS — cmd/dashboard/controller/ddns.go:25–33:

func listDDNS(c *gin.Context) ([]*model.DDNSProfile, error) {
    var ddnsProfiles []*model.DDNSProfile
    list := singleton.DDNSShared.GetSortedList()
    if err := copier.Copy(&ddnsProfiles, &list); err != nil {
        return nil, err
    }
    return ddnsProfiles, nil
}

The 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.

Notification — cmd/dashboard/controller/notification.go:25–33:

func listNotification(c *gin.Context) ([]*model.Notification, error) {
    slist := singleton.NotificationShared.GetSortedList()
    var notifications []*model.Notification
    if err := copier.Copy(&notifications, &slist); err != nil {
        return nil, err
    }
    return notifications, nil
}

The 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.

Route and authorization (cmd/dashboard/controller/controller.go:155, 171):

auth.GET("/notification", restScopeMiddleware(model.ScopeNotificationRead), listHandler(listNotification))
auth.GET("/ddns", restScopeMiddleware(model.ScopeDDNSRead), listHandler(listDDNS))

Both 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.

The 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.

Tested at commit 3d74cd94 (master, post v2.2.3). The vulnerable pattern has existed since the DDNS and notification list endpoints were introduced.

PoC

1. 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...).

2. Authenticate as the admin user. Call:

   # DDNS credentials exposed
   curl -s -H "Authorization: Bearer <admin_jwt>" \
     https://dashboard.example.com/api/v1/ddns \
     | jq '.data[].access_secret'
   
   # Notification webhook secrets exposed
   curl -s -H "Authorization: Bearer <admin_jwt>" \…
   

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M 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.

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M 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.

Summary

The 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.

Details

The 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.

DDNS — cmd/dashboard/controller/ddns.go:25–33:

func listDDNS(c *gin.Context) ([]*model.DDNSProfile, error) {
    var ddnsProfiles []*model.DDNSProfile
    list := singleton.DDNSShared.GetSortedList()
    if err := copier.Copy(&ddnsProfiles, &list); err != nil {
        return nil, err
    }
    return ddnsProfiles, nil
}

The 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.

Notification — cmd/dashboard/controller/notification.go:25–33:

func listNotification(c *gin.Context) ([]*model.Notification, error) {
    slist := singleton.NotificationShared.GetSortedList()
    var notifications []*model.Notification
    if err := copier.Copy(&notifications, &slist); err != nil {
        return nil, err
    }
    return notifications, nil
}

The 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.

Route and authorization (cmd/dashboard/controller/controller.go:155, 171):

auth.GET("/notification", restScopeMiddleware(model.ScopeNotificationRead), listHandler(listNotification))
auth.GET("/ddns", restScopeMiddleware(model.ScopeDDNSRead), listHandler(listDDNS))

Both 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.

The 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.

Tested at commit 3d74cd94 (master, post v2.2.3). The vulnerable pattern has existed since the DDNS and notification list endpoints were introduced.

PoC

1. 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...).

2. Authenticate as the admin user. Call:

   # DDNS credentials exposed
   curl -s -H "Authorization: Bearer <admin_jwt>" \
     https://dashboard.example.com/api/v1/ddns \
     | jq '.data[].access_secret'
   
   # Notification webhook secrets exposed
   curl -s -H "Authorization: Bearer <admin_jwt>" \…
   

Nezha Dashboard: DDNS and Notification credential exposure via unredacted list API in github.com/nezhahq/nezha.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The additional affected modules and versions are: github.com/nezhahq/nezha before v2.2.5.