Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

5548 vulnerabilities reference this CWE, most recent first.

GHSA-39G2-8X68-PMX8

Vulnerability from github – Published: 2026-06-26 23:02 – Updated: 2026-06-26 23:02
VLAI
Summary
Nezha Monitoring: Stored future DDNS profile ID allows unauthorized use of another user's DDNS profile context
Details

Summary

PATCH /server/{id} accepts and persists nonexistent ddns_profiles IDs for a member-owned server. If another user later creates a DDNS profile with one of those IDs, the DDNS worker resolves the stored ID and dispatches an update using the other user's DDNS profile configuration in the context of the attacker's server.

This is a second-order authorization bypass: direct binding to an existing foreign DDNS profile is correctly denied, but an unresolved future ID can be stored first and later becomes a live cross-user reference.

Affected versions

Confirmed on:

  • Nezha v2.0.14
  • Commit: 8b5e382fe217107c7b777ea9c6b4bc3d2e156202

The exact affected version range was not determined.

Impact

A normal member who owns a server can prebind one or more future DDNS profile IDs to that server. If another user later creates a DDNS profile with a matching ID, the dashboard DDNS worker can use the victim's DDNS profile/provider configuration for the attacker's server.

In the validated worker path, the dispatched DDNS update combines:

  • the victim DDNS profile ID and owner
  • the victim profile's provider type
  • victim profile fields such as domains, access ID, access secret, and retry policy
  • attacker server context, including the attacker's server ID, owner, IPv4 address, and override DDNS domains

This can result in unauthorized DDNS update attempts using another user's DDNS profile context. The attacker does not need permission to bind the victim profile after it exists.

The following were not validated: credential disclosure, account takeover, or guaranteed external DNS modification across all providers. The credentials remain server-side in the worker path. The downstream DNS impact depends on the victim profile's provider configuration and what that provider account is authorized to update.

Affected components

  • PATCH /server/{id}
  • cmd/dashboard/controller/server.go
  • service/singleton/singleton.go
  • service/singleton/ddns.go
  • service/singleton/server.go
  • pkg/ddns/ddns.go

Root cause

The server update path validates submitted DDNS profile IDs through CheckPermission, but that check only rejects existing objects owned by another user. Nonexistent IDs are skipped.

The updateServer path then persists the submitted raw IDs into DDNSProfilesRaw, along with override domain data. Later, the DDNS worker resolves the stored profile IDs by ID and dispatches provider updates without revalidating that the resolved profiles belong to the server owner.

As a result, an invalid unresolved reference can become a valid cross-user reference after another user creates a DDNS profile with the same global auto-increment ID.

Reproduction summary

The behavior was validated locally with focused regression tests.

Controller chain proof

Test file:

cmd/dashboard/controller/ddns_second_order_test.go

Test name:

TestUpdateServerAllowsFutureDDNSProfileBindingThenResolvesVictimProfile

Command:

go test ./cmd/dashboard/controller -run TestUpdateServerAllowsFutureDDNSProfileBindingThenResolvesVictimProfile -count=1

Result:

pass

The test demonstrates:

  1. A normal member owns server 1.
  2. DDNS profile ID 1 does not exist.
  3. The member updates their server with enable_ddns=true and ddns_profiles=[1].
  4. The request succeeds.
  5. The server persists DDNSProfiles=[1].
  6. Another user later creates a DDNS profile and receives ID 1.
  7. A fresh attempt by the attacker to bind profile 1 is correctly denied.
  8. The previously stored reference remains active and resolves in the DDNS worker path.

Provider-level worker proof

Test file:

service/singleton/ddns_worker_authz_test.go

Test name:

TestUpdateDDNSDispatchesVictimProfileForAttackerServer

Command:

go test ./service/singleton -run TestUpdateDDNSDispatchesVictimProfileForAttackerServer -count=1

Result:

pass

The test proves that the DDNS worker does not merely resolve the victim profile. It dispatches a DDNS update using the victim profile configuration and attacker server context.

