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.

6282 vulnerabilities reference this CWE, most recent first.

GHSA-XHMM-6XR8-JX92

Vulnerability from github – Published: 2025-08-28 15:30 – Updated: 2025-08-28 15:30
VLAI
Details

The Block Bad Bots and Stop Bad Bots Crawlers and Spiders and Anti Spam Protection plugin for WordPress is vulnerable to unauthorized access of data due to an insufficient capability check on the 'stopbadbots_check_wordpress_logged_in_cookie' function in all versions up to, and including, 11.58. This makes it possible for unauthenticated attackers to bypass blocklists, rate limits, and other plugin functionality.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-9376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-28T12:15:39Z",
    "severity": "MODERATE"
  },
  "details": "The Block Bad Bots and Stop Bad Bots Crawlers and Spiders and Anti Spam Protection plugin for WordPress is vulnerable to unauthorized access of data due to an insufficient capability check on the \u0027stopbadbots_check_wordpress_logged_in_cookie\u0027 function in all versions up to, and including, 11.58. This makes it possible for unauthenticated attackers to bypass blocklists, rate limits, and other plugin functionality.",
  "id": "GHSA-xhmm-6xr8-jx92",
  "modified": "2025-08-28T15:30:40Z",
  "published": "2025-08-28T15:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9376"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/stopbadbots/trunk/stopbadbots.php#L1958"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3350927"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3351023"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8d6b0d86-3cb4-4723-b677-141c604f00cc?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XHQ5-45PM-2GJR

Vulnerability from github – Published: 2026-03-26 21:34 – Updated: 2026-04-18 00:56
VLAI
Summary
OpenClaw: Nextcloud Talk room allowlist matched colliding room names instead of stable room tokens
Details

Summary

Nextcloud Talk room authorization matched on collidable room names instead of the stable room token, allowing policy confusion across similarly named rooms.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: < 2026.3.22
  • Fixed: >= 2026.3.22
  • Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87)
  • Latest published npm version checked: 2026.3.23-2

Fix Commit(s)

  • a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66

Release Status

The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.

Code-Level Confirmation

  • extensions/nextcloud-talk/src/inbound.ts now resolves allowlist policy from roomToken-backed room identity.
  • extensions/nextcloud-talk/src/policy.ts now keys room authorization on stable room tokens instead of display names.

OpenClaw thanks @zpbrent for reporting.

Severity
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/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.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-807",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T21:34:18Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\nNextcloud Talk room authorization matched on collidable room names instead of the stable room token, allowing policy confusion across similarly named rooms.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: \u003c 2026.3.22\n- Fixed: \u003e= 2026.3.22\n- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)\n- Latest published npm version checked: `2026.3.23-2`\n\n## Fix Commit(s)\n- `a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66`\n\n## Release Status\nThe fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.\n\n## Code-Level Confirmation\n- extensions/nextcloud-talk/src/inbound.ts now resolves allowlist policy from roomToken-backed room identity.\n- extensions/nextcloud-talk/src/policy.ts now keys room authorization on stable room tokens instead of display names.\n\nOpenClaw thanks @zpbrent for reporting.",
  "id": "GHSA-xhq5-45pm-2gjr",
  "modified": "2026-04-18T00:56:28Z",
  "published": "2026-03-26T21:34:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xhq5-45pm-2gjr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35624"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-policy-confusion-via-room-name-collision-in-nextcloud-talk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Nextcloud Talk room allowlist matched colliding room names instead of stable room tokens"
}

GHSA-XHQ9-58FW-859P

Vulnerability from github – Published: 2026-04-16 20:42 – Updated: 2026-04-16 20:42
VLAI
Summary
ApostropheCMS: publicApiProjection Bypass via project Query Builder in Piece-Type REST API
Details

Summary

The getRestQuery method in the @apostrophecms/piece-type module checks whether a MongoDB projection has already been set before applying the admin-configured publicApiProjection. An unauthenticated attacker can supply a project query parameter in the REST API request to pre-populate the projection state, causing the security-enforced publicApiProjection to be skipped entirely. This allows disclosure of fields that the site administrator explicitly restricted from public access.

Details

