CVE-2026-48119 - Nezha service-monitor result forgery

Nezha accepted service-monitor TaskResult messages from an authenticated agent based only on whether the referenced service ID existed. The inbound result path did not verify that the reporting agent was actually assigned to that service, belonged to the same owner boundary, or had been selected for the monitoring task. A low-privilege user with a valid agent secret could therefore forge results for another user’s services.

This is an integrity and tenant-boundary failure, not just a “monitoring bug.” Forged results can poison service history, flip current-state views, and trigger victim-owned notifications with attacker-controlled content. The fix needs version upgrades plus explicit authorization checks on every inbound result-processing path that trusts agent identity.

When to use it

Use this recipe when a repository builds, forks, vendors, deploys, or customizes Nezha and accepts monitoring task results from authenticated agents. It is most important for multi-user, tenant-separated, MSP, shared-team, or customer managed environments where low-privilege users can register agents or control agent secrets.

Use it to upgrade Nezha and prove inbound result-processing checks both authentication and ownership/coverage authorization. Do not use it to send forged gRPC task results to a live dashboard.

Inputs

  • Go modules, forks, vendored code, Dockerfiles, images, Compose/Helm/Kubernetes manifests, SBOMs, generated dependency reports, and deployment docs that may include github.com/nezhahq/nezha.
  • Inbound task-result paths: RequestTask, TaskResult, service sentinel workers, cron result handling, service ownership checks, server coverage rules, and notification dispatch.
  • Multi-user/tenant model: agent registration, agent secrets, user IDs, tenant IDs, service ownership, team boundaries, and whether authenticated low-privilege users can control reporters.
  • Monitoring integrity data: service history, current state, notification content/routing, audit logs, and cleanup ownership for historical forged results.
  • Validation commands for go test, authz tests, image build, deployment rendering, SBOM refresh, and dependency/security scans.

Affected versions

Package Vulnerable versions Fixed versions
github.com/nezhahq/nezha >=2.0.0, <2.0.12 2.0.12+
github.com/nezhahq/nezha >=0.20.0, <1.14.15-0.20260521020202-02129f16fb15 1.14.15-0.20260521020202-02129f16fb15+

Indicator-of-exposure

  • The repository builds, forks, vendors, or deploys Nezha in an affected version range.
  • The deployment allows multiple users, tenants, or semi-trusted operators to register agents or control agent secrets.
  • The runtime accepts gRPC task results from agents and stores service-monitor history, current-state, or notification data.
  • The same codebase customizes inbound TaskResult handling, service ownership, server coverage rules, or monitoring notifications.

Quick checks:

rg -n "nezhahq/nezha|TaskResult|RequestTask|ServiceSentinel|canReportServiceResult|CanReportCronResult|service-monitor|SkipServers|ServiceCover|client_secret|client_uuid" .
go list -m all | rg "nezhahq/nezha"
rg -n "image: .*nezha|nezha-agent|nezha-dashboard|client_secret|grpc" Dockerfile* docker-compose*.yml compose*.yml charts k8s deploy .

Remediation strategy

  • Upgrade to 2.0.12+ or the patched 1.x commit line.
  • Regenerate go.sum, container images, SBOMs, deployment artifacts, and dependency reports.
  • Ensure inbound service-monitor and cron-result processing verifies both authentication and authorization: the reporting agent must belong to the service owner boundary and must be eligible to report for that task.
  • Add tests that prove forged results from an authenticated but unauthorized agent are rejected and do not create history rows or trigger notifications.
  • Review historical monitoring integrity and outbound notifications if multi-user agents were exposed before rollout.

The prompt

You are remediating CVE-2026-48119 / GHSA-4g6j-g789-rghm, a Nezha
authorization flaw that lets authenticated agents forge service-monitor results
for other users' services. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Nezha, adds or verifies
  inbound task-result ownership checks, adds safe regression tests, refreshes
  generated artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not control an affected Nezha runtime,
  fork, image, or deployment.

## Rules