Validated assertions include:

  • resolved profile ID is 1
  • resolved profile owner is victim user 200
  • processed server is attacker server 1 owned by user 100
  • provider type is the victim profile's provider
  • victim profile fields are present in worker dispatch:
  • domains
  • access ID
  • access secret
  • max retries
  • attacker server context is present in the same dispatch:
  • IPv4 198.51.100.44
  • attacker-controlled override domains are passed to the worker:
  • attacker-controlled.example

Practicality

The attack requires predicting or prebinding future DDNS profile IDs. This limits severity, but does not remove the authorization issue.

Evidence supporting practicality:

  • DDNS profile IDs are uint64 GORM primary keys from model/common.go.
  • createDDNS uses a normal DB.Create(&p) flow and returns p.ID.
  • DDNSProfiles is an unbounded []uint64 in model/server_api.go.
  • No length or existence validation is applied in updateServer.
  • Invalid/future IDs are preserved in the server record.
  • Stored unresolved IDs survive reload.
  • Range prebinding was validated with [1,2,3,4].
  • The DDNS worker consumes stored IDs on future DDNS update events.
  • Worker dispatch can occur after server edit and agent IP-change events.
  • Each DDNS update can retry according to the victim profile's MaxRetries.

This makes the issue semi-practical: exploitation depends on future ID prediction or range prebinding, but the unresolved IDs persist and can become active later.

Expected behavior

PATCH /server/{id} should reject any submitted DDNS profile ID that does not both:

  1. exist, and
  2. belong to the caller or the owner of the server being updated.

The DDNS worker should also avoid trusting stored profile IDs without revalidating ownership before provider resolution or dispatch.

Actual behavior

PATCH /server/{id} accepts nonexistent DDNS profile IDs and persists them. If another user later creates a DDNS profile with a matching ID, the stored reference resolves to that user's profile and is consumed by the DDNS worker for the attacker's server.

Suggested remediation

Apply both bind-time and worker-time validation.

At bind time:

  • Reject nonexistent DDNS profile IDs.
  • Reject DDNS profile IDs that do not belong to the caller/server owner.
  • Reject or limit excessive DDNS profile ID lists if range prebinding is not intended.

At worker time:

  • Revalidate that every resolved DDNS profile still belongs to the owner of the server being processed.
  • Skip or remove stale, nonexistent, or foreign DDNS profile references before provider dispatch.

Suggested regression tests:

  • TestUpdateServerRejectsNonexistentDDNSProfileIDs
  • TestUpdateServerRejectsForeignDDNSProfileIDs
  • TestUpdateServerAcceptsOwnedDDNSProfileIDs
  • TestUpdateDDNSSkipsStaleOrForeignStoredDDNSProfiles

Security relevance

A direct bind to an existing foreign DDNS profile is already denied, which shows the intended ownership boundary. The issue is that the same boundary can be bypassed by storing a future unresolved ID before the victim profile exists.

The worker later treats the stored ID as trusted and dispatches a DDNS update using the victim profile's provider configuration with attacker server context. This is an authorization issue in a deferred worker path, not merely malformed input.

Limitations

  • The attacker does not read victim DDNS credentials through the validated path.
  • Exploitation may require predicting or prebinding future global auto-increment DDNS profile IDs.
  • The downstream DNS impact depends on the victim profile's provider configuration.
  • External DNS modification was not claimed as guaranteed across all providers.
