GHSA-X3QM-P8HR-3C3H

Vulnerability from github – Published: 2026-05-14 20:27 – Updated: 2026-05-19 16:00
VLAI
Summary
Open WebUI has an Indirect Object Reference (IDOR) in user notes
Details

Summary

The API /api/v1/notes/{note_id} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data.

Details

  • if notes is enabled from UI (Settings >> General >> Features >> Notes (Beta))
  • From API, attacker can access other user notes
  • if notes is disabled from UI (Settings >> General >> Features >> Notes (Beta))
  • Then attacker can enable the notes from /api/config and access other user notes

PoC

  • Step 1: Log in to the application as a valid user (User A). image

  • Step 2: Intercept or inspect the response from the endpoint GET /api/config. image

  • Step 3: Observe the field "enable_notes": false in the JSON response.

  • Step 4: Manually change "enable_notes" to true using browser DevTools or by intercepting and modifying the response via a proxy like Burp Suite. (Please note, the occurrence of this API comes twice, hence modification needs to be made twice as well.) image

  • Step 5: Observe the loaded frontend application; the previously hidden notes form will now be visible. image

image

  • Step 6: Again, click on any note, intercept the request, and Replace the note_id in the URL with a different note ID known to belong to another user (e.g., by guessing or bruteforcing).
  • Step 7: Send the modified request while remaining logged in as User A.
  • Step 8: Observe that the server returns the content of another user's note, confirming unauthorized access. image image

Impact

  1. Unauthorized access to user-created notes
  2. Possible exposure of confidential or sensitive uploaded data
  3. Violation of user privacy and data isolation
  4. High risk of legal or compliance breaches in regulated environments

Resolution

Fixed in commit de3317e26, first released in v0.8.11 (Mar 2026). All per-id note endpoints (GET /api/v1/notes/{id}, POST /api/v1/notes/{id}/update, POST /api/v1/notes/{id}/access/update, deletion) now enforce ownership: the handler fetches the note, then requires the caller to be admin, the note owner, or have an AccessGrants grant for the appropriate permission (read for retrieval, write for mutation). A non-owner with no grant receives 403.

Users on >= 0.8.11 are not affected.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.10"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T20:27:56Z",
    "nvd_published_at": "2026-05-15T22:16:56Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe  API /api/v1/notes/{note_id} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data.\n\n### Details\n- if notes is enabled from UI (Settings \u003e\u003e General \u003e\u003e Features \u003e\u003e Notes (Beta))\n   - From API, attacker can access other user notes\n- if notes is disabled from UI (Settings \u003e\u003e General \u003e\u003e Features \u003e\u003e Notes (Beta))\n   - Then attacker can enable the notes from /api/config and access other user notes \n\n### PoC\n- Step 1: Log in to the application as a valid user (User A).\n![image](https://github.com/user-attachments/assets/3c4625f9-6e51-4cd1-942e-6a3f467520c0)\n\n- Step 2: Intercept or inspect the response from the endpoint GET /api/config.\n![image](https://github.com/user-attachments/assets/7c4fe716-314c-4640-bc9f-1e11ddc2273d)\n\n- Step 3: Observe the field \"enable_notes\": false in the JSON response.\n- Step 4: Manually change \"enable_notes\" to true using browser DevTools or by intercepting and modifying the response via a proxy like Burp Suite. (Please note, the occurrence of this API comes twice, hence modification needs to be made twice as well.)\n![image](https://github.com/user-attachments/assets/99575570-a673-4508-b149-9a2480d8f62e)\n\n- Step 5: Observe the loaded frontend application; the previously hidden notes form will now be visible.\n![image](https://github.com/user-attachments/assets/a4059b1f-2e77-4f29-88a3-431e82b7c41d)\n\n![image](https://github.com/user-attachments/assets/55e601d7-b013-43e3-a070-3a80f166e777)\n\n- Step 6: Again, click on any note, intercept the request, and Replace the note_id in the URL with a different note ID known to belong to another user (e.g., by guessing or bruteforcing).\n- Step 7: Send the modified request while remaining logged in as User A.\n- Step 8: Observe that the server returns the content of another user\u0027s note, confirming unauthorized access.\n![image](https://github.com/user-attachments/assets/cbec4ab5-a8a8-488a-a984-03e8de5b22f7)\n![image](https://github.com/user-attachments/assets/046cd925-7299-44ba-bfc3-d6e7071d29d1)\n\n\n### Impact\n1. Unauthorized access to user-created notes\n2. Possible exposure of confidential or sensitive uploaded data\n3. Violation of user privacy and data isolation\n4. High risk of legal or compliance breaches in regulated environments\n\n## Resolution\n\nFixed in commit [de3317e26](https://github.com/open-webui/open-webui/commit/de3317e26bb67a2a7ea015a183bbd1d369880ebd), first released in **v0.8.11** (Mar 2026). All per-id note endpoints (`GET /api/v1/notes/{id}`, `POST /api/v1/notes/{id}/update`, `POST /api/v1/notes/{id}/access/update`, deletion) now enforce ownership: the handler fetches the note, then requires the caller to be admin, the note owner, or have an `AccessGrants` grant for the appropriate permission (`read` for retrieval, `write` for mutation). A non-owner with no grant receives 403.\n\nUsers on `\u003e= 0.8.11` are not affected.",
  "id": "GHSA-x3qm-p8hr-3c3h",
  "modified": "2026-05-19T16:00:32Z",
  "published": "2026-05-14T20:27:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-x3qm-p8hr-3c3h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45666"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/de3317e26bb67a2a7ea015a183bbd1d369880ebd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.8.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI has an Indirect Object Reference (IDOR) in user notes"
}


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…