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.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-JWRQ-8G5X-5FHM

Vulnerability from github – Published: 2026-04-17 21:35 – Updated: 2026-05-08 01:32
VLAI
Summary
OpenClaw: Collect-mode queue batches could reuse the last sender authorization context
Details

Summary

Collect-mode queue batches could reuse the last sender authorization context.

Affected Packages / Versions

  • Package: openclaw
  • Ecosystem: npm
  • Affected versions: < 2026.4.14
  • Patched versions: >= 2026.4.14

Impact

Collect-mode queued messages from different senders could be drained as one batch using the final sender's authorization context, allowing earlier messages to inherit a more privileged context.

Technical Details

The fix splits collect-mode batches by sender authorization context before dispatch, preserving each message's own trust state.

Fix

The issue was fixed in #66024. The first stable tag containing the fix is v2026.4.14, and openclaw@2026.4.14 includes the fix.

Fix Commit(s)

  • 43d4be902755c970b3d15608679761877718da69
  • PR: #66024

Release Process Note

Users should upgrade to openclaw 2026.4.14 or newer. The latest npm release, 2026.4.14, already includes the fix.

Credits

Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:35:35Z",
    "nvd_published_at": "2026-05-05T12:16:19Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nCollect-mode queue batches could reuse the last sender authorization context.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003c 2026.4.14`\n- Patched versions: `\u003e= 2026.4.14`\n\n## Impact\n\nCollect-mode queued messages from different senders could be drained as one batch using the final sender\u0027s authorization context, allowing earlier messages to inherit a more privileged context.\n\n## Technical Details\n\nThe fix splits collect-mode batches by sender authorization context before dispatch, preserving each message\u0027s own trust state.\n\n## Fix\n\nThe issue was fixed in #66024. The first stable tag containing the fix is `v2026.4.14`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `43d4be902755c970b3d15608679761877718da69`\n- PR: #66024\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.14 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
  "id": "GHSA-jwrq-8g5x-5fhm",
  "modified": "2026-05-08T01:32:26Z",
  "published": "2026-04-17T21:35:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jwrq-8g5x-5fhm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43535"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/66024"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/43d4be902755c970b3d15608679761877718da69"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-context-reuse-in-collect-mode-queue-batches"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Collect-mode queue batches could reuse the last sender authorization context"
}

GHSA-JWVJ-G8PC-CX45

Vulnerability from github – Published: 2026-04-07 18:05 – Updated: 2026-04-07 18:05
VLAI
Summary
OpenFGA's BatchCheck within-request deduplication produces incorrect authorization decisions via list-value cache-key collision
Details

Description

In OpenFGA, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement.

Am I affected?

You are affected if you meet the following preconditions: 1. You execute BatchCheck operations which rely on context. 2. Multiple checks are sent within a single BatchCheck operation for the same user/object/relation combination, each containing context. 3. The contexts between those checks differ in a specific way

Fix

Upgrade to OpenFGA v1.14.0

Acknowledgement

OpenFGA would like to thank @bugbunny-research for the discovery and detailed report.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.13.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0"
            },
            {
              "fixed": "1.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34972"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:05:16Z",
    "nvd_published_at": "2026-04-06T21:16:19Z",
    "severity": "MODERATE"
  },
  "details": "### Description\n\nIn OpenFGA, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement.\n\n### Am I affected?\n\nYou are affected if you meet the following preconditions:\n1. You execute **BatchCheck** operations which rely on context. \n2. Multiple checks are sent within a single BatchCheck operation for the same user/object/relation combination, each containing context.\n3. The contexts between those checks differ in a specific way\n\n### Fix\nUpgrade to OpenFGA v1.14.0\n\n### Acknowledgement\nOpenFGA would like to thank @bugbunny-research for the discovery and detailed report.",
  "id": "GHSA-jwvj-g8pc-cx45",
  "modified": "2026-04-07T18:05:16Z",
  "published": "2026-04-07T18:05:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-jwvj-g8pc-cx45"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34972"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenFGA\u0027s BatchCheck within-request deduplication produces incorrect authorization decisions via list-value cache-key collision"
}