Severity
6.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.14"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:02:37Z",
    "nvd_published_at": "2026-06-12T22:16:52Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`PATCH /server/{id}` accepts and persists nonexistent `ddns_profiles` IDs for a member-owned server. If another user later creates a DDNS profile with one of those IDs, the DDNS worker resolves the stored ID and dispatches an update using the other user\u0027s DDNS profile configuration in the context of the attacker\u0027s server.\n\nThis is a second-order authorization bypass: direct binding to an existing foreign DDNS profile is correctly denied, but an unresolved future ID can be stored first and later becomes a live cross-user reference.\n\n## Affected versions\n\nConfirmed on:\n\n- Nezha `v2.0.14`\n- Commit: `8b5e382fe217107c7b777ea9c6b4bc3d2e156202`\n\nThe exact affected version range was not determined.\n\n## Impact\n\nA normal member who owns a server can prebind one or more future DDNS profile IDs to that server. If another user later creates a DDNS profile with a matching ID, the dashboard DDNS worker can use the victim\u0027s DDNS profile/provider configuration for the attacker\u0027s server.\n\nIn the validated worker path, the dispatched DDNS update combines:\n\n- the victim DDNS profile ID and owner\n- the victim profile\u0027s provider type\n- victim profile fields such as domains, access ID, access secret, and retry policy\n- attacker server context, including the attacker\u0027s server ID, owner, IPv4 address, and override DDNS domains\n\nThis can result in unauthorized DDNS update attempts using another user\u0027s DDNS profile context. The attacker does not need permission to bind the victim profile after it exists.\n\nThe following were not validated: credential disclosure, account takeover, or guaranteed external DNS modification across all providers. The credentials remain server-side in the worker path. The downstream DNS impact depends on the victim profile\u0027s provider configuration and what that provider account is authorized to update.\n\n## Affected components\n\n- `PATCH /server/{id}`\n- `cmd/dashboard/controller/server.go`\n- `service/singleton/singleton.go`\n- `service/singleton/ddns.go`\n- `service/singleton/server.go`\n- `pkg/ddns/ddns.go`\n\n## Root cause\n\nThe server update path validates submitted DDNS profile IDs through `CheckPermission`, but that check only rejects existing objects owned by another user. Nonexistent IDs are skipped.\n\nThe `updateServer` path then persists the submitted raw IDs into `DDNSProfilesRaw`, along with override domain data. Later, the DDNS worker resolves the stored profile IDs by ID and dispatches provider updates without revalidating that the resolved profiles belong to the server owner.\n\nAs a result, an invalid unresolved reference can become a valid cross-user reference after another user creates a DDNS profile with the same global auto-increment ID.\n\n## Reproduction summary\n\nThe behavior was validated locally with focused regression tests.\n\n### Controller chain proof\n\nTest file:\n\n`cmd/dashboard/controller/ddns_second_order_test.go`\n\nTest name:\n\n`TestUpdateServerAllowsFutureDDNSProfileBindingThenResolvesVictimProfile`\n\nCommand:\n\n```bash\ngo test ./cmd/dashboard/controller -run TestUpdateServerAllowsFutureDDNSProfileBindingThenResolvesVictimProfile -count=1\n```\n\nResult:\n\n`pass`\n\nThe test demonstrates:\n\n1. A normal member owns server `1`.\n2. DDNS profile ID `1` does not exist.\n3. The member updates their server with `enable_ddns=true` and `ddns_profiles=[1]`.\n4. The request succeeds.\n5. The server persists `DDNSProfiles=[1]`.\n6. Another user later creates a DDNS profile and receives ID `1`.\n7. A fresh attempt by the attacker to bind profile `1` is correctly denied.\n8. The previously stored reference remains active and resolves in the DDNS worker path.\n\n### Provider-level worker proof\n\nTest file:\n\n`service/singleton/ddns_worker_authz_test.go`\n\nTest name:\n\n`TestUpdateDDNSDispatchesVictimProfileForAttackerServer`\n\nCommand:\n\n```bash\ngo test ./service/singleton -run TestUpdateDDNSDispatchesVictimProfileForAttackerServer -count=1\n```\n\nResult:\n\n`pass`\n\nThe test proves that the DDNS worker does not merely resolve the victim profile. It dispatches a DDNS update using the victim profile configuration and attacker server context.\n\nValidated assertions include:\n\n- resolved profile ID is `1`\n- resolved profile owner is victim user `200`\n- processed server is attacker server `1` owned by user `100`\n- provider type is the victim profile\u0027s provider\n- victim profile fields are present in worker dispatch:\n  - domains\n  - access ID\n  - access secret\n  - max retries\n- attacker server context is present in the same dispatch:\n  - IPv4 `198.51.100.44`\n- attacker-controlled override domains are passed to the worker:\n  - `attacker-controlled.example`\n\n## Practicality\n\nThe attack requires predicting or prebinding future DDNS profile IDs. This limits severity, but does not remove the authorization issue.\n\nEvidence supporting practicality:\n\n- DDNS profile IDs are `uint64` GORM primary keys from `model/common.go`.\n- `createDDNS` uses a normal `DB.Create(\u0026p)` flow and returns `p.ID`.\n- `DDNSProfiles` is an unbounded `[]uint64` in `model/server_api.go`.\n- No length or existence validation is applied in `updateServer`.\n- Invalid/future IDs are preserved in the server record.\n- Stored unresolved IDs survive reload.\n- Range prebinding was validated with `[1,2,3,4]`.\n- The DDNS worker consumes stored IDs on future DDNS update events.\n- Worker dispatch can occur after server edit and agent IP-change events.\n- Each DDNS update can retry according to the victim profile\u0027s `MaxRetries`.\n\nThis makes the issue semi-practical: exploitation depends on future ID prediction or range prebinding, but the unresolved IDs persist and can become active later.\n\n## Expected behavior\n\n`PATCH /server/{id}` should reject any submitted DDNS profile ID that does not both:\n\n1. exist, and\n2. belong to the caller or the owner of the server being updated.\n\nThe DDNS worker should also avoid trusting stored profile IDs without revalidating ownership before provider resolution or dispatch.\n\n## Actual behavior\n\n`PATCH /server/{id}` accepts nonexistent DDNS profile IDs and persists them. If another user later creates a DDNS profile with a matching ID, the stored reference resolves to that user\u0027s profile and is consumed by the DDNS worker for the attacker\u0027s server.\n\n## Suggested remediation\n\nApply both bind-time and worker-time validation.\n\nAt bind time:\n\n- Reject nonexistent DDNS profile IDs.\n- Reject DDNS profile IDs that do not belong to the caller/server owner.\n- Reject or limit excessive DDNS profile ID lists if range prebinding is not intended.\n\nAt worker time:\n\n- Revalidate that every resolved DDNS profile still belongs to the owner of the server being processed.\n- Skip or remove stale, nonexistent, or foreign DDNS profile references before provider dispatch.\n\nSuggested regression tests:\n\n- `TestUpdateServerRejectsNonexistentDDNSProfileIDs`\n- `TestUpdateServerRejectsForeignDDNSProfileIDs`\n- `TestUpdateServerAcceptsOwnedDDNSProfileIDs`\n- `TestUpdateDDNSSkipsStaleOrForeignStoredDDNSProfiles`\n\n## Security relevance\n\nA direct bind to an existing foreign DDNS profile is already denied, which shows the intended ownership boundary. The issue is that the same boundary can be bypassed by storing a future unresolved ID before the victim profile exists.\n\nThe worker later treats the stored ID as trusted and dispatches a DDNS update using the victim profile\u0027s provider configuration with attacker server context. This is an authorization issue in a deferred worker path, not merely malformed input.\n\n## Limitations\n\n- The attacker does not read victim DDNS credentials through the validated path.\n- Exploitation may require predicting or prebinding future global auto-increment DDNS profile IDs.\n- The downstream DNS impact depends on the victim profile\u0027s provider configuration.\n- External DNS modification was not claimed as guaranteed across all providers.",
  "id": "GHSA-39g2-8x68-pmx8",
  "modified": "2026-06-26T23:02:37Z",
  "published": "2026-06-26T23:02:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-39g2-8x68-pmx8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53521"
    },
    {
      "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:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nezha Monitoring: Stored future DDNS profile ID allows unauthorized use of another user\u0027s DDNS profile context"
}

