Stored XSS in Nezha Monitoring Dashboard via Notification Routes

Executive Summary

Nezha Monitoring is a self-hostable tool for monitoring servers and websites. In versions from 1.4.0 up to but not including 2.0.8, its dashboard supports two user roles: RoleAdmin and RoleMember. However, the notification routes POST /api/v1/notification and PATCH /api/v1/notification/:id are handled by a commonHandler instead of an adminHandler, allowing users with the RoleMember role to call them.

These handlers synchronously send an HTTP request to a URL controlled by the user and then reflect the entire response body back to the caller if the response is not a 2xx status, without any size limit. This behavior can be exploited by RoleMember users to potentially cause issues.

This vulnerability was fixed in version 2.0.8.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability allows users with limited privileges (RoleMember) to trigger HTTP requests to arbitrary URLs and receive the full response body if the response status is not successful (non-2xx).

Because there is no size limit on the reflected response, this could lead to information disclosure or resource exhaustion on the client side. The CVSS score of 7.7 indicates a high severity impact, particularly on confidentiality.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, upgrade Nezha Monitoring to version 2.0.8 or later, where the issue has been patched.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows a low-privilege user to perform Server-Side Request Forgery (SSRF) attacks, enabling unauthorized access to sensitive internal resources such as admin login pages and AWS IMDSv2 metadata.

This unauthorized access to sensitive data could lead to violations of data protection regulations like GDPR and HIPAA, which require strict controls over access to personal and sensitive information.

Additionally, the denial-of-service risk due to unbounded memory consumption could impact system availability, which is also a concern under many compliance frameworks.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring and testing the POST /api/v1/notification and PATCH /api/v1/notification/:id endpoints on the Nezha dashboard for unauthorized SSRF attempts by low-privilege RoleMember users.

Specifically, you can attempt to send crafted HTTP requests as a RoleMember user to these endpoints with URLs pointing to internal or sensitive resources (e.g., internal admin pages or AWS IMDSv2 metadata endpoints) and observe if the full response body is reflected back.

Commands to test this might include using curl to send POST requests with JSON payloads containing URLs to internal resources, for example:

• curl -X POST -H "Content-Type: application/json" -d '{"url":"http://169.254.169.254/latest/meta-data/"}' http://<nezha-dashboard>/api/v1/notification
• curl -X PATCH -H "Content-Type: application/json" -d '{"url":"http://internal-admin-page"}' http://<nezha-dashboard>/api/v1/notification/<id>

If the response contains the content of the internal resource or large response bodies are reflected, it indicates the presence of the SSRF vulnerability.

Useful 0 Not Useful 0