GHSA-JX2X-J75F-XQ3J

Vulnerability from github – Published: 2026-05-14 20:18 – Updated: 2026-05-19 15:58
VLAI
Summary
Open WebUI: Read-Only Users Can Toggle Note Pin Status via Incorrect Permission Check (Write via Read-Only Access)
Details

Summary

The POST /api/v1/notes/{id}/pin endpoint performs a write operation (toggling the is_pinned field) but only checks for read permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require write permission. All other write endpoints (update, delete, access/update) correctly check for write permission.

Details

Affected code: backend/open_webui/routers/notes.py lines 412-444

@router.post('/{id}/pin', response_model=Optional[NoteModel])
async def pin_note_by_id(...):
    # ...
    if user.role != 'admin' and (
        user.id != note.user_id
        and not await AccessGrants.has_access(
            user_id=user.id,
            resource_type='note',
            resource_id=note.id,
            permission='read',        # BUG: should be 'write'
            db=db,
        )
    ):
        raise HTTPException(...)

    note = await Notes.toggle_note_pinned_by_id(id, db=db)  # write operation

Compare with update endpoint (correct, line 318-327):

async def update_note_by_id(...):
    # ...
    and not await AccessGrants.has_access(
        permission='write',        # correctly checks 'write'
    )

PoC

Environment: Open WebUI v0.9.2, default configuration with notes sharing enabled.

Setup: 1. UserA creates a note 2. UserA shares note with UserB with read permission via POST /api/v1/notes/{id}/access/update with {"access_grants":[{"principal_type":"user","principal_id":"USERB_ID","permission":"read"}]}

Test:

# Step 1: UserB reads note (READ permission) -> 200 OK, write_access: false
curl -s http://TARGET/api/v1/notes/$NOTE_ID \
  -H "Authorization: Bearer $TOKEN_B"
# Result: 200 OK, "write_access": false

# Step 2: UserB updates note (WRITE operation) -> 403 Forbidden (correctly blocked)
curl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/update \
  -H "Authorization: Bearer $TOKEN_B" \
  -H "Content-Type: application/json" \
  -d '{"title":"HACKED","content":"pwned","data":{"type":"note"}}'
# Result: 403 Forbidden

# Step 3: UserB pins note (WRITE operation, but only checks READ) -> 200 OK (BUG!)
curl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \
  -H "Authorization: Bearer $TOKEN_B"
# Result: 200 OK, "is_pinned": true

# Step 4: UserB can toggle pin repeatedly
curl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \
  -H "Authorization: Bearer $TOKEN_B"
# Result: 200 OK, "is_pinned": false (toggled back)

E2E Verified Result: - Step 1: UserB reads note (READ) -> 200 OK ✓ - Step 2: UserB updates note (WRITE) -> 403 Forbidden ✓ (correctly blocked) - Step 3: UserB pins note (WRITE via READ) -> 200 OK, is_pinned: true ✗ (BUG) - Step 4: UserB toggles pin again -> 200 OK, is_pinned: false ✗ (repeated write)

Impact

  • A user with only read access to a shared note can toggle its is_pinned status
  • This modifies the note's state without write authorization
  • The pin status change is visible to the note owner and all other users with access
  • Privilege escalation from read to write on the pin operation

Limitations: Only affects the is_pinned boolean field. Cannot modify title, content, or access_grants. Requires at least read access via explicit sharing.

Fix

One-line fix — change permission='read' to permission='write' in pin_note_by_id:

# backend/open_webui/routers/notes.py, line 437
- permission='read',
+ permission='write',