GHSA-3C6H-G97W-FG78

Vulnerability from github – Published: 2026-03-03 21:41 – Updated: 2026-03-11 20:38
VLAI
Summary
OpenClaw's tools.exec.safeBins sort long-option abbreviation bypass can skip exec approval in allowlist mode
Details

Summary

In OpenClaw, tools.exec.safeBins validation for sort could be bypassed via GNU long-option abbreviations in allowlist mode, allowing approval-free execution paths that should require approval.

Affected Packages / Versions

  • Ecosystem: npm
  • Package: openclaw
  • Latest published version checked: 2026.2.22-2
  • Affected range: <= 2026.2.22-2
  • Fixed version: 2026.2.23

Impact

When all of the following are true: - tools.exec.security=allowlist - tools.exec.ask=on-miss - tools.exec.safeBins includes sort

abbreviated GNU long options (for example --compress-prog) could bypass denied-flag checks and be treated as allowlist-satisfied safe-bin usage, skipping approval.

Root Cause

Long-option handling matched denied flags by exact string and accepted unknown long options with inline values instead of failing closed.

Fix Commit(s)

  • 3b8e33037ae2e12af7beb56fcf0346f1f8cbde6f

Release Process Note

patched_versions is pre-set to the released version (2026.2.23). This advisory now reflects released fix version 2026.2.23.