When an unauthenticated user queries the piece-type REST API, the getRestQuery method processes the request at modules/@apostrophecms/piece-type/index.js:1120:

// piece-type/index.js:1120-1137
getRestQuery(req, omitPermissionCheck = false) {
  const query = self.find(req).attachments(true);
  query.applyBuildersSafely(req.query);          // [1] attacker input applied first
  if (!omitPermissionCheck && !self.canAccessApi(req)) {
    if (!self.options.publicApiProjection) {
      query.and({
        _id: null
      });
    } else if (!query.state.project) {            // [2] checks if projection already set
      query.project({
        ...self.options.publicApiProjection,
        cacheInvalidatedAt: 1
      });
    }
  }
  return query;
},

At [1], applyBuildersSafely iterates over all query string parameters and invokes their corresponding builder methods. The project builder exists in @apostrophecms/doc-type with a launder method (doc-type/index.js:1876) that sanitizes values to booleans:

// doc-type/index.js:1875-1889
project: {
  launder (p) {
    if (!p || typeof p !== 'object' || Array.isArray(p)) {
      return {};
    }
    const projection = Object.entries(p).reduce((acc, [ key, val ]) => {
      return {
        ...acc,
        [key]: self.apos.launder.boolean(val)
      };
    }, {});
    return projection;
  },

When a request includes ?project[someField]=1, the builder sets query.state.project to {someField: true}. At [2], the conditional !query.state.project evaluates to false because the state is already populated, so the publicApiProjection is never applied.

For comparison, the @apostrophecms/page module's equivalent method (page/index.js:2953) unconditionally applies the projection:

// page/index.js:2953-2958
} else {
  query.project({
    ...self.options.publicApiProjection,
    cacheInvalidatedAt: 1
  });
}

PoC

Prerequisites: An ApostropheCMS 4.x instance with a piece-type (e.g., article) that has publicApiProjection configured to restrict fields. For example:

// modules/article/index.js
module.exports = {
  extend: '@apostrophecms/piece-type',
  options: {
    publicApiProjection: {
      title: 1,
      _url: 1
    }
  }
};

Step 1: Normal request — observe restricted fields are hidden:

curl 'http://localhost:3000/api/v1/article'

Response returns only title and _url fields per the configured projection.

Step 2: Bypass projection by supplying project query parameter:

curl 'http://localhost:3000/api/v1/article?project[internalNotes]=1&project[title]=1&project[slug]=1&project[createdAt]=1'

Response now includes internalNotes, slug, createdAt, and any other requested fields — bypassing the admin-configured publicApiProjection restriction.

Step 3: Request all default fields by projecting inclusion of sensitive fields:

curl 'http://localhost:3000/api/v1/article?project[_id]=1&project[title]=1&project[slug]=1&project[visibility]=1&project[type]=1&project[createdAt]=1&project[updatedAt]=1'

All requested fields are returned, confirming the publicApiProjection is fully bypassed.

Impact

  • Information Disclosure: An unauthenticated attacker can read any field on documents that are already publicly queryable, bypassing administrator-configured field restrictions. This may expose internal notes, draft content, metadata, or other sensitive fields the administrator intentionally hid from the public API.
  • Scope: Affects all piece-type modules with publicApiProjection configured. The attacker cannot access documents they wouldn't otherwise be able to query (document-level permissions still apply), but they can read any field on accessible documents.
  • Exploitability: Trivial — requires only appending query parameters to a public URL. No authentication, special tools, or chaining required.

Recommended Fix

Remove the conditional check on query.state.project in piece-type/index.js, matching the page module's unconditional behavior. The admin-configured publicApiProjection should always override any user-supplied projection for unauthenticated users:

// modules/@apostrophecms/piece-type/index.js:1123-1134
// BEFORE (vulnerable):
if (!omitPermissionCheck && !self.canAccessApi(req)) {
  if (!self.options.publicApiProjection) {
    query.and({
      _id: null
    });
  } else if (!query.state.project) {
    query.project({
      ...self.options.publicApiProjection,
      cacheInvalidatedAt: 1
    });
  }
}

