Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14584 vulnerabilities reference this CWE, most recent first.

GHSA-8JF2-78M7-7F8V

Vulnerability from github – Published: 2023-06-16 09:30 – Updated: 2024-04-04 04:54
VLAI
Details

Mattermost fails to verify if the requestor is a sysadmin or not, before allowing install requests to the Apps allowing a regular user send install requests to the Apps.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-2784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-16T09:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost fails to verify if the requestor is a sysadmin or not, before allowing `install` requests to the Apps allowing a regular user send install requests to the Apps. ",
  "id": "GHSA-8jf2-78m7-7f8v",
  "modified": "2024-04-04T04:54:22Z",
  "published": "2023-06-16T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2784"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8JFH-PH5C-R74H

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

A missing authorization vulnerability exists in Citrix ShareFile Storage Zones Controller before 5.7.3, 5.8.3, 5.9.3, 5.10.1 and 5.11.18 may allow unauthenticated remote compromise of the Storage Zones Controller.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-27T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A missing authorization vulnerability exists in Citrix ShareFile Storage Zones Controller before 5.7.3, 5.8.3, 5.9.3, 5.10.1 and 5.11.18 may allow unauthenticated remote compromise of the Storage Zones Controller.",
  "id": "GHSA-8jfh-ph5c-r74h",
  "modified": "2022-05-24T19:03:30Z",
  "published": "2022-05-24T19:03:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22891"
    },
    {
      "type": "WEB",
      "url": "https://support.citrix.com/article/CTX310780"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8JH8-J7RP-79HX

Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2022-09-27 00:00
VLAI
Details

Unauthenticated Optin Campaign Cache Deletion vulnerability in MailOptin plugin <= 1.2.49.0 at WordPress.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-36340"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-23T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Unauthenticated Optin Campaign Cache Deletion vulnerability in MailOptin plugin \u003c= 1.2.49.0 at WordPress.",
  "id": "GHSA-8jh8-j7rp-79hx",
  "modified": "2022-09-27T00:00:18Z",
  "published": "2022-09-25T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36340"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/mailoptin/wordpress-mailoptin-plugin-1-2-49-0-unauthenticated-optin-campaign-cache-deletion-vulnerability/_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://plugins.svn.wordpress.org/mailoptin/trunk/changelog.txt"
    }
  ],
  "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-8JHG-MP96-62F4

Vulnerability from github – Published: 2025-04-01 15:31 – Updated: 2026-04-01 18:34
VLAI
Details

Missing Authorization vulnerability in WPFactory WordPress Adverts Plugin allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WordPress Adverts Plugin: from n/a through 1.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31848"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T15:16:25Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in WPFactory WordPress Adverts Plugin allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WordPress Adverts Plugin: from n/a through 1.4.",
  "id": "GHSA-8jhg-mp96-62f4",
  "modified": "2026-04-01T18:34:22Z",
  "published": "2025-04-01T15:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31848"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/adverts-click-tracker/vulnerability/wordpress-wordpress-adverts-plugin-plugin-1-4-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8JHH-JCQG-MJ5P

Vulnerability from github – Published: 2026-03-13 15:47 – Updated: 2026-03-13 15:48
VLAI
Summary
OpenClaw: Channel commands could bypass account-scoped `configWrites` restrictions
Details

Summary

In affected versions of openclaw, channel-initiated config mutations were authorized against the originating account's configWrites policy but did not consistently re-check the targeted account scope. An authorized sender on one account could mutate protected sibling-account configuration when the target account had configWrites: false.

Impact

This is an account-scoped policy bypass inside a single gateway deployment. Channel commands such as /config set channels.<provider>.accounts.<id>... and config-backed /allowlist ... --config --account <id> could modify protected sibling-account configuration.

Affected Packages and Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.3.8
  • Fixed in: 2026.3.11

Technical Details

The mutation path validated the origin account scope but did not consistently authorize every resolved target scope. Ambiguous collection and root writes under channels and channels.<provider>.accounts could therefore reach protected account configuration from channel command surfaces.

Fix

OpenClaw now authorizes config mutations against both the origin scope and each resolved target scope, and it rejects ambiguous root and collection writes from channel commands unless the caller is an internal gateway client with operator.admin. The fix shipped in openclaw@2026.3.11.

Workarounds

