{
  "affected": [],
  "aliases": [
    "CVE-2020-2507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-03T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The vulnerability have been reported to affect earlier versions of QTS. If exploited, this improper access control vulnerability could allow attackers to obtain control of a QNAP device. This issue affects: QNAP Systems Inc. Helpdesk versions prior to 3.0.3.",
  "id": "GHSA-7r29-w7vh-5p6q",
  "modified": "2022-05-24T17:40:47Z",
  "published": "2022-05-24T17:40:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2507"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/zh-tw/security-advisory/qsa-20-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-26767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-26T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with additional permissions checks. This issue is fixed in macOS Monterey 12.4, macOS Big Sur 11.6.6. A malicious application may be able to bypass Privacy preferences.",
  "id": "GHSA-7r2p-p57x-pqq4",
  "modified": "2022-06-09T00:00:26Z",
  "published": "2022-05-27T00:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26767"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213256"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213257"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.32.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.32.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.43"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.34"
            },
            {
              "fixed": "2.44"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-2599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-01T18:28:34Z",
    "nvd_published_at": "2018-04-11T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins before versions 2.44 and 2.32.2 is vulnerable to an insufficient permission check. This allows users with permissions to create new items (e.g. jobs) to overwrite existing items they don\u0027t have access to (SECURITY-321).",
  "id": "GHSA-7r4h-2h23-6jq9",
  "modified": "2022-07-01T18:28:34Z",
  "published": "2022-05-13T01:12:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2599"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/4ed5c850b6855ab064a66d02fb338f366853ce89"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2599"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/jenkins"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2017-02-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in Jenkins"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-20582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-14T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Secret Server up to 11.0 stores sensitive information in URL parameters. This may lead to information disclosure if unauthorized parties have access to the URLs via server logs, referrer header or browser history. IBM X-Force ID: 199328.",
  "id": "GHSA-7r57-25xw-x723",
  "modified": "2022-07-13T00:01:05Z",
  "published": "2022-05-24T19:14:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20582"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/199328"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6488459"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "ash"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-13T13:33:22Z",
    "nvd_published_at": "2025-10-10T16:15:52Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen using **filter** authorization, two edge cases could cause the policy compiler/authorizer to generate a permissive filter:\n\n1. **Bypass policies whose condition can never pass at runtime** were compiled as\n   `OR(AND(condition, compiled_policies), NOT(condition))`.\n   If the condition could never be true at runtime, the `NOT(condition)` branch evaluated truthy and the overall expression became permissive.\n\n2. **Runtime policy scenarios that reduce to \u201cno checks are applicable\u201d** (an empty SAT scenario) were treated as an empty clause and dropped instead of being treated as **`false`**, which could again produce an overly broad (permissive) filter.\n\nThese bugs could allow reads to return records that should have been excluded by policy.\n\n### Impact\n\nProjects that rely on **filter-based authorization** and define:\n\n* `bypass ... do ... end` blocks whose condition(s) are only resolvable at runtime and can never pass in a given request context, **or**\n* runtime checks that simplify to an **empty** scenario for a clause\n\nmay unintentionally generate a permissive query filter, potentially returning unauthorized data.\n\n*Actions primarily affected:* reads guarded by filter policies. Non-filter (e.g., hard forbid) policies are not impacted.\n\n### Technical details\n\nThis patch corrects two behaviors:\n\n* **`Ash.Policy.Policy.compile_policy_expression/1`** now treats **bypass** blocks as\n  `AND(condition_expression, compiled_policies)`\n  instead of `OR(AND(...), NOT(condition_expression))`. This removes the permissive `NOT(condition)` escape hatch when a bypass condition never passes.\n\n* **`Ash.Policy.Authorizer`** now treats **empty SAT scenarios** (`scenario == %{}`) as **`false`**, ensuring impossible scenarios do not collapse into a no-op and inadvertently widen the filter. The reducer also normalizes `nil` \u2192 `false` consistently when building `auto_filter` fragments.\n\nRelevant changes are in:\n\n* `lib/ash/policy/policy.ex` (bypass compilation)\n* `lib/ash/policy/authorizer/authorizer.ex` (scenario handling / auto_filter normalization)\n* Tests added: `test/policy/filter_condition_test.exs` (`RuntimeFalsyCheck`, `RuntimeBypassResource`) validate the corrected behavior.\n\n### Workarounds\n\n* Avoid `bypass` policies whose conditions are only decidable at runtime and may be perpetually false in some contexts; prefer explicit `authorize_if`/`forbid_if` blocks without `bypass` for those cases.\n* Add an explicit **final `forbid_if always()`** guard for sensitive reads as a belt-and-suspenders fallback until user can upgrade.\n* Where feasible, replace runtime-unknown checks with strict/compile-time checks or restructure to avoid empty SAT scenarios.\n\n### How to tell if user is affected\n\nUser is likely affected if ALL of the following are true:\n\n*  Uses **filter authorization**; and\n* Defines `bypass` block with `access_type :runtime` without any policies after it; or\n* Defines `bypass` blocks whose conditions are evaluated at runtime (e.g., checks with `strict_check/3` returning `:unknown` and a runtime `check/4` that may never succeed in some contexts) without any policies after it\n\nA quick sanity test is to issue a read expected to return **no** rows under such a bypass or runtime-falsy condition and verify it indeed returns `[]`. The included test `bypass works with filter policies` demonstrates the corrected, non-permissive behavior.",
  "id": "GHSA-7r7f-9xpj-jmr7",
  "modified": "2026-04-06T23:15:07Z",
  "published": "2025-10-13T13:33:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/security/advisories/GHSA-7r7f-9xpj-jmr7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48043"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/commit/66d81300065b970da0d2f4528354835d2418c7ae"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2025-48043.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ash-project/ash"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/releases/tag/v3.6.2"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-48043"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ash Framework: Filter authorization misapplies impossible bypass/runtime policies"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T17:02:14Z",
    "nvd_published_at": "2026-07-09T17:17:02Z",
    "severity": "MODERATE"
  },
  "details": "# Open WebUI upload metadata can add files to knowledge bases without write permission\n\n## Summary\n\nOpen WebUI\u0027s file upload background processing trusts the client-supplied `metadata.knowledge_id` value and inserts a `knowledge_file` association before validating that the uploading user has write access to the target knowledge base.\n\nA verified user with only read access to a knowledge base can upload an arbitrary file and set `metadata={\"knowledge_id\":\"\u003ctarget knowledge id\u003e\"}`. The normal `/api/v1/knowledge/{id}/file/add` endpoint correctly requires knowledge-base write access, but the upload auto-link path bypasses that authorization check.\n\nThe immediate result is unauthorized modification of the target knowledge base\u0027s file membership. The attached attacker-controlled file becomes visible through `/api/v1/knowledge/{id}/files`, and readers/owners of that knowledge base can retrieve the file through the normal file endpoints because file access is derived from `KnowledgeFile` membership.\n\n## Affected Version\n\n- Repository: `open-webui/open-webui`\n- Tested source commit: `02dc3e689ceac915a870b373318b99c029ddf603`\n- Package version observed in `package.json`: `0.9.6`\n- Package name: `open-webui`\n\n## Impact\n\nA read-only knowledge-base collaborator can perform a write operation against that knowledge base by attaching arbitrary uploaded files.\n\nSecurity impact:\n\n- Unauthorized knowledge-base membership modification.\n- Integrity impact on shared knowledge-base file listings.\n- Attacker-controlled files become readable to other users who can read the target knowledge base.\n- If an owner/admin later reprocesses or globally reindexes the knowledge base, the unauthorized file can be indexed into the knowledge collection, turning the membership bypass into RAG/content poisoning.\n\nThis is not an unauthenticated issue. It requires a verified Open WebUI account and a valid target knowledge-base ID. The clearest exploit path is a user who legitimately has read access to a knowledge base but not write access.\n\n## Source Evidence\n\nThe normal single-file knowledge add endpoint checks write permission before processing or inserting the relationship:\n\n- `backend/open_webui/routers/knowledge.py`\n- `add_file_to_knowledge_by_id`\n- Lines 714-728 reject callers who are not owner, admin, or granted `write` access.\n- Lines 750-766 then process and insert the file only after that authorization gate.\n\nThe upload auto-link path does not perform the same check:\n\n- `backend/open_webui/routers/files.py`\n- `process_uploaded_file`\n- Lines 178-186 read `knowledge_id` from upload metadata and immediately call `Knowledges.add_file_to_knowledge_by_id(...)`.\n- Lines 187-192 call `process_file(... collection_name=knowledge_id ...)` after the insert.\n\nThe model method inserts the relationship without validating the caller\u0027s write access to the knowledge base:\n\n- `backend/open_webui/models/knowledge.py`\n- `add_file_to_knowledge_by_id`\n- Lines 646-677 create and commit a `KnowledgeFile` row for the supplied `knowledge_id`, `file_id`, and `user_id`.\n\nThe later vector write check exists, but it runs too late:\n\n- `backend/open_webui/routers/retrieval.py`\n- `process_file`\n- Lines 1587-1592 call `_validate_collection_access(..., access_type=\u0027write\u0027)` when a collection is supplied.\n\nBecause the unauthorized `KnowledgeFile` row is already committed before that check runs, the failed vector processing does not undo the knowledge-base file association. The upload code catches the exception at `backend/open_webui/routers/files.py` lines 194-195 and logs a warning while leaving the row in place.\n\nThe unauthorized relationship affects file access decisions:\n\n- `backend/open_webui/utils/access_control/files.py`\n- `has_access_to_file`\n- Lines 41-53 grant file access when a file is associated with a knowledge base the user can access.\n\nSo once the attacker\u0027s file is inserted into the target `KnowledgeFile` table, target knowledge-base readers/owners can see and fetch that file through normal knowledge/file routes.\n\n## Reproduction Steps\n\nUse a local Open WebUI instance with two verified users:\n\n1. As user `owner`, create a knowledge base.\n2. Grant user `reader` read access to the knowledge base, but do not grant write access.\n3. As `reader`, confirm the normal add-file endpoint is blocked:\n\n```http\nPOST /api/v1/knowledge/\u003cknowledge_id\u003e/file/add\nAuthorization: Bearer \u003creader token\u003e\nContent-Type: application/json\n\n{\"file_id\":\"\u003creader-owned-file-id\u003e\"}\n```\n\nExpected and observed behavior for the normal route: it rejects the request because `reader` lacks knowledge-base write access.\n\n4. As `reader`, upload a new file with the same target knowledge ID embedded in upload metadata:\n\n```http\nPOST /api/v1/files/?process=true\u0026process_in_background=false\nAuthorization: Bearer \u003creader token\u003e\nContent-Type: multipart/form-data\n\nfile=@attacker-note.txt\nmetadata={\"knowledge_id\":\"\u003cknowledge_id\u003e\"}\n```\n\n5. Observe that the upload request succeeds and returns the uploaded file record.\n6. As `owner`, request the knowledge-base files:\n\n```http\nGET /api/v1/knowledge/\u003cknowledge_id\u003e/files\nAuthorization: Bearer \u003cowner token\u003e\n```\n\n7. Observe that `attacker-note.txt` appears in the target knowledge base even though `reader` did not have write access.\n8. As `owner`, request the file content:\n\n```http\nGET /api/v1/files/\u003cattacker_file_id\u003e/content\nAuthorization: Bearer \u003cowner token\u003e\n```\n\n9. Observe that the file is retrievable because `has_access_to_file` derives access from the unauthorized knowledge-base membership.\n\n## Expected Behavior\n\nThe upload auto-link path should enforce the same authorization contract as `/api/v1/knowledge/{id}/file/add`:\n\n- The target knowledge base must exist.\n- The caller must be the knowledge owner, an admin, or have `write` access.\n- The supplied `directory_id`, if present, must belong to the target knowledge base.\n- The `KnowledgeFile` association should only be inserted after authorization and processing succeed.\n\n## Actual Behavior\n\n`metadata.knowledge_id` causes `Knowledges.add_file_to_knowledge_by_id(...)` to insert a `KnowledgeFile` row before write authorization is checked. The later collection write validation can fail, but the unauthorized membership row remains committed.\n\n## Suggested Fix\n\nMove knowledge-base authorization before the insert in the upload auto-link path. The upload path should share the same write-access and directory validation logic used by the dedicated knowledge endpoints.\n\nOne safe pattern:\n\n1. Load the target knowledge base.\n2. Require owner/admin/write access before calling `Knowledges.add_file_to_knowledge_by_id`.\n3. Validate that `directory_id`, if supplied, belongs to the same knowledge base.\n4. Run vector processing before inserting the membership row, or wrap processing plus insertion in a transaction/compensating cleanup so a denied or failed process cannot leave a stale unauthorized row.",
  "id": "GHSA-7r7x-gjvr-448g",
  "modified": "2026-07-24T17:02:14Z",
  "published": "2026-07-24T17:02:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-7r7x-gjvr-448g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/26001"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/b7626f05fb92b24ab923ad81a037071ebd5623d1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-57728"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-20T10:15:30Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains IntelliJ IDEA before 2025.2 improper access control allowed Code With Me guest to discover hidden files",
  "id": "GHSA-7r83-p869-7995",
  "modified": "2025-08-20T12:31:14Z",
  "published": "2025-08-20T12:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57728"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-22521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-30T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "A privileged escalation vulnerability has been identified in Micro Focus ZENworks Configuration Management, affecting version 2020 Update 1 and all prior versions. The vulnerability could be exploited to gain unauthorized system privileges.",
  "id": "GHSA-7r86-h946-g8h2",
  "modified": "2022-05-24T19:09:19Z",
  "published": "2022-05-24T19:09:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22521"
    },
    {
      "type": "WEB",
      "url": "https://support.microfocus.com/kb/doc.php?id=7025205"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-4242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-09T04:15:10Z",
    "severity": "MODERATE"
  },
  "details": "The FULL - Customer plugin for WordPress is vulnerable to Information Disclosure via the /health REST route in versions up to, and including, 2.2.3 due to improper authorization. This allows authenticated attackers with subscriber-level permissions and above to obtain sensitive information about the site configuration as disclosed by the WordPress health check.",
  "id": "GHSA-7rj5-723h-386q",
  "modified": "2026-04-08T21:31:59Z",
  "published": "2023-08-09T06:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4242"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/full-customer/tags/1.1.0/app/api/Health.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/full-customer/tags/2.3/app/api/Controller.php?rev=2951561"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a77d0fb5-8829-407d-a40a-169cf0c5f837?source=cve"
    }
  ],
  "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"
    }
  ]
}