// AFTER (fixed):
if (!omitPermissionCheck && !self.canAccessApi(req)) {
  if (!self.options.publicApiProjection) {
    query.and({
      _id: null
    });
  } else {
    query.project({
      ...self.options.publicApiProjection,
      cacheInvalidatedAt: 1
    });
  }
}
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "apostrophe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T20:42:21Z",
    "nvd_published_at": "2026-04-15T20:16:35Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `getRestQuery` method in the `@apostrophecms/piece-type` module checks whether a MongoDB projection has already been set before applying the admin-configured `publicApiProjection`. An unauthenticated attacker can supply a `project` query parameter in the REST API request to pre-populate the projection state, causing the security-enforced `publicApiProjection` to be skipped entirely. This allows disclosure of fields that the site administrator explicitly restricted from public access.\n\n## Details\n\nWhen an unauthenticated user queries the piece-type REST API, the `getRestQuery` method processes the request at `modules/@apostrophecms/piece-type/index.js:1120`:\n\n```javascript\n// piece-type/index.js:1120-1137\ngetRestQuery(req, omitPermissionCheck = false) {\n  const query = self.find(req).attachments(true);\n  query.applyBuildersSafely(req.query);          // [1] attacker input applied first\n  if (!omitPermissionCheck \u0026\u0026 !self.canAccessApi(req)) {\n    if (!self.options.publicApiProjection) {\n      query.and({\n        _id: null\n      });\n    } else if (!query.state.project) {            // [2] checks if projection already set\n      query.project({\n        ...self.options.publicApiProjection,\n        cacheInvalidatedAt: 1\n      });\n    }\n  }\n  return query;\n},\n```\n\nAt **[1]**, `applyBuildersSafely` iterates over all query string parameters and invokes their corresponding builder methods. The `project` builder exists in `@apostrophecms/doc-type` with a `launder` method (`doc-type/index.js:1876`) that sanitizes values to booleans:\n\n```javascript\n// doc-type/index.js:1875-1889\nproject: {\n  launder (p) {\n    if (!p || typeof p !== \u0027object\u0027 || Array.isArray(p)) {\n      return {};\n    }\n    const projection = Object.entries(p).reduce((acc, [ key, val ]) =\u003e {\n      return {\n        ...acc,\n        [key]: self.apos.launder.boolean(val)\n      };\n    }, {});\n    return projection;\n  },\n```\n\nWhen a request includes `?project[someField]=1`, the builder sets `query.state.project` to `{someField: true}`. At **[2]**, the conditional `!query.state.project` evaluates to `false` because the state is already populated, so the `publicApiProjection` is never applied.\n\nFor comparison, the `@apostrophecms/page` module\u0027s equivalent method (`page/index.js:2953`) unconditionally applies the projection:\n\n```javascript\n// page/index.js:2953-2958\n} else {\n  query.project({\n    ...self.options.publicApiProjection,\n    cacheInvalidatedAt: 1\n  });\n}\n```\n\n## PoC\n\n**Prerequisites:** An ApostropheCMS 4.x instance with a piece-type (e.g., `article`) that has `publicApiProjection` configured to restrict fields. For example:\n\n```javascript\n// modules/article/index.js\nmodule.exports = {\n  extend: \u0027@apostrophecms/piece-type\u0027,\n  options: {\n    publicApiProjection: {\n      title: 1,\n      _url: 1\n    }\n  }\n};\n```\n\n**Step 1:** Normal request \u2014 observe restricted fields are hidden:\n\n```bash\ncurl \u0027http://localhost:3000/api/v1/article\u0027\n```\n\nResponse returns only `title` and `_url` fields per the configured projection.\n\n**Step 2:** Bypass projection by supplying `project` query parameter:\n\n```bash\ncurl \u0027http://localhost:3000/api/v1/article?project[internalNotes]=1\u0026project[title]=1\u0026project[slug]=1\u0026project[createdAt]=1\u0027\n```\n\nResponse now includes `internalNotes`, `slug`, `createdAt`, and any other requested fields \u2014 bypassing the admin-configured `publicApiProjection` restriction.\n\n**Step 3:** Request all default fields by projecting inclusion of sensitive fields:\n\n```bash\ncurl \u0027http://localhost:3000/api/v1/article?project[_id]=1\u0026project[title]=1\u0026project[slug]=1\u0026project[visibility]=1\u0026project[type]=1\u0026project[createdAt]=1\u0026project[updatedAt]=1\u0027\n```\n\nAll requested fields are returned, confirming the `publicApiProjection` is fully bypassed.\n\n## Impact\n\n- **Information Disclosure:** An unauthenticated attacker can read any field on documents that are already publicly queryable, bypassing administrator-configured field restrictions. This may expose internal notes, draft content, metadata, or other sensitive fields the administrator intentionally hid from the public API.\n- **Scope:** Affects all piece-type modules with `publicApiProjection` configured. The attacker cannot access documents they wouldn\u0027t otherwise be able to query (document-level permissions still apply), but they can read any field on accessible documents.\n- **Exploitability:** Trivial \u2014 requires only appending query parameters to a public URL. No authentication, special tools, or chaining required.\n\n## Recommended Fix\n\nRemove the conditional check on `query.state.project` in `piece-type/index.js`, matching the page module\u0027s unconditional behavior. The admin-configured `publicApiProjection` should always override any user-supplied projection for unauthenticated users:\n\n```javascript\n// modules/@apostrophecms/piece-type/index.js:1123-1134\n// BEFORE (vulnerable):\nif (!omitPermissionCheck \u0026\u0026 !self.canAccessApi(req)) {\n  if (!self.options.publicApiProjection) {\n    query.and({\n      _id: null\n    });\n  } else if (!query.state.project) {\n    query.project({\n      ...self.options.publicApiProjection,\n      cacheInvalidatedAt: 1\n    });\n  }\n}\n\n// AFTER (fixed):\nif (!omitPermissionCheck \u0026\u0026 !self.canAccessApi(req)) {\n  if (!self.options.publicApiProjection) {\n    query.and({\n      _id: null\n    });\n  } else {\n    query.project({\n      ...self.options.publicApiProjection,\n      cacheInvalidatedAt: 1\n    });\n  }\n}\n```",
  "id": "GHSA-xhq9-58fw-859p",
  "modified": "2026-04-16T20:42:21Z",
  "published": "2026-04-16T20:42:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-xhq9-58fw-859p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33888"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/00d472804bb622df36a761b6f2cf2b33b2d4ce80"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/6c2b548dec2e3f7a82e8e16736603f4cd17525aa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    }
  ],
  "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"
    }
  ],
  "summary": "ApostropheCMS: publicApiProjection Bypass via project Query Builder in Piece-Type REST API"
}