- Scope only CVE-2026-48119 / GHSA-4g6j-g789-rghm and directly related inbound
  task-result authorization checks.
- Treat agent secrets, user IDs, tenant IDs, notification content, service
  history, and monitoring data as sensitive.
- Do not send forged gRPC task results to a live deployment or generate a
  cross-tenant proof against a shared environment.
- Do not weaken monitoring ownership checks or disable alerting globally to
  silence the issue.
- Do not auto-merge.

## Steps

1. Inventory every Nezha module, fork, image, deployment manifest, lockfile,
   SBOM, and generated dependency report controlled by this repository.
2. Determine every resolved version. A target is vulnerable if it resolves to
   `>=2.0.0, <2.0.12` or `>=0.20.0, <1.14.15-0.20260521020202-02129f16fb15`.
3. Search inbound result-processing paths:
   `RequestTask`, `TaskResult`, service sentinel workers, cron result handling,
   coverage checks, service ownership checks, and notification dispatch.
4. Determine whether multi-user or tenant-separated agents exist and whether
   authenticated low-privilege users can register or control agents.
5. If the repository does not control an affected Nezha runtime, stop with
   `TRIAGE.md` listing checked files, resolved versions, and the owning team if
   another platform supplies Nezha.
6. Upgrade to `2.0.12+` or the patched 1.x line. Refresh `go.sum`, images,
   SBOMs, deployment render output, and dependency reports.
7. Verify or add fail-closed inbound authorization:
   - require the reporting agent to be covered by the service configuration;
   - require owner-boundary validation between service and reporter server;
   - require cron-task result ownership checks as well as service-monitor
     checks;
   - reject unauthorized results before history mutation or notification logic.
8. Add safe regression tests that do not contact a live dashboard:
   - authenticated but unauthorized reporter cannot create service history;
   - unauthorized reporter cannot alter current service state;
   - unauthorized reporter cannot trigger victim-owned notifications;
   - authorized reporters still work.
9. Add a PR body section named `CVE-2026-48119 operator actions` that states:
   - Nezha versions before and after;
   - whether multi-user or tenant-separated agents exist;
   - which inbound task-result paths were reviewed;
   - whether historical service-monitor data or notifications may need review;
   - whether agent secrets, sessions, or notification routing need cleanup.
10. Run available validation: `go test`, unit tests, authz tests, build,
    image build, deployment rendering, SBOM refresh, and dependency/security
    scans.
11. Use PR title:
    `fix(sec): remediate CVE-2026-48119 in Nezha`.

## Stop conditions

- No affected Nezha runtime, fork, image, or deployment is controlled by this
  repository.
- The deployment is single-user and externally unreachable, and the repository
  does not ship the vulnerable dashboard logic.
- A fixed version cannot be adopted without a broader platform migration;
  document owner and temporary containment.
- Verification would require forged live agent traffic against a shared or
  production system.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled module, image, or SBOM resolves affected Nezha versions.
  • Inbound result handling verifies both agent identity and ownership/coverage authorization before mutating state.
  • Tests prove unauthorized reporters cannot create history, alter state, or trigger notifications.
  • Operator notes address historical integrity review when shared agents existed.

Watch for

  • Upgrading the module but leaving a custom fork or deployment image on the old code path.
  • Fixing service-monitor results while leaving cron-result authorization on the old trust model.
  • Treating authenticated agents as inherently authorized for any resource.
  • Reviewing only current-state displays while historical records and notifications remain poisoned.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades Nezha to 2.0.12+ or the patched 1.x line, verifies inbound service-monitor and cron-result ownership checks, adds safe regression tests, refreshes generated artifacts, and documents operator cleanup.
  • TRIAGE.md when no controlled affected Nezha runtime, fork, image, module, or deployment exists.

The output must list versions before/after, inbound result paths reviewed, multi-user or tenant-separated agent exposure, ownership/coverage checks added or verified, validation commands, and whether historical data, notifications, agent secrets, sessions, or routing need review. It must not send forged live agent traffic, expose agent secrets, print tenant/user identifiers from production, or weaken alerting globally.

References