Recently, the open-source server monitoring project Nezha Monitoring disclosed a critical security vulnerability. Security researchers discovered that attackers can read sensitive files on the server without any authentication by simply crafting a special URL. This includes configuration files and database files, which can ultimately lead to a full administrator account takeover.
The vulnerability has been assigned CVE-2026-53519 and carries a CVSS score of 9.1 (Critical). All versions prior to 2.0.13 are affected.
For users who expose their Nezha Monitoring dashboard directly to the public internet, this vulnerability presents a significant real-world security risk.
Vulnerability Overview
This issue is a classic Path Traversal vulnerability.
The flaw exists in the Dashboard frontend resource routing logic.
The application was originally designed to recognize paths such as:
/dashboard/login /dashboard/settings /dashboard/server
However, due to the use of a simple string prefix check during development:
strings.HasPrefix(path, "/dashboard")
An attacker can craft a malicious path such as:
/dashboard../data/config.yaml
Because /dashboard.. still satisfies the prefix-matching condition, the application incorrectly treats it as a valid Dashboard request.
After internal path concatenation and normalization, the request ultimately resolves to:
data/config.yaml
As a result, the server directly returns the contents of the configuration file.
In simple terms, requests intended to access frontend resources can be abused to traverse directories and read sensitive files from the server.
How the Vulnerability Can Be Exploited
Researchers published the following proof-of-concept request:
curl --path-as-is \ http://example.com/dashboard../data/config.yaml
If the target is vulnerable, the response may directly reveal:
debug: false listen_port: 8008 jwt_secret_key: xxxxxxxxxxxxx agent_secret_key: xxxxxxxxxxxxx
Attackers can also access:
/dashboard../data/sqlite.db
to download the entire database file.
More importantly, certain URL-encoded variations can bypass filtering mechanisms as well:
/dashboard%2e%2e/data/config.yaml /dashboard..%2fdata/config.yaml
This means many common web protection rules may fail to detect or block these malicious requests.
What Data Can Be Exposed?
1. Configuration File (config.yaml)
Default location:
data/config.yaml
Typically contains:
- JWT secret key (jwt_secret_key)
- Agent secret key (agent_secret_key)
- OAuth client secrets
- GitHub tokens
- GeoIP API keys
- Third-party notification service credentials
- Email service configuration
Among these, the most critical item is:
jwt_secret_key:
Because this key directly determines the security of Dashboard authentication.
2. Database File (sqlite.db)
Default location:
data/sqlite.db
The database may contain:
- Administrator account information
- User lists
- Monitored server details
- API tokens
- Monitoring task configurations
- Alert notification settings
- OAuth login configurations
Attackers can analyze the database offline and extract additional sensitive information.
Why Is This Vulnerability So Dangerous?
Many file disclosure vulnerabilities result only in information leakage.
However, this vulnerability can be escalated into a complete administrator account takeover.
The full attack chain is as follows:
Step 1: Read the Configuration File
Obtain:
jwt_secret_key
Step 2: Read the Database
Obtain the user ID associated with the administrator account.
Step 3: Forge a JWT
Nezha Monitoring uses:
HS256
as its default JWT signing algorithm.
HS256 is a symmetric signing algorithm. Anyone possessing the signing secret can generate valid JWT tokens.
Step 4: Impersonate the Administrator
Using the leaked JWT secret, the attacker signs a new administrator token.
The token is then placed into the:
nz-jwt
cookie.
The system will treat the attacker as an authenticated administrator.
Step 5: Gain Full Dashboard Control
After successfully logging in, the attacker can:
- Add new monitored nodes
- Delete servers
- Modify users
- Configure notification channels
- Change OAuth settings
- Export monitoring data
- Retrieve API tokens
The entire attack requires no password guessing, no social engineering, and no user interaction.
Affected Versions
Affected versions:
Nezha Monitoring < 2.0.13
Fixed version:
Nezha Monitoring 2.0.13
The issue has been officially patched in version 2.0.13.
How to Check Whether You Are Affected
You should immediately investigate if the following conditions apply:
- You are using the official default deployment method.
- The Dashboard is accessible from the public internet.
- Your current version is older than 2.0.13.
You should also review web access logs for suspicious requests such as:
/dashboard../
/dashboard%2e%2e/
/dashboard..%2f
/../data/
Any of these requests may indicate an attempt to exploit the vulnerability.
Official Fix
The official patch focuses on two major areas.
1. Strict Dashboard Path Validation
Original logic:
strings.HasPrefix(path, "/dashboard")
After the fix, only legitimate routes such as:
/dashboard/ /dashboard/login /dashboard/settings
are allowed.
2. Prevent Directory Traversal
The application now validates the final resolved path after path normalization and concatenation.
This ensures the requested resource remains within:
admin-dist/
and prevents path escape attempts using:
../
What Should Users Do Immediately?
1. Upgrade to Version 2.0.13 or Later
This is the most important and effective mitigation measure.
2. Rotate All Secrets
Even after upgrading, it is strongly recommended to regenerate:
- jwt_secret_key
- agent_secret_key
- OAuth secrets
- GitHub tokens
- Third-party API keys
There is no reliable way to determine whether these secrets were accessed before the vulnerability became public.
3. Reset Administrator Passwords
If the database may have been exposed, all administrator account passwords should be reset immediately.
4. Restrict Public Access to the Dashboard
Recommended protections include:
- Cloudflare Access
- Zero Trust solutions
- VPN access
- IP whitelisting
- WAF protection
Avoid exposing management panels directly to the public internet whenever possible.
Editor’s Commentary
From a technical perspective, this is not a particularly complex vulnerability.
The root cause lies in treating a simple string prefix match as a security boundary.
For example:
/dashboard /dashboard..
Both paths satisfy the prefix-matching condition.
When such logic is combined with path concatenation functions, directory traversal vulnerabilities can emerge.
It is worth noting that vulnerabilities of this type are often easier to exploit at scale than remote code execution flaws. Attackers do not need valid credentials, elevated privileges, or a sophisticated exploit chain. A single carefully crafted HTTP request may be sufficient to expose highly sensitive data.
For organizations and individuals currently running Nezha Monitoring versions older than 2.0.13, upgrading should be treated as a priority. In addition, all JWT secrets and other sensitive credentials should be rotated immediately. Historical access logs should also be reviewed for suspicious /dashboard../ requests to help assess potential exposure and reduce ongoing risk.
GitHub Advisory:
Pre-auth Path Traversal via /dashboard.. Prefix Confusion Leaks jwt_secret_key · Advisory · nezhahq/nezha · GitHub