GHSA-XHQV-VMW5-79PM

Vulnerability from github – Published: 2026-07-08 15:32 – Updated: 2026-07-08 15:32
VLAI
Details

n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization bypass in the POST /workflows/{workflowId}/test-runs/new endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a workflow can trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner and resulting in unintended outbound API calls, data mutations, or other side effects in connected downstream systems. The issue primarily affects instances using the Evaluations feature where RBAC project roles grant workflow:read without workflow:execute.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T14:17:17Z",
    "severity": "MODERATE"
  },
  "details": "n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization bypass in the POST /workflows/{workflowId}/test-runs/new endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a workflow can trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner and resulting in unintended outbound API calls, data mutations, or other side effects in connected downstream systems. The issue primarily affects instances using the Evaluations feature where RBAC project roles grant workflow:read without workflow:execute.",
  "id": "GHSA-xhqv-vmw5-79pm",
  "modified": "2026-07-08T15:32:01Z",
  "published": "2026-07-08T15:32:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-hv7x-3x78-gx53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56776"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-incorrect-oauth-scope-validation-in-workflow-test-run-endpoint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/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-XHV3-Q4XX-349R

Vulnerability from github – Published: 2026-06-19 21:43 – Updated: 2026-06-19 21:43
VLAI
Summary
stistigmem-node: quarantine review surface exposes and mutates other tenants' quarantined facts (cross-tenant BOLA)
Details

Summary

