GHSA-3CG5-48J3-V4GV

Vulnerability from github – Published: 2026-08-04 20:58 – Updated: 2026-08-04 20:58
VLAI
Summary
Open WebUI: A folder write-collaborator can permanently delete the owner's chats by deleting a shared subfolder
Details

Summary

A user granted write access to a shared chat folder could permanently delete chats and messages belonging to the folder's owner. Deleting a folder cascades into the owner's chats and the entire subfolder subtree, and the deletion handler required only write access on subfolders instead of ownership. Root folders were restricted to the owner or an admin, subfolders were not.

Preconditions

The Folders Sharing permission (user.permissions.sharing.folders) must be enabled; it is off by default. The victim must have shared a folder with the attacker at write access. features.folders and the chat.delete permission are enabled by default and are both required. Deployments that leave folder sharing disabled are not affected, and neither are single-user instances.

Impact

Permanent, irreversible destruction of another user's chat history within and beneath a shared folder. With delete_contents=false the same request instead force-moved the owner's chats out of the folder, an unauthorized relocation rather than a deletion. The write grant on the shared root folder is inherited by every descendant, so the attacker could destroy subfolders that were never explicitly shared with them. Nothing outside the shared folder's subtree is reachable, and no data is disclosed that write access did not already expose.

Fix

Fixed in 0.11.0 by https://github.com/open-webui/open-webui/pull/27003. Folder deletion is now restricted to the folder owner or an admin for root folders and subfolders alike, replacing the previous root/subfolder split with a single check. Upgrading fully resolves the issue; no configuration change is required. Owners and admins are unaffected, and a write-collaborator can still create, rename and add to shared folders and delete subfolders they own.

Root cause

Affected component: backend/open_webui/routers/folders.py, the DELETE /api/v1/folders/{id} handler. Affected setup: any release from 0.10.0 onward that has folder sharing enabled.

The cascade that follows the authorization check is bound to the folder owner's id, not the caller's, so whoever passes the check deletes the owner's data. The check itself branched on whether the folder had a parent: root folders demanded ownership or admin, while subfolders accepted any write grant. Because write grants propagate down the folder tree, that branch handed every collaborator deletion rights over the owner's subtree, which is broader than what the sharing model grants write access.

Credits

@legobattman, who reported the issue and its remediation.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-70494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T20:58:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nA user granted write access to a shared chat folder could permanently delete chats and messages belonging to the folder\u0027s owner. Deleting a folder cascades into the owner\u0027s chats and the entire subfolder subtree, and the deletion handler required only write access on subfolders instead of ownership. Root folders were restricted to the owner or an admin, subfolders were not.\n\n## Preconditions\nThe Folders Sharing permission (`user.permissions.sharing.folders`) must be enabled; it is off by default. The victim must have shared a folder with the attacker at write access. `features.folders` and the `chat.delete` permission are enabled by default and are both required. Deployments that leave folder sharing disabled are not affected, and neither are single-user instances.\n\n## Impact\nPermanent, irreversible destruction of another user\u0027s chat history within and beneath a shared folder. With `delete_contents=false` the same request instead force-moved the owner\u0027s chats out of the folder, an unauthorized relocation rather than a deletion. The write grant on the shared root folder is inherited by every descendant, so the attacker could destroy subfolders that were never explicitly shared with them. Nothing outside the shared folder\u0027s subtree is reachable, and no data is disclosed that write access did not already expose.\n\n## Fix\nFixed in 0.11.0 by https://github.com/open-webui/open-webui/pull/27003. Folder deletion is now restricted to the folder owner or an admin for root folders and subfolders alike, replacing the previous root/subfolder split with a single check. Upgrading fully resolves the issue; no configuration change is required. Owners and admins are unaffected, and a write-collaborator can still create, rename and add to shared folders and delete subfolders they own.\n\n## Root cause\nAffected component: `backend/open_webui/routers/folders.py`, the `DELETE /api/v1/folders/{id}` handler. Affected setup: any release from 0.10.0 onward that has folder sharing enabled.\n\nThe cascade that follows the authorization check is bound to the folder owner\u0027s id, not the caller\u0027s, so whoever passes the check deletes the owner\u0027s data. The check itself branched on whether the folder had a parent: root folders demanded ownership or admin, while subfolders accepted any write grant. Because write grants propagate down the folder tree, that branch handed every collaborator deletion rights over the owner\u0027s subtree, which is broader than what the sharing model grants write access.\n\n## Credits\n@legobattman, who reported the issue and its remediation.",
  "id": "GHSA-3cg5-48j3-v4gv",
  "modified": "2026-08-04T20:58:12Z",
  "published": "2026-08-04T20:58:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-3cg5-48j3-v4gv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/27003"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/915ef7d0798d3175819cedbb2f62d7bf0db78c98"
    },
    {
      "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:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: A folder write-collaborator can permanently delete the owner\u0027s chats by deleting a shared subfolder"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…