Upgrade to 2026.3.11 or later.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T15:47:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nIn affected versions of `openclaw`, channel-initiated config mutations were authorized against the originating account\u0027s `configWrites` policy but did not consistently re-check the targeted account scope. An authorized sender on one account could mutate protected sibling-account configuration when the target account had `configWrites: false`.\n\n## Impact\nThis is an account-scoped policy bypass inside a single gateway deployment. Channel commands such as `/config set channels.\u003cprovider\u003e.accounts.\u003cid\u003e...` and config-backed `/allowlist ... --config --account \u003cid\u003e` could modify protected sibling-account configuration.\n\n## Affected Packages and Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.8`\n- Fixed in: `2026.3.11`\n\n## Technical Details\nThe mutation path validated the origin account scope but did not consistently authorize every resolved target scope. Ambiguous collection and root writes under `channels` and `channels.\u003cprovider\u003e.accounts` could therefore reach protected account configuration from channel command surfaces.\n\n## Fix\nOpenClaw now authorizes config mutations against both the origin scope and each resolved target scope, and it rejects ambiguous root and collection writes from channel commands unless the caller is an internal gateway client with `operator.admin`. The fix shipped in `openclaw@2026.3.11`.\n\n## Workarounds\nUpgrade to `2026.3.11` or later.",
  "id": "GHSA-8jhh-jcqg-mj5p",
  "modified": "2026-03-13T15:48:00Z",
  "published": "2026-03-13T15:47:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8jhh-jcqg-mj5p"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Channel commands could bypass account-scoped `configWrites` restrictions"
}

GHSA-8JJ6-7VGP-RG47

Vulnerability from github – Published: 2024-02-08 00:32 – Updated: 2024-02-08 00:32
VLAI
Details

An issue has been discovered in GitLab EE affecting all versions from 16.4 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2 which allows a maintainer to change the name of a protected branch that bypasses the security policy added to block MR.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-6840"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-07T22:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab EE affecting all versions from 16.4 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2 which allows a maintainer to change the name of a protected branch that bypasses the security policy added to block MR.",
  "id": "GHSA-8jj6-7vgp-rg47",
  "modified": "2024-02-08T00:32:19Z",
  "published": "2024-02-08T00:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6840"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2280292"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/435500"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8JJ8-QH37-33Q3

Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-25 18:31
VLAI
Details

GitLab has remediated an issue in GitLab EE affecting all versions from 18.6 before 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1 that under certain conditions could have allowed an authenticated user with Planner role to view security category metadata and attributes in group security configuration due to improper access control

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T17:16:27Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab EE affecting all versions from 18.6 before 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1 that under certain conditions could have allowed an authenticated user with Planner role to view security category metadata and attributes in group security configuration due to improper access control",
  "id": "GHSA-8jj8-qh37-33q3",
  "modified": "2026-03-25T18:31:48Z",
  "published": "2026-03-25T18:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14595"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3457779"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/03/25/patch-release-gitlab-18-10-1-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/583971"
    }
  ],
  "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-8JJP-R2W2-4V22

Vulnerability from github – Published: 2026-05-14 20:26 – Updated: 2026-05-15 23:54
VLAI
Summary
Open WebUI: Low-privilege authenticated users can enumerate and stop global background tasks, causing system-wide chat disruption
Details

Summary

Any authenticated user with low privileges can enumerate active background tasks across the system and stop tasks belonging to other users via the GET /api/tasks and POST /api/tasks/stop/{task_id} methods. This allows a casual user to disrupt system-wide chat usage by continuously canceling other users' active tasks. This is a real authorization vulnerability affecting integrity and usability in multi-user deployments.

Details

Open WebUI exposes GET /api/tasks and POST /api/tasks/stop/{task_id} to any verified user. These endpoints operate on a global task namespace and accept raw task_id values without checking whether the task belongs to the current caller.

As a result, a normal authenticated user can enumerate active global task IDs and stop tasks belonging to other users.

Root cause:

  1. Route authorization is too weak.

In backend/open_webui/main.py, both endpoints only require get_verified_user:

@app.post('/api/tasks/stop/{task_id}')
async def stop_task_endpoint(request: Request, task_id: str, user=Depends(get_verified_user)):
    result = await stop_task(request.app.state.redis, task_id)

@app.get('/api/tasks')
async def list_tasks_endpoint(request: Request, user=Depends(get_verified_user)):
    return {'tasks': await list_tasks(request.app.state.redis)}