OpenClaw thanks @tdjackey for reporting.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32059"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T21:41:59Z",
    "nvd_published_at": "2026-03-11T14:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIn OpenClaw, `tools.exec.safeBins` validation for `sort` could be bypassed via GNU long-option abbreviations in allowlist mode, allowing approval-free execution paths that should require approval.\n\n### Affected Packages / Versions\n- Ecosystem: npm\n- Package: `openclaw`\n- Latest published version checked: `2026.2.22-2`\n- Affected range: `\u003c= 2026.2.22-2`\n- Fixed version: `2026.2.23`\n\n### Impact\nWhen all of the following are true:\n- `tools.exec.security=allowlist`\n- `tools.exec.ask=on-miss`\n- `tools.exec.safeBins` includes `sort`\n\nabbreviated GNU long options (for example `--compress-prog`) could bypass denied-flag checks and be treated as allowlist-satisfied safe-bin usage, skipping approval.\n\n### Root Cause\nLong-option handling matched denied flags by exact string and accepted unknown long options with inline values instead of failing closed.\n\n### Fix Commit(s)\n- `3b8e33037ae2e12af7beb56fcf0346f1f8cbde6f`\n\n### Release Process Note\n`patched_versions` is pre-set to the released version (`2026.2.23`). This advisory now reflects released fix version `2026.2.23`.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-3c6h-g97w-fg78",
  "modified": "2026-03-11T20:38:42Z",
  "published": "2026-03-03T21:41:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3c6h-g97w-fg78"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32059"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/3b8e33037ae2e12af7beb56fcf0346f1f8cbde6f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-sort-long-option-abbreviation-in-toolsexecsafebins"
    }
  ],
  "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:H/VI:H/VA:H/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"
    }
  ],
  "summary": "OpenClaw\u0027s tools.exec.safeBins sort long-option abbreviation bypass can skip exec approval in allowlist mode"
}

GHSA-3C6J-HQ33-3JV4

Vulnerability from github – Published: 2026-07-02 17:12 – Updated: 2026-07-02 17:12
VLAI
Summary
OpenClaw: Paired nodes could forge exec lifecycle events without system.run provenance
Details

Summary

OpenClaw nodes send lifecycle events back to the gateway. In affected releases, a paired node could send an exec lifecycle event that was accepted without enough provenance tying it to an authorized system.run request.

This issue affects the node event boundary. It does not allow an unauthenticated caller to reach the gateway; the attacker must already control a paired node connection.

Affected configurations

This affects deployments with a paired node where that node can send crafted node.event messages to the gateway and the target agent/session can process exec lifecycle events.

Impact

A malicious or compromised paired node could make the gateway treat attacker-supplied event data as an exec lifecycle result. In the vulnerable flow, that could steer the target session into an exec-event path that exposed capabilities the reduced node surface should not have provided.

The issue is a missing provenance check for node-originated lifecycle events.

Patched Versions

The first stable patched version is 2026.5.18.

Mitigations