On a multi-tenant stigmem node, a tenant administrator could list, read, and admit or reject quarantined facts belonging to other tenants. The list/count queries and _get_quarantined_fact in routes/quarantine.py lacked an f.tenant_id = identity.tenant_id predicate, and the garden lookup was not tenant-scoped — reached via the /v1/quarantine list and admit/reject endpoints.

Impact

Cross-tenant confidentiality (reading another tenant's quarantined content) and cross-tenant integrity (moderating — admitting or rejecting — another tenant's facts), gated only by a plain tenant write capability rather than a node-level admin authority.

Affected configurations

This is a cross-tenant break. It is exploitable only on deployments running the opt-in stigmem-plugin-multi-tenant (multiple tenants on one node). A default single-tenant node has only tenant="default" — there is no second tenant to cross — so it is not exploitable on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.

Patches

Fixed in 0.9.0a12 (PR #728): AND f.tenant_id = identity.tenant_id was added to the list/count queries and _get_quarantined_fact; the garden lookup is now tenant-scoped; and any genuinely cross-tenant moderation is gated behind can_admin_federation() (node superadmin), not a tenant write capability. A tenant-B admin can no longer list, admit, or reject tenant-A's quarantined facts.

Workarounds

None other than upgrading to 0.9.0a12. Single-tenant deployments are unaffected.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "stigmem-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0a12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:43:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nOn a multi-tenant stigmem node, a tenant administrator could list, read, and **admit or reject** quarantined facts belonging to **other** tenants. The list/count queries and `_get_quarantined_fact` in `routes/quarantine.py` lacked an `f.tenant_id = identity.tenant_id` predicate, and the garden lookup was not tenant-scoped \u2014 reached via the `/v1/quarantine` list and admit/reject endpoints.\n\n### Impact\nCross-tenant confidentiality (reading another tenant\u0027s quarantined content) and cross-tenant integrity (moderating \u2014 admitting or rejecting \u2014 another tenant\u0027s facts), gated only by a plain tenant `write` capability rather than a node-level admin authority.\n\n### Affected configurations\nThis is a cross-**tenant** break. It is exploitable **only** on deployments running the opt-in `stigmem-plugin-multi-tenant` (multiple tenants on one node). A default single-tenant node has only `tenant=\"default\"` \u2014 there is no second tenant to cross \u2014 so it is **not exploitable** on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.\n\n### Patches\nFixed in `0.9.0a12` (PR #728): `AND f.tenant_id = identity.tenant_id` was added to the list/count queries and `_get_quarantined_fact`; the garden lookup is now tenant-scoped; and any genuinely cross-tenant moderation is gated behind `can_admin_federation()` (node superadmin), not a tenant `write` capability. A tenant-B admin can no longer list, admit, or reject tenant-A\u0027s quarantined facts.\n\n### Workarounds\nNone other than upgrading to `0.9.0a12`. Single-tenant deployments are unaffected.",
  "id": "GHSA-xhv3-q4xx-349r",
  "modified": "2026-06-19T21:43:00Z",
  "published": "2026-06-19T21:43:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eidetic-labs/stigmem/security/advisories/GHSA-xhv3-q4xx-349r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eidetic-labs/stigmem/pull/728"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eidetic-labs/stigmem"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "stistigmem-node: quarantine review surface exposes and mutates other tenants\u0027 quarantined facts (cross-tenant BOLA)"
}

GHSA-XHX7-6233-WM3W

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

Insecure Permissions vulnerability in Ethereum v.1.12.2 allows a remote attacker to escalate privileges via the _transfer function.

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-2024-51426"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-30T21:15:15Z",
    "severity": "HIGH"
  },
  "details": "Insecure Permissions vulnerability in Ethereum v.1.12.2 allows a remote attacker to escalate privileges via the _transfer function.",
  "id": "GHSA-xhx7-6233-wm3w",
  "modified": "2024-10-31T18:31:18Z",
  "published": "2024-10-30T21:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Wzy-source/Gala/blob/main/CVEs/EOTT_0x5fe0971167215aade651f76492f8489e43ceb48a.md"
    }
  ],
  "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-XHXR-RR46-HC8X

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

