CVE-2026-53521: Nezha Monitoring Auth Bypass Vulnerability

CVE-2026-53521 Overview

CVE-2026-53521 is an authorization flaw [CWE-863] in Nezha Monitoring, a self-hostable server and website monitoring tool. The vulnerability affects versions 2.0.14 through versions prior to 2.1.0. The PATCH /server/{id} endpoint accepts and persists nonexistent ddns_profiles IDs on a member-owned server. When another user later creates a Dynamic DNS (DDNS) profile that matches one of those stored IDs, the DDNS worker resolves the reference and dispatches updates using the victim's profile configuration in the attacker's server context. The maintainers patched the issue in version 2.1.0.

Critical Impact
An authenticated low-privileged user can stage stale DDNS profile IDs to later hijack another user's DDNS configuration, causing cross-tenant DNS updates under the attacker's server context.

Affected Products

Nezha Monitoring version 2.0.14
Nezha Monitoring versions after 2.0.14 and before 2.1.0
Self-hosted multi-user deployments of Nezha Monitoring

Discovery Timeline

2026-06-12 - CVE-2026-53521 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-53521

Vulnerability Analysis

The flaw resides in the server update handler exposed at PATCH /server/{id}. The endpoint accepts a ddns_profiles array containing profile identifiers but does not validate that the supplied IDs exist or belong to the requesting user. Nezha persists these dangling references on the attacker-owned server record.

When another tenant later creates a DDNS profile, the database assigns it an ID. If the new ID matches one previously persisted on the attacker's server, the DDNS worker treats the reference as valid. The worker then executes DNS updates using the victim's DDNS credentials and target configuration, but driven by the attacker's monitored server state. This produces a cross-tenant action that the victim never authorized.

Root Cause

The root cause is missing authorization and existence validation on a foreign-key style relationship [CWE-863]. The server update code trusts client-supplied profile IDs without verifying ownership or current existence. Storage of unresolvable IDs creates a time-of-stage to time-of-resolve gap that materializes into a privilege boundary violation once a matching ID is later created by any user.

Attack Vector

An authenticated member-level account submits a PATCH /server/{id} request against a server it owns, supplying arbitrary integer IDs in the ddns_profiles field. The attacker selects IDs likely to be assigned next by the application's sequence. When a separate user creates a DDNS profile and is assigned one of those IDs, the background DDNS worker resolves the stored reference. The worker dispatches DNS updates using the victim's profile configuration, executed in the context of the attacker's server. The attack requires network access to the API and a valid low-privileged account.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-39g2-8x68-pmx8 for maintainer-provided technical detail.

Detection Methods for CVE-2026-53521

Indicators of Compromise

PATCH /server/{id} requests from non-administrative accounts that include ddns_profiles arrays referencing IDs not yet present in the ddns_profiles table.
DDNS worker log entries showing profile resolution where the resolved profile owner differs from the owner of the associated server.
Unexpected DNS record updates against domains belonging to other tenants of the same Nezha instance.

Detection Strategies

Audit the database for servers rows whose ddns_profiles references point to profiles owned by a different user than the server owner.
Add server-side logging that records the user ID of both the server owner and the resolved DDNS profile owner at dispatch time, and alert when they differ.
Review API gateway logs for repeated PATCH /server/{id} calls containing numerically sequential or speculative profile IDs.

Monitoring Recommendations

Forward Nezha application and DDNS worker logs to a centralized log platform and alert on cross-owner profile resolution events.
Monitor outbound DNS provider API calls originating from Nezha for changes that do not correlate to the expected owner's domains.
Track creation rates of new DDNS profiles followed by immediate DNS update activity from unrelated servers.

How to Mitigate CVE-2026-53521

Immediate Actions Required

Upgrade all Nezha Monitoring deployments to version 2.1.0 or later.
Audit existing servers records and remove any ddns_profiles references that point to profiles not owned by the same user.
Rotate DDNS provider API credentials used by Nezha if cross-tenant resolution is suspected to have occurred.

Patch Information

The maintainers fixed CVE-2026-53521 in Nezha Monitoring version 2.1.0. The patch validates that each ddns_profiles ID supplied to PATCH /server/{id} exists and is owned by the requesting user before persistence. Refer to the GitHub Security Advisory GHSA-39g2-8x68-pmx8 for commit-level detail.

Workarounds

Restrict the Nezha API to trusted administrators until the upgrade is applied, removing member-level write access to server records.
Disable the DDNS feature in the Nezha configuration if it is not required in the deployment.
Add a database-level integrity check or foreign-key constraint between servers.ddns_profiles references and the ddns_profiles table, scoped to the same owner.

bash

# Configuration example: upgrade Nezha Monitoring to the patched release
docker pull ghcr.io/naiba/nezha:v2.1.0
docker stop nezha-dashboard && docker rm nezha-dashboard
docker run -d \
  --name nezha-dashboard \
  -p 8008:80 \
  -v /opt/nezha/dashboard/data:/dashboard/data \
  ghcr.io/naiba/nezha:v2.1.0