This makes the pin endpoint consistent with update and delete endpoints.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45316"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T20:18:14Z",
    "nvd_published_at": "2026-05-15T22:16:54Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `POST /api/v1/notes/{id}/pin` endpoint performs a write operation (toggling the `is_pinned` field) but only checks for `read` permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require `write` permission. All other write endpoints (update, delete, access/update) correctly check for `write` permission.\n\n### Details\n\n**Affected code: `backend/open_webui/routers/notes.py` lines 412-444**\n\n```python\n@router.post(\u0027/{id}/pin\u0027, response_model=Optional[NoteModel])\nasync def pin_note_by_id(...):\n    # ...\n    if user.role != \u0027admin\u0027 and (\n        user.id != note.user_id\n        and not await AccessGrants.has_access(\n            user_id=user.id,\n            resource_type=\u0027note\u0027,\n            resource_id=note.id,\n            permission=\u0027read\u0027,        # BUG: should be \u0027write\u0027\n            db=db,\n        )\n    ):\n        raise HTTPException(...)\n    \n    note = await Notes.toggle_note_pinned_by_id(id, db=db)  # write operation\n```\n\n**Compare with update endpoint (correct, line 318-327):**\n```python\nasync def update_note_by_id(...):\n    # ...\n    and not await AccessGrants.has_access(\n        permission=\u0027write\u0027,        # correctly checks \u0027write\u0027\n    )\n```\n\n### PoC\n\n**Environment:** Open WebUI v0.9.2, default configuration with notes sharing enabled.\n\n**Setup:**\n1. UserA creates a note\n2. UserA shares note with UserB with `read` permission via `POST /api/v1/notes/{id}/access/update` with `{\"access_grants\":[{\"principal_type\":\"user\",\"principal_id\":\"USERB_ID\",\"permission\":\"read\"}]}`\n\n**Test:**\n```bash\n# Step 1: UserB reads note (READ permission) -\u003e 200 OK, write_access: false\ncurl -s http://TARGET/api/v1/notes/$NOTE_ID \\\n  -H \"Authorization: Bearer $TOKEN_B\"\n# Result: 200 OK, \"write_access\": false\n\n# Step 2: UserB updates note (WRITE operation) -\u003e 403 Forbidden (correctly blocked)\ncurl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/update \\\n  -H \"Authorization: Bearer $TOKEN_B\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"title\":\"HACKED\",\"content\":\"pwned\",\"data\":{\"type\":\"note\"}}\u0027\n# Result: 403 Forbidden\n\n# Step 3: UserB pins note (WRITE operation, but only checks READ) -\u003e 200 OK (BUG!)\ncurl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \\\n  -H \"Authorization: Bearer $TOKEN_B\"\n# Result: 200 OK, \"is_pinned\": true\n\n# Step 4: UserB can toggle pin repeatedly\ncurl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \\\n  -H \"Authorization: Bearer $TOKEN_B\"\n# Result: 200 OK, \"is_pinned\": false (toggled back)\n```\n\n**E2E Verified Result:**\n- Step 1: UserB reads note (READ) -\u003e 200 OK \u2713\n- Step 2: UserB updates note (WRITE) -\u003e 403 Forbidden \u2713 (correctly blocked)\n- Step 3: UserB pins note (WRITE via READ) -\u003e 200 OK, is_pinned: true \u2717 (BUG)\n- Step 4: UserB toggles pin again -\u003e 200 OK, is_pinned: false \u2717 (repeated write)\n\n### Impact\n\n- A user with only `read` access to a shared note can toggle its `is_pinned` status\n- This modifies the note\u0027s state without write authorization\n- The pin status change is visible to the note owner and all other users with access\n- Privilege escalation from read to write on the pin operation\n\n**Limitations:** Only affects the `is_pinned` boolean field. Cannot modify title, content, or access_grants. Requires at least read access via explicit sharing.\n\n### Fix\n\nOne-line fix \u2014 change `permission=\u0027read\u0027` to `permission=\u0027write\u0027` in `pin_note_by_id`:\n\n```python\n# backend/open_webui/routers/notes.py, line 437\n- permission=\u0027read\u0027,\n+ permission=\u0027write\u0027,\n```\n\nThis makes the pin endpoint consistent with update and delete endpoints.",
  "id": "GHSA-jx2x-j75f-xq3j",
  "modified": "2026-05-19T15:58:35Z",
  "published": "2026-05-14T20:18:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-jx2x-j75f-xq3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45316"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.9.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Read-Only Users Can Toggle Note Pin Status via Incorrect Permission Check (Write via Read-Only Access)"
}

