Nezha EUVD-2026-102568

Requires an authenticated Nezha principal - either an admin account or a Personal Access Token holding the nezha:ddns:read scope - able to call GET /api/v1/ddns; no user interaction is needed. Exploitation additionally requires that DDNS webhook profiles actually contain secrets embedded in the WebhookURL (e.g. ?token=...) or WebhookRequestBody fields, since those are the only fields left unredacted. The primary limiting factor is the authentication and scope prerequisite (PR:L), which confines risk to users/tokens already granted DDNS read access; impact is greatest in multi-tenant deployments where a low-privilege user can thereby read all other users' credentials. No special non-default configuration or platform is required beyond having webhook-based DDNS profiles configured.

The vendor-assigned CVSS 4.0 score is 7.1 (High), driven by VC:H (high confidentiality impact from cleartext third-party credential exposure) with no integrity or availability impact. Critically, the vector is AV:N/AC:L/PR:L/UI:N - PR:L means exploitation requires an authenticated account or a Personal Access Token, so this is NOT remotely exploitable by an anonymous attacker despite the 'network' vector. The equivalent CVSS 3.1 base score is approximately 6.5 (Medium). Exploitation status is 'no public exploit identified at time of analysis' - no POC, EPSS, or KEV data was supplied, so there is no evidence of active exploitation or widespread automated attack probability. The real-world significance is a privilege/tenant boundary violation: in multi-tenant Nezha deployments, any user (or PAT) holding the nezha:ddns:read scope can read EVERY user's DDNS webhook secrets, not just their own, making this a meaningful lateral-credential-harvesting issue rather than a high-CVSS-but-low-real-risk theoretical flaw. The signals are internally consistent (authenticated information disclosure); the main limiting factor is the authentication prerequisite. EPSS and KEV data are absent and should be independently checked before final prioritization.

An authenticated low-privilege Nezha user, or an attacker who has compromised a Personal Access Token carrying the nezha:ddns:read scope, issues a GET request to /api/v1/ddns. The response returns every user's DDNS webhook profiles with WebhookURL and WebhookRequestBody unredacted, exposing cleartext API tokens embedded in those fields; the attacker then reuses those third-party credentials against the external DNS/webhook services. No public exploit is identified, but the single-request nature makes exploitation trivial for any holder of the required scope.