Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid admin account or scoped PAT
-
DeliverySend GET /api/v1/ddns or /api/v1/notification
-
ExploitReceive full plaintext credentials in JSON response
-
ExecutionExtract Cloudflare tokens or TencentCloud SecretKeys
-
PersistAuthenticate directly to third-party cloud APIs
-
ImpactModify external infrastructure or exfiltrate data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK
2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a valid authenticated session on the Nezha instance - either an admin account or a personal access token (PAT) scoped to nezha:ddns:read (to extract DDNS provider credentials) or nezha:notification:read (to extract notification channel secrets including webhook tokens). No non-default configuration is required beyond having at least one DDNS provider or notification channel configured, which is the intended operational state of the platform. Exploitation is strictly limited to users who already hold valid, high-privilege credentials on the Nezha instance; unauthenticated external attackers cannot reach these endpoints. The limiting factor is the PR:H requirement: only those already granted admin or scoped PAT access can exploit this. In single-operator self-hosted deployments the real-world risk is reduced, but in team environments where PATs are distributed to multiple operators, any PAT holder gains access to all stored third-party secrets. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N, score 6.9) accurately reflects that exploitation requires high-privilege authentication, substantially constraining the threat surface relative to unauthenticated flaws. Despite the Medium base score, the real-world confidentiality impact is significant because the credentials exposed are not scoped to Nezha itself - Cloudflare API tokens and TencentCloud SecretKeys can be leveraged to access and manipulate third-party cloud infrastructure entirely outside of the Nezha platform. The primary threat actor is an insider, a compromised admin account, or a PAT holder whose scope was intended as read-only. In multi-operator or team deployments where PATs are distributed, this represents a meaningful lateral-movement risk. No EPSS score was provided, and the product's niche self-hosted deployment footprint suggests low likelihood of automated or opportunistic exploitation. There is no CISA KEV listing and no known POC, consistent with a low urgency for external attackers but moderate urgency for organizations issuing PATs to multiple operators. The CVSS score slightly understates the downstream blast radius since harvested tokens extend attacker reach beyond the Nezha instance itself. |
| Exploit ScenarioDerived | An operator with a PAT scoped to nezha:ddns:read issues a single authenticated GET request to /api/v1/ddns and receives a JSON array containing the full Cloudflare API token stored in Nezha. The operator then uses that token directly against the Cloudflare API to enumerate DNS zones and modify DNS records, enabling traffic redirection or subdomain takeover on infrastructure managed by the Nezha deployment owner - all without any access to Nezha's administrative interface. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 10, 2026
Nezha Monitoring versions prior to 2.2.5 expose stored third-party API credentials in plaintext through two listing API endpoints to any authenticated admin or PAT holder with read-scoped access. The GET /api/v1/ddns and GET /api/v1/notification handlers serialize full database objects - including Cloudflare API tokens, TencentCloud SecretKeys, and Slack, Discord, and Telegram webhook URLs with embedded bot tokens - without any field-level redaction, enabling a single API call to harvest all configured credentials. No public exploit has been identified at time of analysis, and a vendor-released patch is available in v2.2.5.
RemediationAI
Upgrade Nezha Monitoring to v2.2.5, which introduces field-level redaction for credential fields in the listDDNS and listNotification API responses. The patch commit is at https://github.com/nezhahq/nezha/commit/39d398066d8c644fe452f74704e34ada6c7ab61e and the release at https://github.com/nezhahq/nezha/releases/tag/v2.2.5. As an immediate pre-patch compensating control, rotate all third-party credentials stored in Nezha - revoke and reissue Cloudflare API tokens, TencentCloud SecretKeys, and all Slack, Discord, and Telegram webhook URLs - since any PAT holder with read scope may have already obtained them. Additionally, audit all issued PATs and revoke those holding nezha:ddns:read or nezha:notification:read scope that are not operationally required, reducing the window of exposure until patching is complete. Network-level controls such as IP allowlisting for the Nezha API are a useful defense-in-depth measure but do not prevent exploitation by legitimate internal users.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Nezha Monitoring is a self-hostable, Go-based server and website monitoring and O&M (operations and maintenance) platform identified by CPE cpe:2.3:a:nezhahq:nezha:*:*:*:*:*:*:*:*. The vulnerability is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), arising from the listDDNS and listNotification API handlers serializing full database record objects directly into HTTP JSON responses without masking or excluding credential fields. Rather than returning only non-sensitive metadata (e.g., provider name, label), both handlers return the complete stored configuration object, which includes raw API keys, secret keys, and full webhook URLs with embedded authentication tokens. This design flaw means that read-only list permissions are functionally equivalent to credential-read permissions - a separation-of-privilege failure common in systems where credential storage and operational configuration are not architecturally decoupled.
Know when Nezha gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-accessible API requires high privileges (PR:H); full plaintext credential disclosure warrants C:H; no integrity or availability impact from the disclosure itself.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated re
Unauthenticated path traversal in Nezha Monitoring (nezhahq/nezha) before 2.0.13 allows remote attackers to read arbitra
Host header injection in Nezha Monitoring versions 1.0.0 through 2.2.0 allows unauthenticated remote attackers to redire
Unbounded WebSocket stream allocation in Nezha Monitoring versions 1.0.0 through 2.1.x allows any authenticated dashboar
Nezha Monitoring versions 2.0.14 through 2.1.0 (exclusive) allows any authenticated user to exploit the NAT-based Host c
Cross-tenant session hijacking in Nezha Monitoring (v1.14.13-1.14.14 and v2.0.0-2.0.9) lets any authenticated low-privil
Nezha monitoring dashboards running versions 1.0.0 through 2.3.14 can be knocked offline by an authenticated user who ho
Resource exhaustion in Nezha 2.0.13 through 2.3.14 allows an authenticated user to open unbounded concurrent connections
Cleartext third-party credentials are exposed to any authenticated principal holding DDNS read access in Nezha versions
Permanent deadlock of the alerting subsystem in Nezha Dashboard 1.8.0 through 2.3.12 allows any authenticated non-admin
Authenticated privilege escalation in Nezha Dashboard before 2.3.5 lets any account holding the nezha:service:write scop
Denial of service in the Nezha monitoring dashboard before 2.3.8 lets any authenticated non-administrator account crash
EUVD-2026-43108
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB