Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5712 vulnerabilities reference this CWE, most recent first.

GHSA-GM7F-V959-FR2G

Vulnerability from github – Published: 2026-06-26 20:30 – Updated: 2026-06-26 20:30
VLAI
Summary
Fleet DM Vulnerable to Cross-Team Policy Data Exposure via Global Policy Read Endpoint
Details

Summary

The global policy read endpoint (GET /api/latest/fleet/policies/{policy_id}) performs authorization against an empty fleet.Policy{} struct with nil TeamID, then fetches any policy by ID from the database without verifying the fetched policy actually belongs to the global scope. This allows a user with observer-level access on any single team to read the full details of policies belonging to any other team, bypassing Fleet's team isolation model.

Details

The vulnerability is in GetPolicyByIDQueries at server/service/global_policies.go:163-180:

func (svc Service) GetPolicyByIDQueries(ctx context.Context, policyID uint) (*fleet.Policy, error) {
    // Auth check uses empty Policy{} — TeamID is nil
    if err := svc.authz.Authorize(ctx, &fleet.Policy{}, fleet.ActionRead); err != nil {
        return nil, err
    }

    // Fetches ANY policy by ID, regardless of team ownership
    policy, err := svc.ds.Policy(ctx, policyID)
    if err != nil {
        return nil, err
    }
    // ... populates install_software and run_script, returns full policy
    return policy, nil
}

The authorization passes because the OPA rule at server/authz/policy.rego:724-728 allows reading policies with null team_id for any user who holds a role on any team:

allow {
  is_null(object.team_id)
  object.type == "policy"
  team_role(subject, subject.teams[_].id) == [admin, maintainer, technician, observer, observer_plus][_]
  action == read
}

Since the auth object has nil TeamID, this rule fires for any team member. After authorization, ds.Policy() calls policyDB() at server/datastore/mysql/policies.go:283-288 with a nil teamID:

func policyDB(ctx context.Context, q sqlx.QueryerContext, id uint, teamID *uint) (*fleet.Policy, error) {
    teamWhere := "TRUE"  // nil teamID → no team filter
    args := []interface{}{id}
    if teamID != nil {
        teamWhere = "team_id = ?"
        args = append(args, *teamID)
    }
    // ... executes SELECT with WHERE p.id = ? AND {teamWhere}

This returns any policy regardless of team ownership, and the full policy object is returned to the caller without any post-fetch team verification.

By contrast, the properly-secured endpoints verify team scope: - GetTeamPolicyByIDQueries (team_policies.go:421-428) sets TeamID: ptr.Uint(teamID) on the auth object and calls ds.TeamPolicy() which filters by team - DeleteGlobalPolicies (global_policies.go:255-263) explicitly checks policy.PolicyData.TeamID != nil after fetching

PoC

Prerequisites: A Fleet instance with at least two teams. User A has observer role on Team 1 only. Team 2 has policies that User A should not be able to view.

# Step 1: Authenticate as User A (Team 1 observer only)
TOKEN=$(curl -s -X POST https://fleet.example.com/api/latest/fleet/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"team1observer@example.com","password":"password"}' | jq -r '.token')

# Step 2: Enumerate policy IDs (they are sequential integers)
# Attempt to read a policy belonging to Team 2 (e.g., policy ID 5)
curl -s -H "Authorization: Bearer $TOKEN" \
  https://fleet.example.com/api/latest/fleet/policies/5

# Expected: 403 Forbidden (user has no access to Team 2)
# Actual: 200 OK with full policy data:
# {
#   "policy": {
#     "id": 5,
#     "name": "Team 2 Sensitive Policy",
#     "query": "SELECT * FROM sensitive_table WHERE ...",
#     "team_id": 2,
#     "passing_host_count": 42,
#     "failing_host_count": 7,
#     "description": "...",
#     "resolution": "...",
#     ...
#   }
# }

Impact

An authenticated user with observer-level access on any single team can:

  • Read SQL queries from all team policies across the Fleet instance, potentially revealing security monitoring strategies, compliance checks, and internal infrastructure details
  • View host pass/fail counts for other teams' policies, leaking compliance posture data across team boundaries
  • Access software installer and script metadata associated with other teams' policies via the populatePolicyInstallSoftware and populatePolicyRunScript calls
  • Enumerate all policies by iterating sequential integer IDs

This breaks Fleet's team isolation model, which is designed to restrict visibility between teams. Organizations using teams to separate departments, clients, or security zones would have their policy data exposed across boundaries.

Recommended Fix

Add a post-fetch check in GetPolicyByIDQueries to verify the returned policy is actually a global policy (nil TeamID), consistent with how DeleteGlobalPolicies operates:

func (svc Service) GetPolicyByIDQueries(ctx context.Context, policyID uint) (*fleet.Policy, error) {
    if err := svc.authz.Authorize(ctx, &fleet.Policy{}, fleet.ActionRead); err != nil {
        return nil, err
    }

    policy, err := svc.ds.Policy(ctx, policyID)
    if err != nil {
        return nil, err
    }

    // Verify this is actually a global policy — team policies must be
    // accessed via the team-scoped endpoint which enforces team authorization
    if policy.TeamID != nil {
        return nil, authz.ForbiddenWithInternal(
            "attempting to read team policy via global endpoint",
            authz.UserFromContext(ctx),
            policy,
            fleet.ActionRead,
        )
    }

    if err := svc.populatePolicyInstallSoftware(ctx, policy); err != nil {
        return nil, ctxerr.Wrap(ctx, err, "populate install_software")
    }
    if err := svc.populatePolicyRunScript(ctx, policy); err != nil {
        return nil, ctxerr.Wrap(ctx, err, "populate run_script")
    }

    return policy, nil
}

Alternatively, re-authorize against the actual fetched policy object so OPA rules properly evaluate team membership, similar to how other Fleet endpoints handle object-level authorization.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fleetdm/fleet/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.85.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T20:30:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe global policy read endpoint (`GET /api/latest/fleet/policies/{policy_id}`) performs authorization against an empty `fleet.Policy{}` struct with nil TeamID, then fetches any policy by ID from the database without verifying the fetched policy actually belongs to the global scope. This allows a user with observer-level access on any single team to read the full details of policies belonging to any other team, bypassing Fleet\u0027s team isolation model.\n\n## Details\n\nThe vulnerability is in `GetPolicyByIDQueries` at `server/service/global_policies.go:163-180`:\n\n```go\nfunc (svc Service) GetPolicyByIDQueries(ctx context.Context, policyID uint) (*fleet.Policy, error) {\n\t// Auth check uses empty Policy{} \u2014 TeamID is nil\n\tif err := svc.authz.Authorize(ctx, \u0026fleet.Policy{}, fleet.ActionRead); err != nil {\n\t\treturn nil, err\n\t}\n\n\t// Fetches ANY policy by ID, regardless of team ownership\n\tpolicy, err := svc.ds.Policy(ctx, policyID)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\t// ... populates install_software and run_script, returns full policy\n\treturn policy, nil\n}\n```\n\nThe authorization passes because the OPA rule at `server/authz/policy.rego:724-728` allows reading policies with null `team_id` for any user who holds a role on any team:\n\n```rego\nallow {\n  is_null(object.team_id)\n  object.type == \"policy\"\n  team_role(subject, subject.teams[_].id) == [admin, maintainer, technician, observer, observer_plus][_]\n  action == read\n}\n```\n\nSince the auth object has nil TeamID, this rule fires for any team member. After authorization, `ds.Policy()` calls `policyDB()` at `server/datastore/mysql/policies.go:283-288` with a nil teamID:\n\n```go\nfunc policyDB(ctx context.Context, q sqlx.QueryerContext, id uint, teamID *uint) (*fleet.Policy, error) {\n\tteamWhere := \"TRUE\"  // nil teamID \u2192 no team filter\n\targs := []interface{}{id}\n\tif teamID != nil {\n\t\tteamWhere = \"team_id = ?\"\n\t\targs = append(args, *teamID)\n\t}\n\t// ... executes SELECT with WHERE p.id = ? AND {teamWhere}\n```\n\nThis returns any policy regardless of team ownership, and the full policy object is returned to the caller without any post-fetch team verification.\n\nBy contrast, the properly-secured endpoints verify team scope:\n- `GetTeamPolicyByIDQueries` (`team_policies.go:421-428`) sets `TeamID: ptr.Uint(teamID)` on the auth object and calls `ds.TeamPolicy()` which filters by team\n- `DeleteGlobalPolicies` (`global_policies.go:255-263`) explicitly checks `policy.PolicyData.TeamID != nil` after fetching\n\n## PoC\n\nPrerequisites: A Fleet instance with at least two teams. User A has observer role on Team 1 only. Team 2 has policies that User A should not be able to view.\n\n```bash\n# Step 1: Authenticate as User A (Team 1 observer only)\nTOKEN=$(curl -s -X POST https://fleet.example.com/api/latest/fleet/login \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"email\":\"team1observer@example.com\",\"password\":\"password\"}\u0027 | jq -r \u0027.token\u0027)\n\n# Step 2: Enumerate policy IDs (they are sequential integers)\n# Attempt to read a policy belonging to Team 2 (e.g., policy ID 5)\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  https://fleet.example.com/api/latest/fleet/policies/5\n\n# Expected: 403 Forbidden (user has no access to Team 2)\n# Actual: 200 OK with full policy data:\n# {\n#   \"policy\": {\n#     \"id\": 5,\n#     \"name\": \"Team 2 Sensitive Policy\",\n#     \"query\": \"SELECT * FROM sensitive_table WHERE ...\",\n#     \"team_id\": 2,\n#     \"passing_host_count\": 42,\n#     \"failing_host_count\": 7,\n#     \"description\": \"...\",\n#     \"resolution\": \"...\",\n#     ...\n#   }\n# }\n```\n\n## Impact\n\nAn authenticated user with observer-level access on any single team can:\n\n- **Read SQL queries** from all team policies across the Fleet instance, potentially revealing security monitoring strategies, compliance checks, and internal infrastructure details\n- **View host pass/fail counts** for other teams\u0027 policies, leaking compliance posture data across team boundaries\n- **Access software installer and script metadata** associated with other teams\u0027 policies via the `populatePolicyInstallSoftware` and `populatePolicyRunScript` calls\n- **Enumerate all policies** by iterating sequential integer IDs\n\nThis breaks Fleet\u0027s team isolation model, which is designed to restrict visibility between teams. Organizations using teams to separate departments, clients, or security zones would have their policy data exposed across boundaries.\n\n## Recommended Fix\n\nAdd a post-fetch check in `GetPolicyByIDQueries` to verify the returned policy is actually a global policy (nil TeamID), consistent with how `DeleteGlobalPolicies` operates:\n\n```go\nfunc (svc Service) GetPolicyByIDQueries(ctx context.Context, policyID uint) (*fleet.Policy, error) {\n\tif err := svc.authz.Authorize(ctx, \u0026fleet.Policy{}, fleet.ActionRead); err != nil {\n\t\treturn nil, err\n\t}\n\n\tpolicy, err := svc.ds.Policy(ctx, policyID)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\n\t// Verify this is actually a global policy \u2014 team policies must be\n\t// accessed via the team-scoped endpoint which enforces team authorization\n\tif policy.TeamID != nil {\n\t\treturn nil, authz.ForbiddenWithInternal(\n\t\t\t\"attempting to read team policy via global endpoint\",\n\t\t\tauthz.UserFromContext(ctx),\n\t\t\tpolicy,\n\t\t\tfleet.ActionRead,\n\t\t)\n\t}\n\n\tif err := svc.populatePolicyInstallSoftware(ctx, policy); err != nil {\n\t\treturn nil, ctxerr.Wrap(ctx, err, \"populate install_software\")\n\t}\n\tif err := svc.populatePolicyRunScript(ctx, policy); err != nil {\n\t\treturn nil, ctxerr.Wrap(ctx, err, \"populate run_script\")\n\t}\n\n\treturn policy, nil\n}\n```\n\nAlternatively, re-authorize against the actual fetched policy object so OPA rules properly evaluate team membership, similar to how other Fleet endpoints handle object-level authorization.",
  "id": "GHSA-gm7f-v959-fr2g",
  "modified": "2026-06-26T20:30:27Z",
  "published": "2026-06-26T20:30:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fleetdm/fleet/security/advisories/GHSA-gm7f-v959-fr2g"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fleetdm/fleet"
    }
  ],
  "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": "Fleet DM Vulnerable to Cross-Team Policy Data Exposure via Global Policy Read Endpoint"
}

GHSA-GM83-48R5-335W

Vulnerability from github – Published: 2022-12-22 00:30 – Updated: 2022-12-28 21:30
VLAI
Details

Dataprobe iBoot-PDU FW versions prior to 1.42.06162022 contain a vulnerability where unauthenticated users could open PHP index pages without authentication and download the history file from the device; the history file includes the latest actions completed by specific users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-21T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dataprobe iBoot-PDU FW versions prior to 1.42.06162022 contain a vulnerability where unauthenticated users could open PHP index pages without authentication and download the history file from the device; the history file includes the latest actions completed by specific users.",
  "id": "GHSA-gm83-48r5-335w",
  "modified": "2022-12-28T21:30:23Z",
  "published": "2022-12-22T00:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3188"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-263-03"
    }
  ],
  "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-GM85-C692-G62R

Vulnerability from github – Published: 2023-07-27 00:30 – Updated: 2024-04-04 06:22
VLAI
Details

This issue was addressed with improved data protection. This issue is fixed in macOS Monterey 12.6.8, macOS Ventura 13.5, macOS Big Sur 11.7.9. An app may be able to modify protected parts of the file system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-35983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-27T00:15:15Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved data protection. This issue is fixed in macOS Monterey 12.6.8, macOS Ventura 13.5, macOS Big Sur 11.7.9. An app may be able to modify protected parts of the file system.",
  "id": "GHSA-gm85-c692-g62r",
  "modified": "2024-04-04T06:22:29Z",
  "published": "2023-07-27T00:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35983"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213843"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213844"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213845"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GMMX-X25F-3HH3

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-07-16 00:00
VLAI
Details