{
  "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-44558"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T19:50:51Z",
    "nvd_published_at": "2026-05-15T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "# Channel Access Grants Bypass filter_allowed_access_grants\n\n## Affected Component\n\nChannel creation and update endpoints:\n- `backend/open_webui/routers/channels.py` (lines 291-340, `create_new_channel`)\n- `backend/open_webui/routers/channels.py` (lines 617-638, `update_channel_by_id`)\n- `backend/open_webui/models/channels.py` (lines 825-826, `set_access_grants` call without filtering)\n\n## Affected Versions\n\nCurrent main branch (commit `6fdd19bf1`) and likely all versions supporting user-created group channels with access grants.\n\n## Description\n\nAll resource routers in Open WebUI (knowledge, models, notes, prompts, tools, skills) call `filter_allowed_access_grants()` before persisting access grants. This function strips `principal_id: \"*\"` wildcard grants from users who lack the relevant `sharing.public_*` permission, and strips individual user grants from users who lack `access_grants.allow_users` permission.\n\nThe channel router does not call `filter_allowed_access_grants` on either create or update paths. A non-admin user who can create group channels (or who owns a channel) can submit arbitrary access grants \u2014 including public wildcard grants \u2014 and those grants are stored verbatim, bypassing the admin\u0027s permission framework.\n\n```python\n# channels.py \u2014 access_grants from form data flow directly into persistence\n# No call to filter_allowed_access_grants() anywhere in these paths.\n\n# Compare with knowledge.py / models.py / notes.py / prompts.py / tools.py / skills.py,\n# all of which do:\n#     form_data.access_grants = filter_allowed_access_grants(user, form_data.access_grants)\n# before creating or updating.\n```\n\n## Attack Scenario\n\n1. Admin configures permissions so that regular users do NOT have `sharing.public_channels` \u2014 public sharing of channels is intended to be admin-only.\n2. Attacker (a regular user) creates or owns a group channel.\n3. Attacker sends:\n   ```\n   POST /api/v1/channels/\n   {\n     \"name\": \"public-channel\",\n     \"type\": \"group\",\n     \"access_control\": {\n       \"access_grants\": [\n         {\"principal_type\": \"user\", \"principal_id\": \"*\", \"permission\": \"read\"}\n       ]\n     }\n   }\n   ```\n4. `set_access_grants` is called directly without `filter_allowed_access_grants` \u2014 the wildcard grant is persisted.\n5. The channel becomes publicly readable to every user on the instance, despite the admin\u0027s policy prohibiting public channels for regular users.\n\nThe same attack works via `POST /api/v1/channels/{id}/update` for any channel the attacker owns.\n\n## Impact\n\n- Regular users can bypass the `sharing.public_channels` permission and make channels publicly accessible\n- Regular users can bypass `access_grants.allow_users` to grant individual-user access in environments where only group-based sharing is intended\n- Admin\u0027s permission framework for channels is silently ineffective\n- Creates an inconsistency with every other resource type in the codebase, making the security posture harder to reason about\n\n## Preconditions\n\n- Attacker must have an account with the ability to create group channels (default user capability), or ownership of an existing channel\n- Admin must have configured restrictive sharing permissions for regular users (otherwise there\u0027s no policy to bypass)",
  "id": "GHSA-7rjh-px4v-5w55",
  "modified": "2026-05-15T23:52:41Z",
  "published": "2026-05-08T19:50:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-7rjh-px4v-5w55"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44558"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI\u0027s Channel Access Grants Bypass filter_allowed_access_grants"
}