GHSA-JX6G-VMP7-MVXQ

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

capgo.app is an over-the-air (OTA) update platform for Capacitor apps. In all versions up to and including the current release (no patch available at time of publication), the transfer_app() database function transfers an app, its channels, versions and related records to a destination organization without deleting or revalidating existing rows in channel_permission_overrides. As a result, a user who legitimately held a channel permission override while a member of the source organization retains that override after the transfer, even though they have no membership and no RBAC binding in the destination organization. Using their own authenticated JWT against the PostgREST API, such a former member can modify the destination-owned channel to point at a different bundle, causing the /updates endpoint to serve an attacker-selected application version to devices. The previously proposed fix for GHSA-626c-p6fq-3whq (PR #3093), which validates organization membership when an override is created or updated, does not remove overrides that became stale as a result of an app transfer.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-100613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T14:16:41Z",
    "severity": "MODERATE"
  },
  "details": "capgo.app is an over-the-air (OTA) update platform for Capacitor apps. In all versions up to and including the current release (no patch available at time of publication), the `transfer_app()` database function transfers an app, its channels, versions and related records to a destination organization without deleting or revalidating existing rows in `channel_permission_overrides`. As a result, a user who legitimately held a channel permission override while a member of the source organization retains that override after the transfer, even though they have no membership and no RBAC binding in the destination organization. Using their own authenticated JWT against the PostgREST API, such a former member can modify the destination-owned channel to point at a different bundle, causing the /updates endpoint to serve an attacker-selected application version to devices. The previously proposed fix for GHSA-626c-p6fq-3whq (PR #3093), which validates organization membership when an override is created or updated, does not remove overrides that became stale as a result of an app transfer.",
  "id": "GHSA-jx6g-vmp7-mvxq",
  "modified": "2026-09-26T15:31:14Z",
  "published": "2026-09-26T15:31:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Cap-go/capgo.app/security/advisories/GHSA-6mj9-x3ww-rpj9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100613"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/capgo-app-authorization-bypass-via-stale-channel-permission-overrides"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/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-JX78-FJMH-Q5CC

Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-07-13 00:01
VLAI
Details

Redmine before 4.0.9, 4.1.x before 4.1.3, and 4.2.x before 4.2.1 allows attackers to bypass the add_issue_notes permission requirement by leveraging the incoming mail handler.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-31864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-28T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Redmine before 4.0.9, 4.1.x before 4.1.3, and 4.2.x before 4.2.1 allows attackers to bypass the add_issue_notes permission requirement by leveraging the incoming mail handler.",
  "id": "GHSA-jx78-fjmh-q5cc",
  "modified": "2022-07-13T00:01:25Z",
  "published": "2022-05-24T17:49:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31864"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00013.html"
    },
    {
      "type": "WEB",
      "url": "https://www.redmine.org/news/131"
    },
    {
      "type": "WEB",
      "url": "https://www.redmine.org/projects/redmine/wiki/Security_Advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JX7F-4JRV-RJH9

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

An access control vulnerability was discovered in the Smart Polling configuration functionality due to insufficient validation of user privileges. An authenticated user with limited privileges can remotely bypass the intended access control of the web management interface and modify the Smart Polling discovery configuration. This allows the attacker to disrupt the visibility of assets in the monitored network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-33391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T14:17:22Z",
    "severity": "MODERATE"
  },
  "details": "An access control vulnerability was discovered in the Smart Polling configuration functionality due to insufficient validation of user privileges. An authenticated user with limited privileges can remotely bypass the intended access control of the web management interface and modify the Smart Polling discovery configuration. This allows the attacker to disrupt the visibility of assets in the monitored network.",
  "id": "GHSA-jx7f-4jrv-rjh9",
  "modified": "2026-09-08T15:31:54Z",
  "published": "2026-09-08T15:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33391"
    },
    {
      "type": "WEB",
      "url": "https://security.nozominetworks.com/NN-2026:17-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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-JX9M-6Q5C-JRGM

Vulnerability from github – Published: 2026-07-17 03:31 – Updated: 2026-07-17 03:31
VLAI
Details

OpenClaw 2026.2.12 before 2026.5.26 contain an authorization bypass vulnerability in the hooks allowedAgentIds validation. A lower-trust caller or configured input path can bypass agent ID restrictions by submitting blank agent IDs, allowing actions that should require stronger authorization or policy checks.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-62219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T02:18:08Z",
    "severity": "MODERATE"
  },
  "details": "OpenClaw 2026.2.12 before 2026.5.26 contain an authorization bypass vulnerability in the hooks allowedAgentIds validation. A lower-trust caller or configured input path can bypass agent ID restrictions by submitting blank agent IDs, allowing actions that should require stronger authorization or policy checks.",
  "id": "GHSA-jx9m-6q5c-jrgm",
  "modified": "2026-07-17T03:31:23Z",
  "published": "2026-07-17T03:31:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-724r-v4wf-mqc5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62219"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-blank-agent-ids"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:N/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-JXC9-XMC4-GR23