Upgrade to openclaw@2026.5.18 or later. Pair nodes only from trusted environments, and remove/re-pair nodes that may have been compromised.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53816"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T17:12:03Z",
    "nvd_published_at": "2026-06-11T21:16:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nOpenClaw nodes send lifecycle events back to the gateway. In affected releases, a paired node could send an exec lifecycle event that was accepted without enough provenance tying it to an authorized `system.run` request.\n\nThis issue affects the node event boundary. It does not allow an unauthenticated caller to reach the gateway; the attacker must already control a paired node connection.\n\n### Affected configurations\n\nThis affects deployments with a paired node where that node can send crafted `node.event` messages to the gateway and the target agent/session can process exec lifecycle events.\n\n### Impact\n\nA malicious or compromised paired node could make the gateway treat attacker-supplied event data as an exec lifecycle result. In the vulnerable flow, that could steer the target session into an exec-event path that exposed capabilities the reduced node surface should not have provided.\n\nThe issue is a missing provenance check for node-originated lifecycle events.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.18`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.18` or later. Pair nodes only from trusted environments, and remove/re-pair nodes that may have been compromised.",
  "id": "GHSA-3c6j-hq33-3jv4",
  "modified": "2026-07-02T17:12:03Z",
  "published": "2026-07-02T17:12:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3c6j-hq33-3jv4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53816"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-exec-lifecycle-event-forgery-via-paired-node"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Paired nodes could forge exec lifecycle events without system.run provenance"
}

GHSA-3C7P-VV5R-CMR5

Vulnerability from github – Published: 2022-02-10 00:31 – Updated: 2025-03-17 21:39
VLAI
Summary
Incorrect Authorization in Apache Solr
Details

Apache Solr versions 6.6.0 to 6.6.6, 7.0.0 to 7.7.3 and 8.0.0 to 8.6.2 prevents some features considered dangerous (which could be used for remote code execution) to be configured in a ConfigSet that's uploaded via API without authentication/authorization. The checks in place to prevent such features can be circumvented by using a combination of UPLOAD/CREATE actions. This issue is patched in 8.6.3.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.solr:solr-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0"
            },
            {
              "fixed": "8.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.solr:solr-solrj"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0"
            },
            {
              "fixed": "8.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.solr:solr-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0"
            },
            {
              "fixed": "8.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-13957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-14T17:55:51Z",
    "nvd_published_at": "2020-10-13T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Apache Solr versions 6.6.0 to 6.6.6, 7.0.0 to 7.7.3 and 8.0.0 to 8.6.2 prevents some features considered dangerous (which could be used for remote code execution) to be configured in a ConfigSet that\u0027s uploaded via API without authentication/authorization. The checks in place to prevent such features can be circumvented by using a combination of UPLOAD/CREATE actions. This issue is patched in 8.6.3.",
  "id": "GHSA-3c7p-vv5r-cmr5",
  "modified": "2025-03-17T21:39:03Z",
  "published": "2022-02-10T00:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13957"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/solr/commit/e001c2221812a0ba9e9378855040ce72f93eced4"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201023-0002"
    },
    {
      "type": "WEB",
      "url": "https://mail-archives.us.apache.org/mod_mbox/www-announce/202010.mbox/%3CCAECwjAWCVLoVaZy%3DTNRQ6Wk9KWVxdPRiGS8NT%2BPHMJCxbbsEVg%40mail.gmail.com%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf1a32f00017e83ff29a74be2de02e28e4302dddb5f14c624e297a8c0@%3Cdev.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb2f1c7fd3d3ea719dfac4706a80e6affddecae8663dda04e1335347f@%3Ccommits.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb1de6ba50a468e9baff32a249edaa08f6bcec7dd7cc208e25e6b48c8@%3Cissues.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9d7356f209ee30d702b6a921c866564eb2e291b126640c7ab70feea7@%3Ccommits.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r999f828e6e37d9e825e207471cbfd2681c3befcd7f3abd59ed87c0d5@%3Cissues.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8b1782d42d0a4ce573495d5d9345ad328d652c68c411ccdb245c57e3@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r853fdc6d0b91d5e01a26c7bd5becb044ad775a231703d634ca5d55c9@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7512ae552cd9d14ab8b1bc0a7e95f2ec52ae85364f068d4034398ede@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r622a043c2890327f8a4aea16b131e8a7137a282a004614369fceb224@%3Cdev.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5557641fcf5cfd99260a7037cfbc8788fb546b72c98a900570edaa2e@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4ca8ba5980d9049cf3707798aa3116ee76c1582f171ff452ad2ca75e@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3da9895cea476bcee2557531bebd4e8f6f367dc3ea900a65e2f51cd8@%3Cissues.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3d1e24a73e6bffa1d6534e1f34c8f5cbd9999495e7d933640f4fa0ed@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2f8d33a4de07db9459fb2a98a1cd39747066137636b53f84a13e5628@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2a6600fe9afd502c04d26fd112823ec3f3c3ad1b4a289d10567a78a0@%3Cdev.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r226c1112bb41e7cd427862d875eff9877a20a40242c2542f4dd39e4a@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2236fdf99ac3efbfc36c2df96d3a88f822baa6f45e13fec7ff558e34@%3Cdev.bigtop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1d4a247329a8478073163567bbc8c8cb6b49c6bfc2bf58153a857af1@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1c783d3d81ba62f3381a17a4d6c826f7dead3a132ba42349c90df075@%3Ccommits.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r13a728994c60be5b5a7049282b5c926dac1fc6a9a0b2362f6adfa573@%3Cissues.lucene.apache.org%3E"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/lucene-solr"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in Apache Solr"
}