get_verified_user accepts both user and admin roles in backend/open_webui/utils/auth.py.

  1. The helper operates on a global namespace.

In backend/open_webui/tasks.py, task listing is global:

async def list_tasks(redis):
    if redis:
        return await redis_list_tasks(redis)
    return list(tasks.keys())

In backend/open_webui/tasks.py, task stopping is by raw task_id:

async def stop_task(redis, task_id: str):
    if redis:
        item_id = await redis.hget(REDIS_TASKS_KEY, task_id)
        await redis_send_command(redis, {'action': 'stop', 'task_id': task_id})
        await redis_cleanup_task(redis, task_id, item_id or None)

There is no owner check, no user_id check, and no mapping from task_id back to the current caller before stop or cleanup.

This also appears unintended because the codebase already has a scoped route, GET /api/tasks/chat/{chat_id}, which checks whether the chat belongs to the current user before returning task IDs.

Relevant code references: - backend/open_webui/main.py:1975 - backend/open_webui/main.py:1984 - backend/open_webui/main.py:1989 - backend/open_webui/tasks.py:127 - backend/open_webui/tasks.py:145 - backend/open_webui/utils/auth.py:415

Suggested remediation: - Store task ownership metadata such as user_id and chat_id, then enforce owner-only access for non-admin users - Suggested implementation locations: - backend/open_webui/main.py: add authentication checks for /api/tasks and /api/tasks/stop/{task_id} - backend/open_webui/tasks.py: add support for storing/querying task ownership metadata such as user_id and chat_id, and support owner-scoped listing/stopping

PoC

Preconditions:

  • Default main branch deployment
  • Authentication enabled
  • Two normal user accounts, or any multi-user deployment where the attacker has one authenticated non-admin account
  • At least one task actively running for another user

This does not require any weakened security settings.

PoC objective:

  1. Show that a non-admin user can see global active task IDs that are not their own
  2. Show that the same user can stop another user's active task

Reproduction steps:

Step 1. Victim starts a long-running task

Using the UI, User A starts a long response generation or another background task and leaves it running.

Expected security model: User B should not be able to see or control User A's task.

Step 2. Attacker enumerates global task IDs

Using User B's authenticated token:

curl -i -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks

Expected result:

  • only User B's own task IDs should be returned, or
  • the endpoint should be admin-only

Actual result: the response returns the global active task list.

Example response shape:

{"tasks":["<task-id-a>","<task-id-b>"]}

This exposes task IDs belonging to other users.

Step 3. Attacker stops a foreign task

Pick a task ID that belongs to User A and send:

curl -i -X POST -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks/stop/<FOREIGN_TASK_ID>

Expected result:

  • 403 Forbidden, or
  • 404 Not Found for non-owned tasks, or
  • admin-only access

Actual result: the server accepts the request and attempts to stop the foreign task.

Example response shape:

{"status":true,"message":"Task <FOREIGN_TASK_ID> stopped."}

Step 4. Observe boundary violation

User A's running task is interrupted or disappears from the active task set even though User B does not own it.

What actions become possible that should not be possible:

  • enumerate globally active task IDs across users
  • cancel another user's in-progress generation or background work
  • repeat this for every returned task ID, causing broad cross-user disruption

Copy-paste PoC summary:

  1. Enumerate all active tasks as a normal non-admin user
curl -s -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks
  1. Stop a task that does not belong to that user
curl -s -X POST -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks/stop/<FOREIGN_TASK_ID>

Impact

Type of vulnerability: broken object-level authorization affecting a global runtime control-plane endpoint.

Who is impacted:

  • all users in a multi-user Open WebUI deployment
  • any user currently running a background task, especially chat generation tasks
  • administrators indirectly, because normal users can disrupt system-wide usage without admin privileges

Direct impact:

  • cross-user task ID disclosure
  • cross-user task cancellation

Practical impact:

  • interruption of long-running chat responses
  • interruption of background indexing or ingestion tasks associated with shared runtime jobs
  • one ordinary authenticated low-privilege user can continuously poll /api/tasks and immediately cancel every newly created active task
  • with a simple loop or script, this becomes a practical persistent denial-of-service against chat usage for all users on the instance
  • in a multi-user deployment, normal users may be unable to complete any chat generation while the attacker continues polling and cancelling tasks

