CVE-2026-111387 in Nezha
Summary
by MITRE • 10/16/2026
Nezha from 2.2.5 before 2.3.15 contains an information disclosure vulnerability that allows authenticated users to retrieve third-party credentials because listDDNS omits WebhookURL and WebhookRequestBody redaction. Admins or PATs with nezha:ddns:read scope can call GET /api/v1/ddns to read cleartext tokens embedded in every user's DDNS webhook profiles.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within Nezha versions prior to 2.3.15 represents a critical information disclosure flaw rooted in improper handling of sensitive data during API responses. Specifically, the listDDNS endpoint fails to redact or mask confidential credentials embedded within Dynamic DNS (DDNS) webhook configurations before returning them to the client. This design oversight allows any authenticated user possessing the nezha:ddns:read scope, including administrators and those holding Personal Access Tokens with this specific permission set, to retrieve cleartext tokens associated with third-party DDNS services. The technical mechanism involves a GET request to /api/v1/ddns, which returns JSON payloads containing WebhookURL and WebhookRequestBody fields in their original, unmasked form rather than displaying placeholder characters or omitting the sensitive values entirely.
From a security architecture perspective, this flaw aligns with CWE-200: Information Exposure, as it involves the unintentional leakage of confidential information through an API interface that should have enforced strict data sanitization policies. The vulnerability is particularly severe because DDNS webhooks often contain long-lived authentication tokens or secret keys required to interact with external DNS providers such as Cloudflare, AWS Route 53, or Google Domains. By exposing these credentials in plaintext within the response body, the application violates fundamental principles of least privilege and data minimization, effectively granting attackers access to third-party infrastructure controls without needing additional exploitation steps beyond simple API interaction.
The operational impact of this vulnerability is significant, as it enables lateral movement and potential compromise of external services linked to the Nezha monitoring instance. An attacker with read-only DDNS permissions can harvest these credentials to authenticate directly against the respective DNS providers. This could lead to unauthorized domain modifications, such as pointing domains to malicious IP addresses for phishing campaigns or man-in-the-middle attacks. Furthermore, if any webhook configurations include broader API keys beyond just DDNS tokens, those secrets would also be exposed, potentially escalating the impact to other integrated services like Slack notifications or email alerts that rely on similar authentication mechanisms.
This behavior is consistent with ATT&CK technique T1087: Account Discovery and can facilitate further reconnaissance activities under T1539: Steal Web Session Cookie if session tokens were also inadvertently exposed, though in this case the primary risk lies in credential theft leading to service compromise via T1078: Valid Accounts. The vulnerability persists due to a lack of input validation on output serialization processes within the DDNS management module, where developers likely assumed that read-only access would not necessitate strict redaction policies for sensitive fields.
To mitigate this issue, organizations must immediately upgrade Nezha to version 2.3.15 or later, which addresses the omission in WebhookURL and WebhookRequestBody redaction logic. In addition to patching, administrators should rotate all DDNS-related credentials that were accessible via the affected API endpoints, assuming potential compromise of those secrets during the window of vulnerability exposure. Future development practices should enforce a security-by-design approach where sensitive fields are explicitly masked or excluded from API responses by default, regardless of user role, unless specifically requested through dedicated, audited endpoints with enhanced authorization checks. Implementing automated secret scanning in CI/CD pipelines can also help detect such misconfigurations before deployment to production environments.