GHSA-3C8C-VCMC-G2H3

Vulnerability from github – Published: 2022-12-12 03:31 – Updated: 2022-12-14 15:30
VLAI
Details

SENS v1.0 is vulnerable to Incorrect Access Control vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-45760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-12T03:15:00Z",
    "severity": "HIGH"
  },
  "details": "SENS v1.0 is vulnerable to Incorrect Access Control vulnerability.",
  "id": "GHSA-3c8c-vcmc-g2h3",
  "modified": "2022-12-14T15:30:18Z",
  "published": "2022-12-12T03:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45760"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saysky/SENS/issues/21"
    }
  ],
  "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"
    }
  ]
}

GHSA-3CFW-2RV8-9RX3

Vulnerability from github – Published: 2022-07-18 00:00 – Updated: 2022-07-23 00:00
VLAI
Details

An issue was discovered in Poly EagleEye Director II before 2.2.2.1. Existence of a certain file (which can be created via an rsync backdoor) causes all API calls to execute as admin without authentication.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-26479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-17T23:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Poly EagleEye Director II before 2.2.2.1. Existence of a certain file (which can be created via an rsync backdoor) causes all API calls to execute as admin without authentication.",
  "id": "GHSA-3cfw-2rv8-9rx3",
  "modified": "2022-07-23T00:00:23Z",
  "published": "2022-07-18T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26479"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/de/vulnerability-lab/advisory/poly-eagleeye-director-ii-kritische-schwachstellen"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/vulnerability-lab/advisory/critical-vulnerabilities-poly-eagleeye-director-ii"
    },
    {
      "type": "WEB",
      "url": "https://www.poly.com/us/en/support/security-center"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3CG7-X7VX-225C

Vulnerability from github – Published: 2025-03-13 06:30 – Updated: 2025-03-13 06:30
VLAI
Details

An issue has been discovered in GitLab EE/CE affecting all versions starting from 16.9 before 17.7.7, all versions starting from 17.8 before 17.8.5, all versions starting from 17.9 before 17.9.2 could allow unauthorized users to access confidential information intended for internal use only.

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-0652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-13T06:15:36Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab EE/CE affecting all versions starting from 16.9 before 17.7.7, all versions starting from 17.8 before 17.8.5, all versions starting from 17.9 before 17.9.2 could allow unauthorized users to access confidential information intended for internal use only.",
  "id": "GHSA-3cg7-x7vx-225c",
  "modified": "2025-03-13T06:30:35Z",
  "published": "2025-03-13T06:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0652"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2947863"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/514532"
    }
  ],
  "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-3CJF-FWCQ-XH22

Vulnerability from github – Published: 2025-02-04 12:30 – Updated: 2025-02-18 22:31
VLAI
Summary
Apache Cassandra: CassandraNetworkAuthorizer and CassandraCIDRAuthorizer can be bypassed allowing access to different network regions
Details

Incorrect Authorization vulnerability in Apache Cassandra allowing users to access a datacenter or IP/CIDR groups they should not be able to when using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer.