Why severity is meaningful:

  • privileges required: low, only an authenticated non-admin account
  • scope: cross-user
  • impact class: integrity and availability
  • exploitation complexity: low once logged in

This is not full account takeover or privilege escalation, but it enables platform-wide operational disruption from a low-privilege account. In practice, sustained exploitation can make chat functionality effectively unusable for other users on the system.

Resolution

Fixed in commit e7ff4768f (#23454, "Add ownership checks to global task endpoints"), first released in v0.9.0 (Apr 2026).

The fix takes a simpler approach than per-task ownership tracking, which would have required a schema change to attribute every task to a user_id:

  • GET /api/tasks and POST /api/tasks/stop/{task_id} are restricted to admin-only via Depends(get_admin_user). Cross-user enumeration and termination are no longer reachable from a non-admin account.
  • A new scoped POST /api/tasks/chat/{chat_id}/stop endpoint covers the legitimate non-admin use case (a user stopping their own in-progress generation), reusing the same chat-ownership check the existing GET /api/tasks/chat/{chat_id} already enforces.

CVE-2025-63681 was a prior disclosure of the same authorization gap against v0.6.33; the fix in v0.9.0 also resolves that.

Users on >= 0.9.0 are not affected.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.12"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T20:26:49Z",
    "nvd_published_at": "2026-05-15T20:16:48Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAny authenticated user with low privileges can enumerate active background tasks across the system and stop tasks belonging to other users via the GET /api/tasks and POST /api/tasks/stop/{task_id} methods. This allows a casual user to disrupt system-wide chat usage by continuously canceling other users\u0027 active tasks. This is a real authorization vulnerability affecting integrity and usability in multi-user deployments.\n\n\n### Details\nOpen WebUI exposes `GET /api/tasks` and `POST /api/tasks/stop/{task_id}` to any verified user. These endpoints operate on a global task namespace and accept raw `task_id` values without checking whether the task belongs to the current caller.\n\nAs a result, a normal authenticated user can enumerate active global task IDs and stop tasks belonging to other users.\n\nRoot cause:\n\n1. Route authorization is too weak.\n\nIn `backend/open_webui/main.py`, both endpoints only require `get_verified_user`:\n\n```python\n@app.post(\u0027/api/tasks/stop/{task_id}\u0027)\nasync def stop_task_endpoint(request: Request, task_id: str, user=Depends(get_verified_user)):\n    result = await stop_task(request.app.state.redis, task_id)\n\n@app.get(\u0027/api/tasks\u0027)\nasync def list_tasks_endpoint(request: Request, user=Depends(get_verified_user)):\n    return {\u0027tasks\u0027: await list_tasks(request.app.state.redis)}\n```\n\n`get_verified_user` accepts both `user` and `admin` roles in `backend/open_webui/utils/auth.py`.\n\n2. The helper operates on a global namespace.\n\nIn `backend/open_webui/tasks.py`, task listing is global:\n\n```python\nasync def list_tasks(redis):\n    if redis:\n        return await redis_list_tasks(redis)\n    return list(tasks.keys())\n```\n\nIn `backend/open_webui/tasks.py`, task stopping is by raw `task_id`:\n\n```python\nasync def stop_task(redis, task_id: str):\n    if redis:\n        item_id = await redis.hget(REDIS_TASKS_KEY, task_id)\n        await redis_send_command(redis, {\u0027action\u0027: \u0027stop\u0027, \u0027task_id\u0027: task_id})\n        await redis_cleanup_task(redis, task_id, item_id or None)\n```\n\nThere is no owner check, no `user_id` check, and no mapping from `task_id` back to the current caller before stop or cleanup.\n\nThis also appears unintended because the codebase already has a scoped route, `GET /api/tasks/chat/{chat_id}`, which checks whether the chat belongs to the current user before returning task IDs.\n\nRelevant code references:\n- `backend/open_webui/main.py:1975`\n- `backend/open_webui/main.py:1984`\n- `backend/open_webui/main.py:1989`\n- `backend/open_webui/tasks.py:127`\n- `backend/open_webui/tasks.py:145`\n- `backend/open_webui/utils/auth.py:415`\n\nSuggested remediation:\n- Store task ownership metadata such as `user_id` and `chat_id`, then enforce owner-only access for non-admin users\n- Suggested implementation locations:\n  - `backend/open_webui/main.py`: add authentication checks for `/api/tasks` and `/api/tasks/stop/{task_id}`\n  - `backend/open_webui/tasks.py`: add support for storing/querying task ownership metadata such as `user_id` and `chat_id`, and support owner-scoped listing/stopping\n\n\n\n### PoC\nPreconditions:\n\n- Default `main` branch deployment\n- Authentication enabled\n- Two normal user accounts, or any multi-user deployment where the attacker has one authenticated non-admin account\n- At least one task actively running for another user\n\nThis does not require any weakened security settings.\n\nPoC objective:\n\n1. Show that a non-admin user can see global active task IDs that are not their own\n2. Show that the same user can stop another user\u0027s active task\n\nReproduction steps:\n\n#### Step 1. Victim starts a long-running task\n\nUsing the UI, User A starts a long response generation or another background task and leaves it running.\n\nExpected security model:\nUser B should not be able to see or control User A\u0027s task.\n\n#### Step 2. Attacker enumerates global task IDs\n\nUsing User B\u0027s authenticated token:\n\n```bash\ncurl -i -H \"Authorization: Bearer \u003cUSER_B_TOKEN\u003e\" http://\u003copen-webui-host\u003e/api/tasks\n```\n\nExpected result:\n\n- only User B\u0027s own task IDs should be returned, or\n- the endpoint should be admin-only\n\nActual result:\nthe response returns the global active task list.\n\nExample response shape:\n\n```json\n{\"tasks\":[\"\u003ctask-id-a\u003e\",\"\u003ctask-id-b\u003e\"]}\n```\n\nThis exposes task IDs belonging to other users.\n\n#### Step 3. Attacker stops a foreign task\n\nPick a task ID that belongs to User A and send:\n\n```bash\ncurl -i -X POST -H \"Authorization: Bearer \u003cUSER_B_TOKEN\u003e\" http://\u003copen-webui-host\u003e/api/tasks/stop/\u003cFOREIGN_TASK_ID\u003e\n```\n\nExpected result:\n\n- `403 Forbidden`, or\n- `404 Not Found` for non-owned tasks, or\n- admin-only access\n\nActual result:\nthe server accepts the request and attempts to stop the foreign task.\n\nExample response shape:\n\n```json\n{\"status\":true,\"message\":\"Task \u003cFOREIGN_TASK_ID\u003e stopped.\"}\n```\n\n#### Step 4. Observe boundary violation\n\nUser A\u0027s running task is interrupted or disappears from the active task set even though User B does not own it.\n\nWhat actions become possible that should not be possible:\n\n- enumerate globally active task IDs across users\n- cancel another user\u0027s in-progress generation or background work\n- repeat this for every returned task ID, causing broad cross-user disruption\n\nCopy-paste PoC summary:\n\n1. Enumerate all active tasks as a normal non-admin user\n\n```bash\ncurl -s -H \"Authorization: Bearer \u003cUSER_B_TOKEN\u003e\" http://\u003copen-webui-host\u003e/api/tasks\n```\n\n2. Stop a task that does not belong to that user\n\n```bash\ncurl -s -X POST -H \"Authorization: Bearer \u003cUSER_B_TOKEN\u003e\" http://\u003copen-webui-host\u003e/api/tasks/stop/\u003cFOREIGN_TASK_ID\u003e\n```\n\n### Impact\nType of vulnerability:\nbroken object-level authorization affecting a global runtime control-plane endpoint.\n\nWho is impacted:\n\n- all users in a multi-user Open WebUI deployment\n- any user currently running a background task, especially chat generation tasks\n- administrators indirectly, because normal users can disrupt system-wide usage without admin privileges\n\nDirect impact:\n\n- cross-user task ID disclosure\n- cross-user task cancellation\n\nPractical impact:\n\n- interruption of long-running chat responses\n- interruption of background indexing or ingestion tasks associated with shared runtime jobs\n- one ordinary authenticated low-privilege user can continuously poll `/api/tasks` and immediately cancel every newly created active task\n- with a simple loop or script, this becomes a practical persistent denial-of-service against chat usage for all users on the instance\n- in a multi-user deployment, normal users may be unable to complete any chat generation while the attacker continues polling and cancelling tasks\n\nWhy severity is meaningful:\n\n- privileges required: low, only an authenticated non-admin account\n- scope: cross-user\n- impact class: integrity and availability\n- exploitation complexity: low once logged in\n\nThis is not full account takeover or privilege escalation, but it enables platform-wide operational disruption from a low-privilege account. In practice, sustained exploitation can make chat functionality effectively unusable for other users on the system.\n\n## Resolution\n\nFixed in commit [e7ff4768f](https://github.com/open-webui/open-webui/commit/e7ff4768f8ffe1924b4576381c9e45e8a64350e4) ([#23454](https://github.com/open-webui/open-webui/pull/23454), \"Add ownership checks to global task endpoints\"), first released in **v0.9.0** (Apr 2026).\n\nThe fix takes a simpler approach than per-task ownership tracking, which would have required a schema change to attribute every task to a `user_id`:\n\n- `GET /api/tasks` and `POST /api/tasks/stop/{task_id}` are restricted to admin-only via `Depends(get_admin_user)`. Cross-user enumeration and termination are no longer reachable from a non-admin account.\n- A new scoped `POST /api/tasks/chat/{chat_id}/stop` endpoint covers the legitimate non-admin use case (a user stopping their own in-progress generation), reusing the same chat-ownership check the existing `GET /api/tasks/chat/{chat_id}` already enforces.\n\nCVE-2025-63681 was a prior disclosure of the same authorization gap against v0.6.33; the fix in v0.9.0 also resolves that.\n\nUsers on `\u003e= 0.9.0` are not affected.",
  "id": "GHSA-8jjp-r2w2-4v22",
  "modified": "2026-05-15T23:54:50Z",
  "published": "2026-05-14T20:26:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-8jjp-r2w2-4v22"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45399"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/23454"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/e7ff4768f8ffe1924b4576381c9e45e8a64350e4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.9.0"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Low-privilege authenticated users can enumerate and stop global background tasks, causing system-wide chat disruption"
}