Vulnerability from github – Published: 2026-08-04 20:35 – Updated: 2026-08-04 20:35
VLAI
Summary
Open WebUI: Deletion of directories and file embeddings in other knowledge bases via sync cleanup
Details

Summary

A user with write access to one knowledge base could delete directories, and drop file embeddings, belonging to knowledge bases they do not control. The sync cleanup endpoint verified write access on the knowledge base named in the URL and then acted on the directory and file ids supplied in the request body without checking that those objects belonged to that knowledge base.

Preconditions

Default configuration, no flags involved. The attacker needs write access to at least one knowledge base, which comes from owning one, from a write access grant, or from the admin role; workspace.knowledge is off by default, so an ordinary user cannot simply create one. They also need the victim's directory or file id, which are UUIDs and are not enumerable, so in practice the attacker is someone who can already see the target knowledge base, typically a read-only collaborator on a shared one. Deployments where no knowledge base is shared beyond its owner are not reachable.

Impact

The attacker deletes a target directory and, because the deletion runs without moving files to the parent, the knowledge_file associations for every file in that subtree are removed as well, so those documents silently drop out of the victim's knowledge base and out of its retrieval results. Separately, the per-file vector cleanup dropped the standalone file-<id> collection for any file id, breaking chat-with-file for that document. The stored files and their database rows survive, since that path was gated on file ownership, and an owner can restore the state by re-adding and reprocessing. Nothing about the target knowledge base's contents is disclosed to the attacker.

Fix

Fixed in https://github.com/open-webui/open-webui/pull/26722. Both request-body loops are now scoped to the knowledge base in the URL: a directory is resolved and skipped unless its knowledge_id matches, and the per-file vector cleanup runs only for files that are members of that knowledge base. Upgrading fully resolves the issue.

Root cause

Affected component: backend/open_webui/routers/knowledge.py, handler sync_knowledge_cleanup, endpoint POST /api/v1/knowledge/{id}/sync/cleanup. Affected setup: all builds from 0.9.6 onward, no optional dependency involved.

The handler treated the write-access check on the URL knowledge base as authorization for everything it went on to do, but the objects it acted on came from the request body and were addressed by primary key alone. Directory deletion at the model layer deletes by directory id and has no notion of a parent knowledge base, so the only thing that could have bound the two together was a membership check in the handler, and there was none. The explicit directory-delete endpoint in the same router already carried that check, which is what makes this a gap in one handler rather than a missing model-layer control.

Credits