Users with restricted data center access can update their own permissions via data control language (DCL) statements on affected versions.

This issue affects Apache Cassandra: from 4.0.0 through 4.0.15 and from 4.1.0 through 4.1.7 for CassandraNetworkAuthorizer, and from 5.0.0 through 5.0.2 for both CassandraNetworkAuthorizer and CassandraCIDRAuthorizer.

Operators using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer on affected versions should review data access rules for potential breaches. Users are recommended to upgrade to versions 4.0.16, 4.1.8, 5.0.3, which fixes the issue.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/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.apache.cassandra:cassandra-all"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0-alpha1"
            },
            {
              "fixed": "4.0.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.cassandra:cassandra-all"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1-alpha1"
            },
            {
              "fixed": "4.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.cassandra:cassandra-all"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0-alpha1"
            },
            {
              "fixed": "5.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24860"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-04T18:39:39Z",
    "nvd_published_at": "2025-02-04T11:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in Apache Cassandra allowing users to access a datacenter or IP/CIDR groups they should not be able to when using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer. \n\nUsers with restricted data center access can update their own permissions via data control language (DCL) statements on affected versions.\n\nThis issue affects Apache Cassandra: from 4.0.0 through 4.0.15 and from 4.1.0 through 4.1.7 for CassandraNetworkAuthorizer, and from 5.0.0 through 5.0.2 for both CassandraNetworkAuthorizer and CassandraCIDRAuthorizer.\n\nOperators using\u00a0CassandraNetworkAuthorizer or\u00a0CassandraCIDRAuthorizer on affected versions should review data access rules for potential breaches. Users are recommended to upgrade to versions 4.0.16, 4.1.8, 5.0.3, which fixes the issue.",
  "id": "GHSA-3cjf-fwcq-xh22",
  "modified": "2025-02-18T22:31:50Z",
  "published": "2025-02-04T12:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24860"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/cassandra"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/yjo5on4tf7s1r9qklc4byrz30b8vkm2d"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250214-0005"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/02/03/3"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache Cassandra: CassandraNetworkAuthorizer and CassandraCIDRAuthorizer can be bypassed allowing access to different network regions"
}

GHSA-3CJP-47JV-9RH2

Vulnerability from github – Published: 2026-01-15 15:31 – Updated: 2026-01-15 15:31
VLAI
Details

Certain system functions may be accessed without proper authorization, allowing attackers to start, stop, or delete installed applications, potentially disrupting system operations.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-22909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-15T13:16:05Z",
    "severity": "HIGH"
  },
  "details": "Certain system functions may be accessed without proper authorization, allowing attackers to start, stop, or delete installed applications, potentially disrupting system operations.",
  "id": "GHSA-3cjp-47jv-9rh2",
  "modified": "2026-01-15T15:31:18Z",
  "published": "2026-01-15T15:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22909"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/resources-tools/resources/ics-recommended-practices"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/3.1"
    },
    {
      "type": "WEB",
      "url": "https://www.sick.com/.well-known/csaf/white/2026/sca-2026-0001.json"
    },
    {
      "type": "WEB",
      "url": "https://www.sick.com/.well-known/csaf/white/2026/sca-2026-0001.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.sick.com/media/docs/9/19/719/special_information_sick_operating_guidelines_cybersecurity_by_sick_en_im0106719.pdf"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3CM3-9CCJ-7MVQ

Vulnerability from github – Published: 2021-12-14 00:00 – Updated: 2021-12-16 00:02
VLAI
Details

Improper access control in the GitLab CE/EE API affecting all versions starting from 9.4 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allows an author of a Merge Request to approve the Merge Request even after having their project access revoked

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-39945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-13T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper access control in the GitLab CE/EE API affecting all versions starting from 9.4 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allows an author of a Merge Request to approve the Merge Request even after having their project access revoked",
  "id": "GHSA-3cm3-9ccj-7mvq",
  "modified": "2021-12-16T00:02:44Z",
  "published": "2021-12-14T00:00:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39945"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1198317"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-39945.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/331675"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
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.

← Back to the CWE list