CVE-2026-53521

## Summary `PATCH /server/{id}` accepts and persists nonexistent `ddns_profiles` IDs for a member-owned server. If another user later creates a DDNS profile with one of those IDs, the DDNS worker resolves the stored ID and dispatches an update using the other user's DDNS profile configuration in the context of the attacker's server. This is a second-order authorization bypass: direct binding to an existing foreign DDNS profile is correctly denied, but an unresolved future ID can be stored first and later becomes a live cross-user reference. ## Affected versions Confirmed on: - Nezha `v2.0.14` - Commit: `8b5e382fe217107c7b777ea9c6b4bc3d2e156202` The exact affected version range was not determined. ## Impact A normal member who owns a server can prebind one or more future DDNS profile IDs to that server. If another user later creates a DDNS profile with a matching ID, the dashboard DDNS worker can use the victim's DDNS profile/provider configuration for the attacker's server. In the validated worker path, the dispatched DDNS update combines: - the victim DDNS profile ID and owner - the victim profile's provider type - victim profile fields such as domains, access ID, access secret, and retry policy - attacker server context, including the attacker's server ID, owner, IPv4 address, and override DDNS domains This can result in unauthorized DDNS update attempts using another user's DDNS profile context. The attacker does not need permission to bind the victim profile after it exists. The following were not validated: credential disclosure, account takeover, or guaranteed external DNS modification across all providers. The credentials remain server-side in the worker path. The downstream DNS impact depends on the victim profile's provider configuration and what that provider account is authorized to update. ## Affected components - `PATCH /server/{id}` - `cmd/dashboard/controller/server.go` - `service/singleton/singleton.go` - `service/singleton/ddns.go` - `