CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
14623 vulnerabilities reference this CWE, most recent first.
GHSA-RXF6-F2P5-Q27M
Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2022-05-24 17:07An information disclosure issue was discovered GitLab versions < 12.1.2, < 12.0.4, and < 11.11.6 in the security dashboard which could result in disclosure of vulnerability feedback information.
{
"affected": [],
"aliases": [
"CVE-2019-5470"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-01-28T03:15:00Z",
"severity": "MODERATE"
},
"details": "An information disclosure issue was discovered GitLab versions \u003c 12.1.2, \u003c 12.0.4, and \u003c 11.11.6 in the security dashboard which could result in disclosure of vulnerability feedback information.",
"id": "GHSA-rxf6-f2p5-q27m",
"modified": "2022-05-24T17:07:36Z",
"published": "2022-05-24T17:07:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5470"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/490250"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2019/07/29/security-release-gitlab-12-dot-1-dot-2-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab-ee/issues/9665"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-RXF6-WJH4-JFJ6
Vulnerability from github – Published: 2026-05-23 00:08 – Updated: 2026-06-26 21:28Summary
createAlertRule and createService (and their update* siblings) accept FailTriggerTasks []uint64 and RecoverTriggerTasks []uint64 — IDs of cron tasks to fire when the alert/service trips. The validation function only validates the alert's Rules.Ignore server map; it never checks that the cron task IDs in FailTriggerTasks / RecoverTriggerTasks belong to the caller.
When the alert fires, singleton.CronShared.SendTriggerTasks(taskIDs, triggerServer) (service/singleton/crontask.go:113-127) looks up those task IDs in the global cron registry and executes them via CronTrigger. For non-AlertTrigger cover modes, CronTrigger fans the command out to every server in ServerShared.Range with no ownership check.
Net effect: a RoleMember can attach their alert rule (or service monitor) to another user's cron task ID — including admin's crons. When the alert trips, the admin's cron command runs across every server (or every server in its allow/deny list).
This is the same fanout/auth-bypass class as NEZHA-002 (cron creation), but reachable by a different code path: even if /cron writes are restricted to admin, this /alert-rule and /service writes are member-reachable and let a member invoke pre-existing admin crons.
Affected versions
Commit 50dc8e660326b9f22990898142c58b7a5312b42a and earlier on master.
Reachability chain
POST /api/v1/alert-rule(orPOST /api/v1/service) iscommonHandler-gated — any authenticated user.createAlertRule/createServiceacceptsFailTriggerTasksandRecoverTriggerTasksfrom the request body without validating ownership.validateRule(cmd/dashboard/controller/alertrule.go:169-196) only checksrule.Ignoreserver IDs — not the trigger task IDs.validateServers(cmd/dashboard/controller/service.go:543-549) only checks the service'sSkipServersmap — not the trigger task IDs.- When the alert/service trips:
service/singleton/alertsentinel.go:170, 180andservice/singleton/servicesentinel.go:747, 750callCronShared.SendTriggerTasks(...). SendTriggerTasks(service/singleton/crontask.go:113-127) iterates the requested task IDs againstc.listand callsCronTrigger(c, triggerServer)()for each — no ownership check.CronTriggerthen fans the cron'sCommandto every connected agent (perCoverrules).
Code locations
// cmd/dashboard/controller/alertrule.go:47-77
func createAlertRule(c *gin.Context) (uint64, error) {
var arf model.AlertRuleForm
var r model.AlertRule
if err := c.ShouldBindJSON(&arf); err != nil { return 0, err }
uid := getUid(c)
r.UserID = uid
r.Name = arf.Name
r.Rules = arf.Rules
r.FailTriggerTasks = arf.FailTriggerTasks // <-- attacker-controlled task IDs
r.RecoverTriggerTasks = arf.RecoverTriggerTasks // <-- ditto
r.NotificationGroupID = arf.NotificationGroupID
enable := arf.Enable
r.TriggerMode = arf.TriggerMode
r.Enable = &enable
if err := validateRule(c, &r); err != nil { return 0, err } // only checks rule.Ignore servers
...
}
// cmd/dashboard/controller/alertrule.go:169-196
func validateRule(c *gin.Context, r *model.AlertRule) error {
if len(r.Rules) > 0 {
for _, rule := range r.Rules {
if !singleton.ServerShared.CheckPermission(c, maps.Keys(rule.Ignore)) {
return singleton.Localizer.ErrorT("permission denied")
}
// ... duration/cycle validation only
}
}
// BUG: no check on r.FailTriggerTasks or r.RecoverTriggerTasks ownership.
return nil
}
// service/singleton/crontask.go:113-127
func (c *CronClass) SendTriggerTasks(taskIDs []uint64, triggerServer uint64) {
c.listMu.RLock()
var cronLists []*model.Cron
for _, taskID := range taskIDs {
if c, ok := c.list[taskID]; ok { // <-- looks up ANY cron in global state
cronLists = append(cronLists, c)
}
}
c.listMu.RUnlock()
// BUG: no ownership check between alert.UserID and cron.UserID before invoking.
for _, c := range cronLists {
go CronTrigger(c, triggerServer)()
}
}
// service/singleton/crontask.go:138-181 — CronTrigger
return func() {
if cr.Cover == model.CronCoverAlertTrigger {
// alert-only: only sends to triggerServer (the member's server, when alert was triggered by it)
if s, ok := ServerShared.Get(triggerServer[0]); ok && s.TaskStream != nil {
s.TaskStream.Send(&pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})
}
return
}
// For Cover=CronCoverAll or CronCoverIgnoreAll: fan out to every server.
for _, s := range ServerShared.Range {
if cr.Cover == model.CronCoverAll && crIgnoreMap[s.ID] { continue }
if cr.Cover == model.CronCoverIgnoreAll && !crIgnoreMap[s.ID] { continue }
if s.TaskStream != nil {
s.TaskStream.Send(&pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})
}
}
}
PoC
Pre-conditions: attacker has RoleMember credentials. Admin has at least one pre-existing cron with Cover=CronCoverAll or Cover=CronCoverIgnoreAll (i.e., a "run on all servers" maintenance cron — common in monitoring deployments).
Step 1: Enumerate admin cron IDs by ID-guessing. Try IDs 1..N; create AlertRule referencing each, see if the alert handler accepts.
Step 2: Create an alert rule referencing the admin's cron and pointed at an offline-trigger condition on the member's own server.
TOKEN=$(curl -sX POST -H 'Content-Type: application/json' \
-d '{"username":"member","password":"hunter2"}' \
http://nezha.example.com/api/v1/login | jq -r .token)
curl -sX POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
-d '{"name":"trip","rules":[{"type":"offline","duration":3,"min":1.0,"cover":"member-server-id"}],"fail_trigger_tasks":[1,2,3,4,5],"recover_trigger_tasks":[],"notification_group_id":0,"trigger_mode":0,"enable":true}' \
http://nezha.example.com/api/v1/alert-rule
Step 3: Stop the agent on the member's own server (or unplug it). The alert trips after duration seconds. SendTriggerTasks([1,2,3,4,5], member-server-id) runs.
Step 4: For each cron ID in the list, if that cron exists in the global registry and has Cover=CronCoverAll/IgnoreAll, its Command runs on every server.
The same chain works via POST /api/v1/service (service-monitor with fail_trigger_tasks).
Composability with NEZHA-002
If NEZHA-002 is unfixed, this chain is redundant — the member already has direct cron-create access. With NEZHA-002 fixed, this still gives the member a means to invoke any pre-existing admin cron with the member's chosen trigger condition. The fix surface is also independent (alertrule/service write paths, not /cron writes).
Suggested fix
In validateRule (and validateServers):
if !singleton.CronShared.CheckPermission(c, slices.Values(r.FailTriggerTasks)) {
return singleton.Localizer.ErrorT("permission denied")
}
if !singleton.CronShared.CheckPermission(c, slices.Values(r.RecoverTriggerTasks)) {
return singleton.Localizer.ErrorT("permission denied")
}
Defense-in-depth in SendTriggerTasks: enforce that task.UserID == alert.UserID || alertOwnerIsAdmin || taskOwnerIsAdmin.
Severity
- PR:L because RoleMember credentials needed.
- AC:H because attacker has to ID-guess admin cron IDs and have an alert-trip vector. (For a deployment where the attacker has visibility into max cron ID via UI hints or the
id-query echo, AC drops to L.) - S:C because the cron command runs on every connected agent (different trust zone).
- Auth: authenticated
RoleMember.
Reproduction environment
- Tested against:
nezhahq/nezhamaster @50dc8e660326b9f22990898142c58b7a5312b42a. - Code locations:
cmd/dashboard/controller/alertrule.go:47-77(createAlertRule), 91-131 (updateAlertRule), 169-196 (validateRule)cmd/dashboard/controller/service.go:404-445(createService), 459-509 (updateService), 543-549 (validateServers)service/singleton/crontask.go:113-127(SendTriggerTasks), 133-181 (CronTrigger)service/singleton/alertsentinel.go:170, 180(alert-fire callsite)service/singleton/servicesentinel.go:742-750(service-fire callsite)
Reporter
Eddie Ran. Filed via reporter API. Companion to NEZHA-001/002 — same auth-bypass class but a different write path.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nezhahq/nezha"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.14.15-0.20260517022419-d7526351cf97"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47120"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-23T00:08:45Z",
"nvd_published_at": "2026-06-12T22:16:51Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`createAlertRule` and `createService` (and their `update*` siblings) accept `FailTriggerTasks []uint64` and `RecoverTriggerTasks []uint64` \u2014 IDs of cron tasks to fire when the alert/service trips. The validation function only validates the alert\u0027s `Rules.Ignore` server map; it never checks that the cron task IDs in `FailTriggerTasks` / `RecoverTriggerTasks` belong to the caller.\n\nWhen the alert fires, `singleton.CronShared.SendTriggerTasks(taskIDs, triggerServer)` (`service/singleton/crontask.go:113-127`) looks up those task IDs in the global cron registry and executes them via `CronTrigger`. For non-`AlertTrigger` cover modes, `CronTrigger` fans the command out to every server in `ServerShared.Range` with no ownership check.\n\nNet effect: a `RoleMember` can attach their alert rule (or service monitor) to **another user\u0027s** cron task ID \u2014 including admin\u0027s crons. When the alert trips, the admin\u0027s cron command runs across every server (or every server in its allow/deny list).\n\nThis is the same fanout/auth-bypass class as `NEZHA-002` (cron creation), but reachable by a different code path: even if `/cron` writes are restricted to admin, this `/alert-rule` and `/service` writes are member-reachable and let a member invoke pre-existing admin crons.\n\n## Affected versions\n\nCommit `50dc8e660326b9f22990898142c58b7a5312b42a` and earlier on `master`.\n\n## Reachability chain\n\n1. `POST /api/v1/alert-rule` (or `POST /api/v1/service`) is `commonHandler`-gated \u2014 any authenticated user.\n2. `createAlertRule` / `createService` accepts `FailTriggerTasks` and `RecoverTriggerTasks` from the request body without validating ownership.\n3. `validateRule` (`cmd/dashboard/controller/alertrule.go:169-196`) only checks `rule.Ignore` server IDs \u2014 not the trigger task IDs.\n4. `validateServers` (`cmd/dashboard/controller/service.go:543-549`) only checks the service\u0027s `SkipServers` map \u2014 not the trigger task IDs.\n5. When the alert/service trips: `service/singleton/alertsentinel.go:170, 180` and `service/singleton/servicesentinel.go:747, 750` call `CronShared.SendTriggerTasks(...)`.\n6. `SendTriggerTasks` (`service/singleton/crontask.go:113-127`) iterates the requested task IDs against `c.list` and calls `CronTrigger(c, triggerServer)()` for each \u2014 no ownership check.\n7. `CronTrigger` then fans the cron\u0027s `Command` to every connected agent (per `Cover` rules).\n\n## Code locations\n\n```go\n// cmd/dashboard/controller/alertrule.go:47-77\nfunc createAlertRule(c *gin.Context) (uint64, error) {\n var arf model.AlertRuleForm\n var r model.AlertRule\n if err := c.ShouldBindJSON(\u0026arf); err != nil { return 0, err }\n uid := getUid(c)\n r.UserID = uid\n r.Name = arf.Name\n r.Rules = arf.Rules\n r.FailTriggerTasks = arf.FailTriggerTasks // \u003c-- attacker-controlled task IDs\n r.RecoverTriggerTasks = arf.RecoverTriggerTasks // \u003c-- ditto\n r.NotificationGroupID = arf.NotificationGroupID\n enable := arf.Enable\n r.TriggerMode = arf.TriggerMode\n r.Enable = \u0026enable\n\n if err := validateRule(c, \u0026r); err != nil { return 0, err } // only checks rule.Ignore servers\n ...\n}\n```\n\n```go\n// cmd/dashboard/controller/alertrule.go:169-196\nfunc validateRule(c *gin.Context, r *model.AlertRule) error {\n if len(r.Rules) \u003e 0 {\n for _, rule := range r.Rules {\n if !singleton.ServerShared.CheckPermission(c, maps.Keys(rule.Ignore)) {\n return singleton.Localizer.ErrorT(\"permission denied\")\n }\n // ... duration/cycle validation only\n }\n }\n // BUG: no check on r.FailTriggerTasks or r.RecoverTriggerTasks ownership.\n return nil\n}\n```\n\n```go\n// service/singleton/crontask.go:113-127\nfunc (c *CronClass) SendTriggerTasks(taskIDs []uint64, triggerServer uint64) {\n c.listMu.RLock()\n var cronLists []*model.Cron\n for _, taskID := range taskIDs {\n if c, ok := c.list[taskID]; ok { // \u003c-- looks up ANY cron in global state\n cronLists = append(cronLists, c)\n }\n }\n c.listMu.RUnlock()\n // BUG: no ownership check between alert.UserID and cron.UserID before invoking.\n for _, c := range cronLists {\n go CronTrigger(c, triggerServer)()\n }\n}\n```\n\n```go\n// service/singleton/crontask.go:138-181 \u2014 CronTrigger\nreturn func() {\n if cr.Cover == model.CronCoverAlertTrigger {\n // alert-only: only sends to triggerServer (the member\u0027s server, when alert was triggered by it)\n if s, ok := ServerShared.Get(triggerServer[0]); ok \u0026\u0026 s.TaskStream != nil {\n s.TaskStream.Send(\u0026pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})\n }\n return\n }\n // For Cover=CronCoverAll or CronCoverIgnoreAll: fan out to every server.\n for _, s := range ServerShared.Range {\n if cr.Cover == model.CronCoverAll \u0026\u0026 crIgnoreMap[s.ID] { continue }\n if cr.Cover == model.CronCoverIgnoreAll \u0026\u0026 !crIgnoreMap[s.ID] { continue }\n if s.TaskStream != nil {\n s.TaskStream.Send(\u0026pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})\n }\n }\n}\n```\n\n## PoC\n\nPre-conditions: attacker has `RoleMember` credentials. Admin has at least one pre-existing cron with `Cover=CronCoverAll` or `Cover=CronCoverIgnoreAll` (i.e., a \"run on all servers\" maintenance cron \u2014 common in monitoring deployments).\n\nStep 1: Enumerate admin cron IDs by ID-guessing. Try IDs 1..N; create AlertRule referencing each, see if the alert handler accepts.\n\nStep 2: Create an alert rule referencing the admin\u0027s cron and pointed at an offline-trigger condition on the member\u0027s own server.\n\n```bash\nTOKEN=$(curl -sX POST -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"member\",\"password\":\"hunter2\"}\u0027 \\\n http://nezha.example.com/api/v1/login | jq -r .token)\n\ncurl -sX POST -H \"Authorization: Bearer $TOKEN\" -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"name\":\"trip\",\"rules\":[{\"type\":\"offline\",\"duration\":3,\"min\":1.0,\"cover\":\"member-server-id\"}],\"fail_trigger_tasks\":[1,2,3,4,5],\"recover_trigger_tasks\":[],\"notification_group_id\":0,\"trigger_mode\":0,\"enable\":true}\u0027 \\\n http://nezha.example.com/api/v1/alert-rule\n```\n\nStep 3: Stop the agent on the member\u0027s own server (or unplug it). The alert trips after `duration` seconds. `SendTriggerTasks([1,2,3,4,5], member-server-id)` runs.\n\nStep 4: For each cron ID in the list, if that cron exists in the global registry and has `Cover=CronCoverAll/IgnoreAll`, its `Command` runs on every server.\n\nThe same chain works via `POST /api/v1/service` (service-monitor with `fail_trigger_tasks`).\n\n## Composability with NEZHA-002\n\nIf `NEZHA-002` is unfixed, this chain is redundant \u2014 the member already has direct cron-create access. With `NEZHA-002` fixed, this still gives the member a means to invoke any **pre-existing** admin cron with the member\u0027s chosen trigger condition. The fix surface is also independent (alertrule/service write paths, not /cron writes).\n\n## Suggested fix\n\nIn `validateRule` (and `validateServers`):\n\n```go\nif !singleton.CronShared.CheckPermission(c, slices.Values(r.FailTriggerTasks)) {\n return singleton.Localizer.ErrorT(\"permission denied\")\n}\nif !singleton.CronShared.CheckPermission(c, slices.Values(r.RecoverTriggerTasks)) {\n return singleton.Localizer.ErrorT(\"permission denied\")\n}\n```\n\nDefense-in-depth in `SendTriggerTasks`: enforce that `task.UserID == alert.UserID || alertOwnerIsAdmin || taskOwnerIsAdmin`.\n\n## Severity\n\n - PR:L because RoleMember credentials needed.\n - AC:H because attacker has to ID-guess admin cron IDs and have an alert-trip vector. (For a deployment where the attacker has visibility into max cron ID via UI hints or the `id`-query echo, AC drops to L.)\n - S:C because the cron command runs on every connected agent (different trust zone).\n- **Auth:** authenticated `RoleMember`.\n\n## Reproduction environment\n\n- Tested against: `nezhahq/nezha` master @ `50dc8e660326b9f22990898142c58b7a5312b42a`.\n- Code locations:\n - `cmd/dashboard/controller/alertrule.go:47-77` (createAlertRule), 91-131 (updateAlertRule), 169-196 (validateRule)\n - `cmd/dashboard/controller/service.go:404-445` (createService), 459-509 (updateService), 543-549 (validateServers)\n - `service/singleton/crontask.go:113-127` (SendTriggerTasks), 133-181 (CronTrigger)\n - `service/singleton/alertsentinel.go:170, 180` (alert-fire callsite)\n - `service/singleton/servicesentinel.go:742-750` (service-fire callsite)\n\n## Reporter\n\nEddie Ran. Filed via reporter API. Companion to NEZHA-001/002 \u2014 same auth-bypass class but a different write path.",
"id": "GHSA-rxf6-wjh4-jfj6",
"modified": "2026-06-26T21:28:31Z",
"published": "2026-05-23T00:08:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-rxf6-wjh4-jfj6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47120"
},
{
"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:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Nezha Monitoring: RoleMember can fire other users\u0027 cron tasks via AlertRule.FailTriggerTasks (no ownership check)"
}
GHSA-RXGG-V778-G4XJ
Vulnerability from github – Published: 2023-12-07 03:30 – Updated: 2023-12-07 03:30The System Dashboard plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the sd_global_value() function hooked via an AJAX action in all versions up to, and including, 2.8.7. This makes it possible for authenticated attackers, with subscriber-level access and above, to retrieve sensitive global value information.
{
"affected": [],
"aliases": [
"CVE-2023-5712"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-07T02:15:06Z",
"severity": "MODERATE"
},
"details": "The System Dashboard plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the sd_global_value() function hooked via an AJAX action in all versions up to, and including, 2.8.7. This makes it possible for authenticated attackers, with subscriber-level access and above, to retrieve sensitive global value information.",
"id": "GHSA-rxgg-v778-g4xj",
"modified": "2023-12-07T03:30:32Z",
"published": "2023-12-07T03:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5712"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/system-dashboard/tags/2.8.7/admin/class-system-dashboard-admin.php#L7382"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/system-dashboard/tags/2.8.8/admin/class-system-dashboard-admin.php#L7403"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/70f14d9d-6ed6-4bcb-944d-f9c5aa6a17a6?source=cve"
}
],
"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-RXGG-VPM5-PCCW
Vulnerability from github – Published: 2024-11-18 06:30 – Updated: 2024-11-18 18:30In Bitcoin Core before 25.0, a peer can affect the download state of other peers by sending a mutated block.
{
"affected": [],
"aliases": [
"CVE-2024-52921"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-18T04:15:05Z",
"severity": "MODERATE"
},
"details": "In Bitcoin Core before 25.0, a peer can affect the download state of other peers by sending a mutated block.",
"id": "GHSA-rxgg-vpm5-pccw",
"modified": "2024-11-18T18:30:54Z",
"published": "2024-11-18T06:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52921"
},
{
"type": "WEB",
"url": "https://bitcoincore.org/en/2024/10/08/disclose-mutated-blocks-hindering-propagation"
},
{
"type": "WEB",
"url": "https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-RXH4-Q26C-4FV9
Vulnerability from github – Published: 2022-12-20 21:30 – Updated: 2022-12-20 21:30In launchConfigNewNetworkFragment of NetworkProviderSettings.java, there is a possible way for the guest user to add a new WiFi network due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246301667
{
"affected": [],
"aliases": [
"CVE-2022-20556"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-16T16:15:00Z",
"severity": "LOW"
},
"details": "In launchConfigNewNetworkFragment of NetworkProviderSettings.java, there is a possible way for the guest user to add a new WiFi network due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246301667",
"id": "GHSA-rxh4-q26c-4fv9",
"modified": "2022-12-20T21:30:18Z",
"published": "2022-12-20T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20556"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RXH8-V6X2-M5H4
Vulnerability from github – Published: 2024-06-09 18:30 – Updated: 2026-04-28 15:30Missing Authorization vulnerability in Olive Themes Olive One Click Demo Import.This issue affects Olive One Click Demo Import: from n/a through 1.1.1.
{
"affected": [],
"aliases": [
"CVE-2024-32715"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-09T17:15:49Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Olive Themes Olive One Click Demo Import.This issue affects Olive One Click Demo Import: from n/a through 1.1.1.",
"id": "GHSA-rxh8-v6x2-m5h4",
"modified": "2026-04-28T15:30:41Z",
"published": "2024-06-09T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32715"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/olive-one-click-demo-import/vulnerability/wordpress-olive-one-click-demo-import-plugin-1-1-1-arbitrary-file-download-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/olive-one-click-demo-import/wordpress-olive-one-click-demo-import-plugin-1-1-1-arbitrary-file-download-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-RXHH-67GX-MR8W
Vulnerability from github – Published: 2024-10-16 09:30 – Updated: 2024-10-16 09:30The Paytium: Mollie payment forms & donations plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the create_mollie_account function in versions up to, and including, 4.3.7. This makes it possible for authenticated attackers with subscriber-level access to set up a mollie account.
{
"affected": [],
"aliases": [
"CVE-2023-7291"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-16T07:15:14Z",
"severity": "HIGH"
},
"details": "The Paytium: Mollie payment forms \u0026 donations plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the create_mollie_account function in versions up to, and including, 4.3.7. This makes it possible for authenticated attackers with subscriber-level access to set up a mollie account.",
"id": "GHSA-rxhh-67gx-mr8w",
"modified": "2024-10-16T09:30:31Z",
"published": "2024-10-16T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7291"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2853869%40paytium%2Ftrunk\u0026old=2824314%40paytium%2Ftrunk\u0026sfp_email=\u0026sfph_mail=#file0"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d4491b89-2120-4edb-a396-e45ba09b3b99?source=cve"
}
],
"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"
}
]
}
GHSA-RXHX-W577-5F4R
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-10-27 19:00InHand Networks IR615 Router's Versions 2.3.0.r4724 and 2.3.0.r4870 cloud portal allows for self-registration of the affected product without any requirements to create an account, which may allow an attacker to have full control over the product and execute code within the internal network to which the product is connected.
{
"affected": [],
"aliases": [
"CVE-2021-38486"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-19T13:15:00Z",
"severity": "HIGH"
},
"details": "InHand Networks IR615 Router\u0027s Versions 2.3.0.r4724 and 2.3.0.r4870 cloud portal allows for self-registration of the affected product without any requirements to create an account, which may allow an attacker to have full control over the product and execute code within the internal network to which the product is connected.",
"id": "GHSA-rxhx-w577-5f4r",
"modified": "2022-10-27T19:00:38Z",
"published": "2022-05-24T19:18:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38486"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-280-05"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RXJ2-8FR9-HWCQ
Vulnerability from github – Published: 2025-01-02 12:32 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in FeedbackWP kk Star Ratings allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects kk Star Ratings: from n/a through 5.4.5.
{
"affected": [],
"aliases": [
"CVE-2023-46639"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-02T12:15:14Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in FeedbackWP kk Star Ratings allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects kk Star Ratings: from n/a through 5.4.5.",
"id": "GHSA-rxj2-8fr9-hwcq",
"modified": "2026-04-28T21:35:29Z",
"published": "2025-01-02T12:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46639"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/kk-star-ratings/vulnerability/wordpress-kk-star-ratings-plugin-5-4-5-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-RXPX-FPWF-9Q46
Vulnerability from github – Published: 2024-10-05 12:31 – Updated: 2024-10-05 12:31The Rank Math SEO – AI SEO Tools to Dominate SEO Rankings plugin for WordPress is vulnerable to unauthorized modification and loss of data due to a missing capability check on the 'update_metadata' function in all versions up to, and including, 1.0.228. This makes it possible for unauthenticated attackers to insert new and update existing metadata beginning with 'rank_math', and delete arbitrary existing user metadata and term metadata. Deleting existing usermeta can cause a loss of access to the administrator dashboard for any registered users, including Administrators.
{
"affected": [],
"aliases": [
"CVE-2024-9161"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-05T12:15:02Z",
"severity": "MODERATE"
},
"details": "The Rank Math SEO \u2013 AI SEO Tools to Dominate SEO Rankings plugin for WordPress is vulnerable to unauthorized modification and loss of data due to a missing capability check on the \u0027update_metadata\u0027 function in all versions up to, and including, 1.0.228. This makes it possible for unauthenticated attackers to insert new and update existing metadata beginning with \u0027rank_math\u0027, and delete arbitrary existing user metadata and term metadata. Deleting existing usermeta can cause a loss of access to the administrator dashboard for any registered users, including Administrators.",
"id": "GHSA-rxpx-fpwf-9q46",
"modified": "2024-10-05T12:31:33Z",
"published": "2024-10-05T12:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9161"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/seo-by-rank-math/trunk/includes/rest/class-shared.php#L120"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/seo-by-rank-math/trunk/includes/rest/class-shared.php#L161"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/seo-by-rank-math/trunk/includes/rest/class-shared.php#L162"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/seo-by-rank-math/trunk/includes/rest/class-shared.php#L64"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3161896"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7df39a64-76c5-4ebe-a271-44bd147a3a86?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:L",
"type": "CVSS_V3"
}
]
}
Mitigation
- 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
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
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
- 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
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.