NVIDIA camera firmware contains a vulnerability where an unauthorized modification by camera resources may result in complete denial of service and loss of partial data integrity for all clients.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-1113"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-11T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA camera firmware contains a vulnerability where an unauthorized modification by camera resources may result in complete denial of service and loss of partial data integrity for all clients.",
  "id": "GHSA-gmmx-x25f-3hh3",
  "modified": "2022-07-16T00:00:22Z",
  "published": "2022-05-24T19:11:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1113"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5216"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GMW7-26J8-4983

Vulnerability from github – Published: 2025-09-16 00:30 – Updated: 2025-11-03 21:34
VLAI
Details

This issue was addressed with improved URL validation. This issue is fixed in Safari 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to unexpected URL redirection.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31254"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T23:15:29Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved URL validation. This issue is fixed in Safari 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to unexpected URL redirection.",
  "id": "GHSA-gmw7-26j8-4983",
  "modified": "2025-11-03T21:34:28Z",
  "published": "2025-09-16T00:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31254"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125108"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125113"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Sep/59"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GP2R-34C8-48XQ

Vulnerability from github – Published: 2024-08-05 09:30 – Updated: 2025-10-22 00:33
VLAI
Details

Incorrect Authorization vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: through 18.12.14.

Users are recommended to upgrade to version 18.12.15, which fixes the issue.

Unauthenticated endpoints could allow execution of screen rendering code of screens if some preconditions are met (such as when the screen definitions don't explicitly check user's permissions because they rely on the configuration of their endpoints).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-05T09:15:56Z",
    "severity": "HIGH"
  },
  "details": "Incorrect Authorization vulnerability in Apache OFBiz.\n\nThis issue affects Apache OFBiz: through 18.12.14.\n\nUsers are recommended to upgrade to version 18.12.15, which fixes the issue.\n\nUnauthenticated endpoints could allow execution of screen rendering code of screens if some preconditions are met (such as when the screen definitions don\u0027t explicitly check user\u0027s permissions because they rely on the configuration of their endpoints).",
  "id": "GHSA-gp2r-34c8-48xq",
  "modified": "2025-10-22T00:33:04Z",
  "published": "2024-08-05T09:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38856"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/OFBIZ-13128"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/olxxjk6b13sl3wh9cmp0k2dscvp24l7w"
    },
    {
      "type": "WEB",
      "url": "https://ofbiz.apache.org/download.html"
    },
    {
      "type": "WEB",
      "url": "https://ofbiz.apache.org/security.html"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-38856"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/08/04/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GP3C-FXMQ-6R3C

Vulnerability from github – Published: 2026-02-08 00:30 – Updated: 2026-02-11 00:30
VLAI
Details

Wekan versions prior to 8.20 allow non-administrative users to access migration functionality due to insufficient permission checks, potentially resulting in unauthorized migration operations.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-25859"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-07T22:16:02Z",
    "severity": "HIGH"
  },
  "details": "Wekan versions prior to 8.20 allow non-administrative users to access migration functionality due to insufficient permission checks, potentially resulting in unauthorized migration operations.",
  "id": "GHSA-gp3c-fxmq-6r3c",
  "modified": "2026-02-11T00:30:14Z",
  "published": "2026-02-08T00:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25859"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wekan/wekan/commit/cbb1cd78de3e40264a5e047ace0ce27f8635b4e6"
    },
    {
      "type": "WEB",
      "url": "https://wekan.fi"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wekan-migration-functionality-insufficient-permission-checks"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GP3Q-WPQ4-5C5H

Vulnerability from github – Published: 2026-03-12 14:21 – Updated: 2026-03-12 14:21
VLAI
Summary
OpenClaw: LINE group allowlist scope mismatch with DM pairing-store entries
Details

Summary

In specific LINE configurations, sender IDs approved through DM pairing could also satisfy group allowlist checks when operators expected group sender access to be scoped only to explicit group allowlists.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published version at triage/update time: 2026.2.25
  • Affected: <= 2026.2.25
  • Patched: >= 2026.2.26 (planned next release)

Impact

This is a group-authorization scope mismatch. DM pairing-store entries could influence group sender authorization in allowlist mode.

Technical Details

Root cause: group allowlist composition inherited pairing-store entries intended for DM approvals. Under default DM pairing policy, a DM-paired sender could match group allowlist checks.

Fixes on main: - isolate group allowlist composition from pairing-store entries - centralize shared DM/group allowlist composition to preserve DM-only pairing behavior - add regression coverage for LINE and Mattermost policy paths

Fix Commit(s)

  • 8bdda7a651c21e98faccdbbd73081e79cffe8be0
  • 892a9c24b0f6118729ab5b5f5499b1a7e792dd15 (follow-up refactor hardening)

Release Process Note

patched_versions is pre-set to >= 2026.2.26 so once npm 2026.2.26 is published, this advisory can be published directly without additional version-field edits.

Thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T14:21:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nIn specific LINE configurations, sender IDs approved through DM pairing could also satisfy group allowlist checks when operators expected group sender access to be scoped only to explicit group allowlists.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published version at triage/update time: `2026.2.25`\n- Affected: `\u003c= 2026.2.25`\n- Patched: `\u003e= 2026.2.26` (planned next release)\n\n### Impact\nThis is a group-authorization scope mismatch. DM pairing-store entries could influence group sender authorization in allowlist mode.\n\n### Technical Details\nRoot cause: group allowlist composition inherited pairing-store entries intended for DM approvals. Under default DM pairing policy, a DM-paired sender could match group allowlist checks.\n\nFixes on `main`:\n- isolate group allowlist composition from pairing-store entries\n- centralize shared DM/group allowlist composition to preserve DM-only pairing behavior\n- add regression coverage for LINE and Mattermost policy paths\n\n### Fix Commit(s)\n- `8bdda7a651c21e98faccdbbd73081e79cffe8be0`\n- `892a9c24b0f6118729ab5b5f5499b1a7e792dd15` (follow-up refactor hardening)\n\n### Release Process Note\n`patched_versions` is pre-set to `\u003e= 2026.2.26` so once npm `2026.2.26` is published, this advisory can be published directly without additional version-field edits.\n\nThanks @tdjackey for reporting.",
  "id": "GHSA-gp3q-wpq4-5c5h",
  "modified": "2026-03-12T14:21:45Z",
  "published": "2026-03-12T14:21:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gp3q-wpq4-5c5h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/892a9c24b0f6118729ab5b5f5499b1a7e792dd15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/8bdda7a651c21e98faccdbbd73081e79cffe8be0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: LINE group allowlist scope mismatch with DM pairing-store entries"
}