GHSA-8JMV-F2MX-H22C

Vulnerability from github – Published: 2026-04-16 09:31 – Updated: 2026-04-16 09:31
VLAI
Details

The Post Grid Gutenberg Blocks for News, Magazines, Blog Websites – PostX plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ultp_shareCount_callback() function in all versions up to, and including, 5.0.5. This makes it possible for unauthenticated attackers to modify the share_count post meta for any post, including private or draft posts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-16T08:16:27Z",
    "severity": "MODERATE"
  },
  "details": "The Post Grid Gutenberg Blocks for News, Magazines, Blog Websites \u2013 PostX plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ultp_shareCount_callback() function in all versions up to, and including, 5.0.5. This makes it possible for unauthenticated attackers to modify the share_count post meta for any post, including private or draft posts.",
  "id": "GHSA-8jmv-f2mx-h22c",
  "modified": "2026-04-16T09:31:44Z",
  "published": "2026-04-16T09:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0718"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?old_path=/ultimate-post/tags/5.0.5/classes/Blocks.php\u0026new_path=/ultimate-post/tags/5.0.6/classes/Blocks.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c4b2cf3b-5d35-4ce6-9453-1538a6f7752f?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8JP3-8878-6Q85

Vulnerability from github – Published: 2026-04-09 06:30 – Updated: 2026-04-09 06:30
VLAI
Details

The Quick Playground plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1.3.1. This is due to insufficient authorization checks on REST API endpoints that expose a sync code and allow arbitrary file uploads. This makes it possible for unauthenticated attackers to retrieve the sync code, upload PHP files with path traversal, and achieve remote code execution on the server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-1830"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-09T05:16:03Z",
    "severity": "CRITICAL"
  },
  "details": "The Quick Playground plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1.3.1. This is due to insufficient authorization checks on REST API endpoints that expose a sync code and allow arbitrary file uploads. This makes it possible for unauthenticated attackers to retrieve the sync code, upload PHP files with path traversal, and achieve remote code execution on the server.",
  "id": "GHSA-8jp3-8878-6q85",
  "modified": "2026-04-09T06:30:27Z",
  "published": "2026-04-09T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1830"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/quick-playground/trunk/api.php#L39"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/quick-playground/trunk/expro-api.php#L419"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3500839%40quick-playground\u0026new=3500839%40quick-playground\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/308cd28a-a477-4bc6-a392-ad5a9eca1cb5?source=cve"
    }
  ],
  "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"
    }
  ]
}

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.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.