Improper access control vulnerability in Samsung Members prior to versions 2.4.85.11 in Android O(8.1) and below, and 3.9.10.11 in Android P(9.0) and above allows untrusted applications to cause local file inclusion in webview.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-25438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-08T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control vulnerability in Samsung Members prior to versions 2.4.85.11 in Android O(8.1) and below, and 3.9.10.11 in Android P(9.0) and above allows untrusted applications to cause local file inclusion in webview.",
  "id": "GHSA-xhxr-rr46-hc8x",
  "modified": "2022-07-15T00:00:18Z",
  "published": "2022-05-24T19:07:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25438"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XJ5Q-CGQF-CRW9

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

During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the ACAP Application framework that allowed applications to access restricted D-Bus methods within the framework. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-0359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-04T06:15:30Z",
    "severity": "HIGH"
  },
  "details": "During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the ACAP Application framework that allowed applications to access restricted D-Bus methods within the framework. \nAxis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.",
  "id": "GHSA-xj5q-cgqf-crw9",
  "modified": "2025-03-04T06:30:34Z",
  "published": "2025-03-04T06:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0359"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/68/08/c5/cve-2025-0359pdf-en-US-466885.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XJ63-5V6J-3XR7

Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-05-24 17:43
VLAI
Details

Improper Access Control in the RCP+ server of the Bosch Video Recording Manager (VRM) component allows arbitrary and unauthenticated access to a limited subset of certificates, stored in the underlying Microsoft Windows operating system. The fixed versions implement modified authentication checks. Prior releases of VRM software version 3.70 are considered unaffected. This vulnerability affects VRM v3.70.x, v3.71 < v3.71.0034 and v3.81 < 3.81.0050; DIVAR IP 5000 3.80 < 3.80.0039; BVMS all versions using VRM.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-26T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Access Control in the RCP+ server of the Bosch Video Recording Manager (VRM) component allows arbitrary and unauthenticated access to a limited subset of certificates, stored in the underlying Microsoft Windows operating system. The fixed versions implement modified authentication checks. Prior releases of VRM software version 3.70 are considered unaffected. This vulnerability affects VRM v3.70.x, v3.71 \u003c v3.71.0034 and v3.81 \u003c 3.81.0050; DIVAR IP 5000 3.80 \u003c 3.80.0039; BVMS all versions using VRM.",
  "id": "GHSA-xj63-5v6j-3xr7",
  "modified": "2022-05-24T17:43:05Z",
  "published": "2022-05-24T17:43:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11684"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com/security-advisories/bosch-sa-804652.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XJ9W-5R6Q-X6V4

Vulnerability from github – Published: 2026-04-03 02:59 – Updated: 2026-05-06 23:25
VLAI
Summary
OpenClaw: Device-Paired Node Skips Node Scope Gate → Host RCE.md
Details

Summary

Device-Paired Node Skips Node Scope Gate → Host RCE.md

Current Maintainer Triage

  • Status: open
  • Normalized severity: high
  • Assessment: Real in shipped v2026.3.28 because a merely device-paired node could expose node commands without node pairing, but high is sufficient given the pairing/setup prerequisites.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • 3886b65ef21d02808c1a106fa1f9f69e22f71c32 — 2026-03-30T17:29:28+01:00

OpenClaw thanks @AntAISecurityLab 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
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T02:59:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nDevice-Paired Node Skips Node Scope Gate \u2192 Host RCE.md\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: high\n- Assessment: Real in shipped v2026.3.28 because a merely device-paired node could expose node commands without node pairing, but high is sufficient given the pairing/setup prerequisites.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `3886b65ef21d02808c1a106fa1f9f69e22f71c32` \u2014 2026-03-30T17:29:28+01:00\n\nOpenClaw thanks @AntAISecurityLab for reporting.",
  "id": "GHSA-xj9w-5r6q-x6v4",
  "modified": "2026-05-06T23:25:17Z",
  "published": "2026-04-03T02:59:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xj9w-5r6q-x6v4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41352"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/3886b65ef21d02808c1a106fa1f9f69e22f71c32"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-remote-code-execution-via-node-scope-gate-bypass"
    }
  ],
  "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:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Device-Paired Node Skips Node Scope Gate \u2192 Host RCE.md"
}
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