GHSA-WW5P-J6CJ-6MQQ: Credential Exposure in Nezha Dashboard DDNS and Notification APIs

Nezha Dashboard is an open-source server monitoring and administration panel written in Go. The dashboard allows administrators to manage servers, monitor system resource metrics, configure Dynamic DNS (DDNS) providers, and set up notification channels (such as Slack, Telegram, or Discord webhooks) for alert thresholds.

The attack surface exists within the authenticated REST API endpoints exposed by the dashboard controller layer. Specifically, the endpoints GET /api/v1/ddns and GET /api/v1/notification are queryable by authenticated administrators or users with scoped Personal Access Tokens (PATs). This implementation introduces a significant vulnerability categorized under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

The vulnerability stems from a design pattern where database-level model representations of DDNS profiles and Notification configurations are copied and returned directly to the client interface. Because these models contain plaintext authentication material—such as Cloudflare API tokens, TencentCloud SecretKeys, and Slack webhook URLs containing embedded tokens—the API response exposes these credentials to anyone with read access to these panels.

The core of the vulnerability resides in how Nezha Dashboard manages and serializes data structures inside the cmd/dashboard/controller and model packages. In Go, structures representing database tables or configuration states often contain sensitive fields alongside general metadata. When serializing these structures to JSON via web frameworks like Gin, any field not explicitly ignored, redacted, or marked as private is included in the raw HTTP response.

To prevent concurrent mutation bugs on the global in-memory state, the handlers listDDNS and listNotification deep-copy the configurations using the github.com/jinzhu/copier library. However, the target structures (model.DDNSProfile and model.Notification) retain their sensitive string fields during this cloning process. In versions of Nezha Dashboard prior to 2.2.5, no subsequent cleanup operations were performed on these copied instances before returning them to the controller's serializer.

As a consequence, the JSON output contains write-capable credentials in cleartext. For DDNS configurations, the AccessSecret and WebhookHeaders fields are left fully populated. For notifications, fields like URL (often containing Telegram bot tokens or Slack webhook keys), RequestHeader (frequently holding Authorization: Bearer strings), and RequestBody are left unredacted. This implementation breaks the security principle of least privilege, as read-only endpoints should never expose the high-privilege credentials required to authenticate or write to external systems.

Analyzing the code from the affected versions exposes the direct pathway of the credential leak. In cmd/dashboard/controller/ddns.go, the vulnerable listing function copy-serializes the data without filter loops:

// Vulnerable function in cmd/dashboard/controller/ddns.go
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 corresponding patch implemented in commit 39d398066d8c644fe452f74704e34ada6c7ab61e introduces explicit field zeroing on the copied records. Because ddnsProfiles is a fresh copy returned by copier.Copy, setting individual attributes to an empty string does not affect the master state stored in the singleton package.

// Patched function in cmd/dashboard/controller/ddns.go
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
    }
 
    // Redact write-capable credentials prior to serialization
    for _, p := range ddnsProfiles {
        p.AccessSecret = ""
        p.WebhookHeaders = ""
    }
 
    return ddnsProfiles, nil
}

Additionally, the patch must accommodate the standard frontend lifecycle. Typically, web panels retrieve data via a GET request, allow the user to modify parameters, and send the state back via POST or PUT. If the frontend receives blank values for secrets, it sends them back empty. The update handler was therefore updated to ignore empty credentials instead of overwriting existing ones with blank strings:

// Patched update check in cmd/dashboard/controller/ddns.go
if df.AccessSecret != "" {
    p.AccessSecret = df.AccessSecret
}
if df.WebhookHeaders != "" {
    p.WebhookHeaders = df.WebhookHeaders
}

Exploitation of GHSA-WW5P-J6CJ-6MQQ does not require complex memory manipulation or binary payloads. The attack vector is low-complexity and requires network access to the Nezha Dashboard API alongside valid credentials. The primary threat comes from users holding low-privilege or read-only administrative credentials, or from attackers who exfiltrate active admin sessions or scoped Personal Access Tokens (PATs).

If an attacker compromises an account with read access to DDNS or notification resources (such as tokens with scopes nezha:ddns:read or nezha:notification:read), they can make direct REST queries to the vulnerable endpoints. The server responds with the raw configuration containing the third-party tokens in cleartext.

An administrative session can be used to query the endpoints using tools like curl and parse the output using jq. An example query targeting the notification endpoint illustrates the risk:

curl -s -H "Authorization: Bearer <token>" \
  https://dashboard.example.com/api/v1/notification \
  | jq '.data[] | {name: .name, url: .url, request_header: .request_header}'

The resulting response payload exposes the full webhook URI, including Slack or Discord bot secrets, and any custom HTTP request headers containing third-party bearer tokens:

{
  "name": "Slack Alert Channel",
  "url": "https://hooks.slack.com/services/T012345/B012345/secret_token_value_here",
  "request_header": "{\"Authorization\":\"Bearer external_service_api_token_value\"}"
}

Using this exfiltrated information, the attacker can move laterally to other services, modifying DNS records at external providers (e.g., Cloudflare) or accessing restricted internal webhooks.

The vulnerability's direct impact is rated as Medium (CVSS v4: 5.5) because high administrative privileges are required to reach the endpoints. However, the subsequent system confidentiality impact is high. The credentials stored in Nezha Dashboard frequently govern the integrity and availability of larger cloud architectures.

For example, exposing Cloudflare API tokens allows adversaries to edit, add, or delete DNS records for any domain managed under that token. This exposure enables domain hijacking, sub-domain takeovers, and the creation of malicious records to facilitate phishing campaigns. Because Nezha Dashboard is used to monitor infrastructure, exposing these keys allows an attacker to manipulate the very infrastructure under observation.

Furthermore, the exposure of Slack or Telegram bot tokens allows unauthorized message interception and spoofing. Attackers can leverage control of official notification bots to push social engineering payloads or fake alerts to team channels. Finally, leaking HTTP Authorization headers can grant immediate access to internal corporate web APIs, violating security segmentation boundaries.

To completely resolve the vulnerability, Nezha Dashboard must be upgraded to version 2.2.5 or later. This version contains the necessary controller-level redaction filters and prevents accidental deletion of secrets during configuration updates.

If patching cannot be executed immediately, administrators should implement strict access control policies on the reverse proxy level. Restricting the /api/v1/ddns and /api/v1/notification endpoints to trusted source IP addresses or requiring VPN access lowers the overall exposure. Additionally, administrators must review and audit all active Personal Access Tokens (PATs) and delete any tokens with read scopes that are no longer required.

Following a patch or upgrade, a thorough credential rotation process must be executed. Because historical logs might not indicate whether sensitive API endpoints were accessed for exfiltration, any API key, OAuth token, webhook URL, or Secret Key previously stored in the dashboard should be considered compromised and rotated immediately.