7.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-48119

CVE-2026-48119: Nezha Monitoring: Authenticated agents can forge service-monitor results for other users' services

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 0.20.0 to before version 2.0.12, authenticated agents can forge service-monitor results for other users' services. This issue has been patched in version 2.0.12.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-48119

CVE-2026-48119:

7.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/nezhahq/nezha	go	>= 0.20.0, < 1.14.15-0.20260521020202-02129f16fb15	1.14.15-0.20260521020202-02129f16fb15
github.com/nezhahq/nezha	go	>= 2.0.0, < 2.0.12	2.0.12

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability is a missing authorization flaw where the system processes task results from authenticated agents without verifying if the agent is authorized to report for the specified task. This allows a low-privilege attacker with a valid agent to forge results for services and cron jobs belonging to other users, leading to data integrity violations and potentially incorrect alert notifications.

The analysis of the patch identified two key functions where this vulnerability was present:

singleton.ServiceSentinel.worker: This function is responsible for processing service monitor results. The patch shows that the original code only checked for the existence of the service ID from the incoming report. The fix introduces a call to canReportServiceResult, which performs the necessary authorization checks, verifying that the reporting agent is covered by the service's monitoring configuration and belongs to the correct user.
rpc.NezhaHandler.RequestTask: This function is the main gRPC endpoint for receiving all task results. While the patch for this specific file was not provided in the commit details, the addition of the CanReportCronResult function and a new security test file (request_task_security_test.go) strongly indicate that this function was also vulnerable. It improperly handled cron job results, and the patch added authorization checks by calling the new CanReportCronResult function before processing them. The tests explicitly validate that forged cron results are now rejected.

Both functions are critical runtime indicators for this vulnerability. During an exploit, RequestTask would be the initial function in the stack trace to receive the malicious data, and for service monitoring, the exploit's effects would be processed by the worker function in a separate goroutine.

Vulnerable functions

singleton.ServiceSentinel.worker

service/singleton/servicesentinel.go

This function runs as a background worker processing service monitor results. The vulnerability lies in the fact that before the patch, it only checked if the service ID in the reported result existed. It did not perform any authorization to verify if the agent reporting the result was actually assigned to monitor that service. This allowed any authenticated agent to forge monitoring results for any service in the system, leading to cross-tenant data corruption.

rpc.NezhaHandler.RequestTask

service/rpc/nezha.go

This gRPC handler function is the entry point for all task results submitted by agents. While the primary vulnerability report focuses on service monitors, the patch and associated tests reveal a similar authorization flaw for cron job results, which are also handled by this function. The function accepted and processed results for cron jobs without verifying if the reporting agent was authorized to do so. This allowed an attacker to poison the status and history of cron jobs belonging to other users.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.