Reported by @whyiug.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.10.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.6"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-70488"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T20:35:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nA user with write access to one knowledge base could delete directories, and drop file embeddings, belonging to knowledge bases they do not control. The sync cleanup endpoint verified write access on the knowledge base named in the URL and then acted on the directory and file ids supplied in the request body without checking that those objects belonged to that knowledge base.\n\n## Preconditions\nDefault configuration, no flags involved. The attacker needs write access to at least one knowledge base, which comes from owning one, from a write access grant, or from the admin role; `workspace.knowledge` is off by default, so an ordinary user cannot simply create one. They also need the victim\u0027s directory or file id, which are UUIDs and are not enumerable, so in practice the attacker is someone who can already see the target knowledge base, typically a read-only collaborator on a shared one. Deployments where no knowledge base is shared beyond its owner are not reachable.\n\n## Impact\nThe attacker deletes a target directory and, because the deletion runs without moving files to the parent, the knowledge_file associations for every file in that subtree are removed as well, so those documents silently drop out of the victim\u0027s knowledge base and out of its retrieval results. Separately, the per-file vector cleanup dropped the standalone `file-\u003cid\u003e` collection for any file id, breaking chat-with-file for that document. The stored files and their database rows survive, since that path was gated on file ownership, and an owner can restore the state by re-adding and reprocessing. Nothing about the target knowledge base\u0027s contents is disclosed to the attacker.\n\n## Fix\nFixed in https://github.com/open-webui/open-webui/pull/26722. Both request-body loops are now scoped to the knowledge base in the URL: a directory is resolved and skipped unless its `knowledge_id` matches, and the per-file vector cleanup runs only for files that are members of that knowledge base. Upgrading fully resolves the issue.\n\n## Root cause\nAffected component: `backend/open_webui/routers/knowledge.py`, handler `sync_knowledge_cleanup`, endpoint `POST /api/v1/knowledge/{id}/sync/cleanup`. Affected setup: all builds from 0.9.6 onward, no optional dependency involved.\n\nThe handler treated the write-access check on the URL knowledge base as authorization for everything it went on to do, but the objects it acted on came from the request body and were addressed by primary key alone. Directory deletion at the model layer deletes by directory id and has no notion of a parent knowledge base, so the only thing that could have bound the two together was a membership check in the handler, and there was none. The explicit directory-delete endpoint in the same router already carried that check, which is what makes this a gap in one handler rather than a missing model-layer control.\n\n## Credits\nReported by @whyiug.",
  "id": "GHSA-jxc9-xmc4-gr23",
  "modified": "2026-08-04T20:35:47Z",
  "published": "2026-08-04T20:35:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-jxc9-xmc4-gr23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/26722"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/707efeaed7992dd9896d5928559458f228b9a539"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Deletion of directories and file embeddings in other knowledge bases via sync cleanup"
}

GHSA-JXF6-Q59W-R36Q

Vulnerability from github – Published: 2022-05-13 01:27 – Updated: 2022-05-13 01:27
VLAI
Details

Cisco Carrier Routing System (CRS) 3.9, 4.0, and 4.1 allows remote attackers to bypass ACL entries via fragmented packets, aka Bug ID CSCtj10975.

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

{
  "affected": [],
  "aliases": [
    "CVE-2012-1342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-08-06T17:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cisco Carrier Routing System (CRS) 3.9, 4.0, and 4.1 allows remote attackers to bypass ACL entries via fragmented packets, aka Bug ID CSCtj10975.",
  "id": "GHSA-jxf6-q59w-r36q",
  "modified": "2022-05-13T01:27:48Z",
  "published": "2022-05-13T01:27:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-1342"
    },
    {
      "type": "WEB",
      "url": "http://www.cisco.com/cisco/software/release.html?mdfid=279506669\u0026catid=268437899\u0026flowid=1915\u0026reltype=all\u0026relind=AVAILABLE\u0026release=3.9.2\u0026softwareid=280867577"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JXF8-G6GQ-M62F

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

Two authorization bypass through user-controlled key vulnerabilities in the Fortinet FortiPresence 2.1.0 administration interface may allow an attacker to gain access to some user data via portal manager or portal users parameters.

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-2020-6641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-02T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Two authorization bypass through user-controlled key vulnerabilities in the Fortinet FortiPresence 2.1.0 administration interface may allow an attacker to gain access to some user data via portal manager or portal users parameters.",
  "id": "GHSA-jxf8-g6gq-m62f",
  "modified": "2022-05-24T19:03:54Z",
  "published": "2022-05-24T19:03:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6641"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/advisory/FG-IR-19-258"
    }
  ],
  "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"
    }
  ]
}
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