GHSA-GP4X-Q6RM-QP9M

Vulnerability from github – Published: 2024-10-15 21:30 – Updated: 2024-10-15 21:30
VLAI
Details

Vulnerability in the Oracle Banking Liquidity Management product of Oracle Financial Services Applications (component: Reports). The supported version that is affected is 14.5.0.12.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Banking Liquidity Management. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle Banking Liquidity Management. CVSS 3.1 Base Score 7.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-15T20:15:21Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle Banking Liquidity Management product of Oracle Financial Services Applications (component: Reports).   The supported version that is affected is 14.5.0.12.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Banking Liquidity Management.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle Banking Liquidity Management. CVSS 3.1 Base Score 7.1 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H).",
  "id": "GHSA-gp4x-q6rm-qp9m",
  "modified": "2024-10-15T21:30:39Z",
  "published": "2024-10-15T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21285"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2024.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GP5G-VM23-75FQ

Vulnerability from github – Published: 2022-08-12 00:01 – Updated: 2022-08-19 00:00
VLAI
Details

Zoom On-Premise Meeting Connector MMR before version 4.8.129.20220714 contains an improper access control vulnerability. As a result, a malicious actor can join a meeting which they are authorized to join without appearing to the other participants, can admit themselves into the meeting from the waiting room, and can become host and cause other meeting disruptions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-28754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-11T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Zoom On-Premise Meeting Connector MMR before version 4.8.129.20220714 contains an improper access control vulnerability. As a result, a malicious actor can join a meeting which they are authorized to join without appearing to the other participants, can admit themselves into the meeting from the waiting room, and can become host and cause other meeting disruptions.",
  "id": "GHSA-gp5g-vm23-75fq",
  "modified": "2022-08-19T00:00:21Z",
  "published": "2022-08-12T00:01:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28754"
    },
    {
      "type": "WEB",
      "url": "https://explore.zoom.us/en/trust/security/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/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.

No CAPEC attack patterns related to this CWE.