CWE-862
Allowed-with-ReviewMissing 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:54Mattermost 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.
{
"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:03A 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.
{
"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:00Unauthenticated Optin Campaign Cache Deletion vulnerability in MailOptin plugin <= 1.2.49.0 at WordPress.
{
"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:34Missing 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.
{
"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:48Summary
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.
{
"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:32An 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.
{
"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:31GitLab 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
{
"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:54Summary
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:
- 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.
- 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
mainbranch 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:
- Show that a non-admin user can see global active task IDs that are not their own
- 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, or404 Not Foundfor 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:
- Enumerate all active tasks as a normal non-admin user
curl -s -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks
- 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/tasksand 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/tasksandPOST /api/tasks/stop/{task_id}are restricted to admin-only viaDepends(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}/stopendpoint covers the legitimate non-admin use case (a user stopping their own in-progress generation), reusing the same chat-ownership check the existingGET /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.
{
"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:31The 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.
{
"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:30The 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.
{
"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
- 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
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
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
- 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
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.