Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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

15215 vulnerabilities reference this CWE, most recent first.

GHSA-6C2X-GCP3-GP73

Vulnerability from github – Published: 2026-05-08 19:51 – Updated: 2026-05-15 23:52
VLAI
Summary
Open WebUI vulnerable to Global Knowledge Base Enumeration via knowledge-bases Meta-Collection
Details

Global Knowledge Base Enumeration via knowledge-bases Meta-Collection

Affected Component

Retrieval collection access validation: - backend/open_webui/routers/retrieval.py (lines 2330-2355, _validate_collection_access) - backend/open_webui/routers/retrieval.py (query endpoints, e.g. POST /query/doc)

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions with the knowledge base subsystem.

Description

The _validate_collection_access function uses an incomplete allowlist that only enforces ownership checks for collections matching user-memory-* and file-* patterns. All other collection names pass through unchecked — including the system-level knowledge-bases meta-collection, which stores the IDs, names, and descriptions of every knowledge base on the instance.

Any authenticated user can query this meta-collection directly via the retrieval query endpoints to obtain a global index of all knowledge bases across all users.

# retrieval.py:2330-2355 — incomplete collection allowlist
def _validate_collection_access(user, collection_name, ...):
    if collection_name.startswith('user-memory-'):
        # Check user-memory ownership
        ...
    elif collection_name.startswith('file-'):
        # Check file access
        ...
    # Everything else (including "knowledge-bases") passes through unchecked

This finding is the enabler for the KB destruction (process/web), KB content injection (process/file), and RAG vector search access bypass findings — all of which require knowing a target KB's UUID. Without this enumeration, UUIDs are random and practically unguessable; with it, UUIDs across the entire instance are trivially obtained.

CVSS 3.1 Breakdown

Metric Value Rationale
Attack Vector Network (N) Exploited remotely via API call
Attack Complexity Low (L) Single API call
Privileges Required Low (L) Requires any authenticated user account
User Interaction None (N) No victim interaction required
Scope Unchanged (U) Impact within the knowledge base boundary
Confidentiality Low (L) Discloses KB metadata (IDs, names, descriptions) across all users
Integrity None (N) No direct data modification
Availability None (N) No denial of service

Attack Scenario

  1. Attacker (any authenticated user) sends: POST /api/v1/retrieval/query/doc { "collection_name": "knowledge-bases", "query": "confidential" }
  2. _validate_collection_access does not recognize the knowledge-bases prefix and lets the request pass.
  3. The vector search returns the most relevant documents from the meta-collection — knowledge base records including their UUIDs, names, and descriptions — across all users on the instance.
  4. Attacker varies the query to enumerate more KBs: "project", "internal", "private", etc.
  5. Attacker now has a full target list for subsequent attacks (destruction, poisoning, content extraction).

Impact

  • Information disclosure: KB names and descriptions may reveal sensitive project names, internal initiatives, or user activities
  • Enabler for other attacks: Unlocks the following findings by supplying the required target UUIDs:
  • KB destruction/poisoning via process/web
  • Cross-user content injection via process/file
  • RAG vector search access bypass in retrieval/utils.py
  • Transforms these from theoretical (requires UUID guessing) to trivially exploitable (UUIDs enumerable)

Preconditions

  • Attacker must have a valid user account
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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-44557"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T19:51:33Z",
    "nvd_published_at": "2026-05-15T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "# Global Knowledge Base Enumeration via knowledge-bases Meta-Collection\n\n## Affected Component\n\nRetrieval collection access validation:\n- `backend/open_webui/routers/retrieval.py` (lines 2330-2355, `_validate_collection_access`)\n- `backend/open_webui/routers/retrieval.py` (query endpoints, e.g. `POST /query/doc`)\n\n## Affected Versions\n\nCurrent main branch (commit `6fdd19bf1`) and likely all versions with the knowledge base subsystem.\n\n## Description\n\nThe `_validate_collection_access` function uses an incomplete allowlist that only enforces ownership checks for collections matching `user-memory-*` and `file-*` patterns. All other collection names pass through unchecked \u2014 including the system-level `knowledge-bases` meta-collection, which stores the IDs, names, and descriptions of every knowledge base on the instance.\n\nAny authenticated user can query this meta-collection directly via the retrieval query endpoints to obtain a global index of all knowledge bases across all users.\n\n```python\n# retrieval.py:2330-2355 \u2014 incomplete collection allowlist\ndef _validate_collection_access(user, collection_name, ...):\n    if collection_name.startswith(\u0027user-memory-\u0027):\n        # Check user-memory ownership\n        ...\n    elif collection_name.startswith(\u0027file-\u0027):\n        # Check file access\n        ...\n    # Everything else (including \"knowledge-bases\") passes through unchecked\n```\n\nThis finding is the enabler for the KB destruction (`process/web`), KB content injection (`process/file`), and RAG vector search access bypass findings \u2014 all of which require knowing a target KB\u0027s UUID. Without this enumeration, UUIDs are random and practically unguessable; with it, UUIDs across the entire instance are trivially obtained.\n\n## CVSS 3.1 Breakdown\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network (N) | Exploited remotely via API call |\n| Attack Complexity | Low (L) | Single API call |\n| Privileges Required | Low (L) | Requires any authenticated user account |\n| User Interaction | None (N) | No victim interaction required |\n| Scope | Unchanged (U) | Impact within the knowledge base boundary |\n| Confidentiality | Low (L) | Discloses KB metadata (IDs, names, descriptions) across all users |\n| Integrity | None (N) | No direct data modification |\n| Availability | None (N) | No denial of service |\n\n## Attack Scenario\n\n1. Attacker (any authenticated user) sends:\n   ```\n   POST /api/v1/retrieval/query/doc\n   {\n     \"collection_name\": \"knowledge-bases\",\n     \"query\": \"confidential\"\n   }\n   ```\n2. `_validate_collection_access` does not recognize the `knowledge-bases` prefix and lets the request pass.\n3. The vector search returns the most relevant documents from the meta-collection \u2014 knowledge base records including their UUIDs, names, and descriptions \u2014 across all users on the instance.\n4. Attacker varies the query to enumerate more KBs: `\"project\"`, `\"internal\"`, `\"private\"`, etc.\n5. Attacker now has a full target list for subsequent attacks (destruction, poisoning, content extraction).\n\n## Impact\n\n- **Information disclosure:** KB names and descriptions may reveal sensitive project names, internal initiatives, or user activities\n- **Enabler for other attacks:** Unlocks the following findings by supplying the required target UUIDs:\n  - KB destruction/poisoning via `process/web`\n  - Cross-user content injection via `process/file`\n  - RAG vector search access bypass in `retrieval/utils.py`\n- Transforms these from theoretical (requires UUID guessing) to trivially exploitable (UUIDs enumerable)\n\n## Preconditions\n\n- Attacker must have a valid user account",
  "id": "GHSA-6c2x-gcp3-gp73",
  "modified": "2026-05-15T23:52:57Z",
  "published": "2026-05-08T19:51:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-6c2x-gcp3-gp73"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44557"
    },
    {
      "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:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI vulnerable to Global Knowledge Base Enumeration via knowledge-bases Meta-Collection"
}

GHSA-6C37-PJH3-94V6

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

Missing Authorization vulnerability in enituretechnology Small Package Quotes – Worldwide Express Edition allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Small Package Quotes – Worldwide Express Edition: from n/a through 5.2.19.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-30915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-03T14:15:34Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in enituretechnology Small Package Quotes \u2013 Worldwide Express Edition allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Small Package Quotes \u2013 Worldwide Express Edition: from n/a through 5.2.19.",
  "id": "GHSA-6c37-pjh3-94v6",
  "modified": "2026-04-01T18:34:27Z",
  "published": "2025-04-03T15:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30915"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/small-package-quotes-wwe-edition/vulnerability/wordpress-small-package-quotes-worldwide-express-edition-plugin-5-2-19-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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6C3H-GXFP-37VM

Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-20 18:31
VLAI
Details

Missing Authorization vulnerability in cmsmasters CMSMasters Content Composer cmsmasters-content-composer allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CMSMasters Content Composer: from n/a through <= 2.5.8.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-23547"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-19T09:16:12Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in cmsmasters CMSMasters Content Composer cmsmasters-content-composer allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CMSMasters Content Composer: from n/a through \u003c= 2.5.8.",
  "id": "GHSA-6c3h-gxfp-37vm",
  "modified": "2026-02-20T18:31:27Z",
  "published": "2026-02-19T18:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23547"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/cmsmasters-content-composer/vulnerability/wordpress-cmsmasters-content-composer-plugin-2-5-8-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6C46-P6J5-3F49

Vulnerability from github – Published: 2026-01-13 20:37 – Updated: 2026-01-13 20:37
VLAI
Summary
TYPO3 CMS Allows Broken Access Control in Redirects Module
Details

Problem

Backend users with access to the redirects module and write permission on the sys_redirect table were able to read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

Solution

Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

Credits

Thanks to Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

References

Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 14.0.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0.0"
            },
            {
              "fixed": "14.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 13.4.22"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.0.0"
            },
            {
              "fixed": "13.4.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.4.40"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.4.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.5.48"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.5.49"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.4.54"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.55"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-13T20:37:37Z",
    "nvd_published_at": "2026-01-13T12:15:50Z",
    "severity": "MODERATE"
  },
  "details": "### Problem\nBackend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user\u2019s own file\u2011mounts or web\u2011mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.\n\n### Solution\nUpdate to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.\n\n### Credits\nThanks to Georg D\u00fcmmler for reporting this issue, and to TYPO3 security team member Elias H\u00e4u\u00dfler for fixing it.\n\n### References\n* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)",
  "id": "GHSA-6c46-p6j5-3f49",
  "modified": "2026-01-13T20:37:37Z",
  "published": "2026-01-13T20:37:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-6c46-p6j5-3f49"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59021"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/8a46abd8993e3a5a31a834dcd6c8f91adef57ce4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/bac370df5c1c3fcf5ebc1c030fbd2bec86d6a686"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/fbbae3b9a40d0420207ef7af990cdf1ac0612c0b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TYPO3/typo3"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2026-002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "TYPO3 CMS Allows Broken Access Control in Redirects Module"
}

GHSA-6C4C-5HCJ-J9PJ

Vulnerability from github – Published: 2024-06-12 09:30 – Updated: 2024-06-12 09:30
VLAI
Details

Missing Authorization vulnerability in Brett Shumaker Simple Staff List.This issue affects Simple Staff List: from n/a through 2.2.4.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-51526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-12T09:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Brett Shumaker Simple Staff List.This issue affects Simple Staff List: from n/a through 2.2.4.",
  "id": "GHSA-6c4c-5hcj-j9pj",
  "modified": "2024-06-12T09:30:48Z",
  "published": "2024-06-12T09:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51526"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/simple-staff-list/wordpress-simple-staff-list-plugin-2-2-4-broken-access-control-vulnerability?_s_id=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"
    }
  ]
}

GHSA-6C66-33PW-Q83J

Vulnerability from github – Published: 2026-06-11 12:32 – Updated: 2026-06-11 12:32
VLAI
Details

A Missing Authorization vulnerability in the playbook import functionality in Dialogflow CX on Google Cloud Platform allows an authenticated user with specific roles to escalate privileges and potentially take over a GCP project using a maliciously crafted playbook import.

This vulnerability was patched on 15 March 2026, and no customer action is needed.

Severity
9.4 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/U:Clear
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-11T12:16:31Z",
    "severity": "CRITICAL"
  },
  "details": "A Missing Authorization vulnerability in the playbook import functionality in Dialogflow CX on Google Cloud Platform allows an authenticated user with specific roles to escalate privileges and potentially take over a GCP project using a maliciously crafted playbook import.\n\n\nThis vulnerability was patched on 15 March 2026, and no customer action is needed.",
  "id": "GHSA-6c66-33pw-q83j",
  "modified": "2026-06-11T12:32:44Z",
  "published": "2026-06-11T12:32:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4764"
    },
    {
      "type": "WEB",
      "url": "https://docs.cloud.google.com/dialogflow/docs/release-notes#May_07_2026"
    }
  ],
  "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:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Clear",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6C6R-5XR4-CR5M

Vulnerability from github – Published: 2026-07-21 20:22 – Updated: 2026-07-21 20:22
VLAI
Summary
Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content
Details

Summary

Gitea's issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker's repository authorization context.

Affected

  • Component: web issue/comment attachment handling.
  • Confirmed version: main commit a39b2775edcb3ba53def96794491b91335117d81 (v1.27.0-dev-352-ga39b2775ed).
  • Fixed in: not fixed at the time of validation.
  • Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic.

Description / Root Cause

files[] values from issue/comment edit flows are passed to updateAttachments in routers/web/repo/issue.go:589-629. That helper calls:

  • models/issues/issue_update.go:267-278 (UpdateIssueAttachments)
  • models/issues/comment.go:623-642 (UpdateCommentAttachments)

Both functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row's RepoID matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.

Attachment reads then use the linked issue/release repository to decide access:

  • services/repository/repository.go:185-207 returns the repository ID from IssueID or ReleaseID.
  • routers/web/repo/attachment.go:153-184 checks read permission on that linked repository.
  • routers/web/repo/attachment.go:216-224 opens and serves the file from the attachment's storage path after the linked-repository permission check succeeds.

For the global /attachments/{uuid} route in routers/web/web.go:872-876, there is no current repository context, so the early attach.RepoID mismatch check in ServeAttachment does not protect against this re-linking case.

A patched sibling path already demonstrates the intended invariant: models/repo/release.go:179-215 rejects release attachments whose RepoID differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.

Impact

An attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository's authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.

This can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.

Reproduction Summary

Full HTTP/E2E observation:

  • A local Gitea server was started with an isolated SQLite database.
  • A victim user created private repositories, private issues, and issue attachments containing unique marker strings.
  • An attacker user first attempted to download each victim attachment through /attachments/{uuid} and received 404.
  • The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.
  • The same attacker could then download the victim issue attachment through /attachments/{uuid} and received 200; the response body contained the unique issue marker.
  • The attacker repeated the flow through the real comment edit route and could download the second victim attachment with 200; the response body contained the unique comment marker.

Model-level issue-path behavior:

  • A fixture attachment with RepoID = 2 and IssueID = 4 was passed to UpdateIssueAttachments for attacker issue ID = 1, whose RepoID = 1.
  • The call succeeded.
  • The attachment row still had RepoID = 2, but its IssueID was changed to the attacker issue.
  • GetAttachmentLinkedTypeAndRepoID then resolved the attachment to attacker repository RepoID = 1.

Model-level comment-path behavior:

  • The same cross-repository attachment UUID was passed to UpdateCommentAttachments for attacker comment ID = 1.
  • The call succeeded.
  • The attachment row still had RepoID = 2, but its IssueID and CommentID were changed to the attacker's issue/comment.
  • The linked repository used for access checks became attacker repository RepoID = 1.

Negative control:

  • Existing release test TestAddReleaseAttachmentsRejectsDifferentRepo passes and confirms the release path rejects the same class of cross-repository attachment linkage.

Detailed verifier and step-by-step runbook are available on request.

Suggested Fix

Add repository and linkage validation before updating issue/comment attachments.

Recommended checks:

  • Load the target issue for UpdateIssueAttachments and derive its RepoID.
  • Load the target comment's issue for UpdateCommentAttachments and derive its RepoID.
  • Reject any attachment whose RepoID differs from the target issue repository.
  • Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.
  • If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.
  • Preserve any legacy RepoID = 0 migration behavior only when it can be proven safe for the target repository.

Also consider a cleanup/audit query for existing inconsistent rows where attachment.issue_id != 0 and attachment.repo_id differs from the linked issue repository.

Regression Tests

Add tests that fail before the fix and pass after it:

  • UpdateIssueAttachments rejects an attachment whose RepoID differs from the target issue's RepoID.
  • UpdateCommentAttachments rejects an attachment whose RepoID differs from the target comment issue's RepoID.
  • Same-repository unlinked attachment linking still works for normal issue/comment editing.
  • Attachments already linked to a different issue/comment cannot be moved by passing their UUID in files[].
  • Existing release guard test remains passing.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:22:58Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGitea\u0027s issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker\u0027s repository authorization context.\n\n## Affected\n\n- Component: web issue/comment attachment handling.\n- Confirmed version: `main` commit `a39b2775edcb3ba53def96794491b91335117d81` (`v1.27.0-dev-352-ga39b2775ed`).\n- Fixed in: not fixed at the time of validation.\n- Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic.\n\n## Description / Root Cause\n\n`files[]` values from issue/comment edit flows are passed to `updateAttachments` in `routers/web/repo/issue.go:589-629`. That helper calls:\n\n- `models/issues/issue_update.go:267-278` (`UpdateIssueAttachments`)\n- `models/issues/comment.go:623-642` (`UpdateCommentAttachments`)\n\nBoth functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row\u0027s `RepoID` matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.\n\nAttachment reads then use the linked issue/release repository to decide access:\n\n- `services/repository/repository.go:185-207` returns the repository ID from `IssueID` or `ReleaseID`.\n- `routers/web/repo/attachment.go:153-184` checks read permission on that linked repository.\n- `routers/web/repo/attachment.go:216-224` opens and serves the file from the attachment\u0027s storage path after the linked-repository permission check succeeds.\n\nFor the global `/attachments/{uuid}` route in `routers/web/web.go:872-876`, there is no current repository context, so the early `attach.RepoID` mismatch check in `ServeAttachment` does not protect against this re-linking case.\n\nA patched sibling path already demonstrates the intended invariant: `models/repo/release.go:179-215` rejects release attachments whose `RepoID` differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.\n\n## Impact\n\nAn attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository\u0027s authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.\n\nThis can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.\n\n## Reproduction Summary\n\nFull HTTP/E2E observation:\n\n- A local Gitea server was started with an isolated SQLite database.\n- A victim user created private repositories, private issues, and issue attachments containing unique marker strings.\n- An attacker user first attempted to download each victim attachment through `/attachments/{uuid}` and received `404`.\n- The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.\n- The same attacker could then download the victim issue attachment through `/attachments/{uuid}` and received `200`; the response body contained the unique issue marker.\n- The attacker repeated the flow through the real comment edit route and could download the second victim attachment with `200`; the response body contained the unique comment marker.\n\nModel-level issue-path behavior:\n\n- A fixture attachment with `RepoID = 2` and `IssueID = 4` was passed to `UpdateIssueAttachments` for attacker issue `ID = 1`, whose `RepoID = 1`.\n- The call succeeded.\n- The attachment row still had `RepoID = 2`, but its `IssueID` was changed to the attacker issue.\n- `GetAttachmentLinkedTypeAndRepoID` then resolved the attachment to attacker repository `RepoID = 1`.\n\nModel-level comment-path behavior:\n\n- The same cross-repository attachment UUID was passed to `UpdateCommentAttachments` for attacker comment `ID = 1`.\n- The call succeeded.\n- The attachment row still had `RepoID = 2`, but its `IssueID` and `CommentID` were changed to the attacker\u0027s issue/comment.\n- The linked repository used for access checks became attacker repository `RepoID = 1`.\n\nNegative control:\n\n- Existing release test `TestAddReleaseAttachmentsRejectsDifferentRepo` passes and confirms the release path rejects the same class of cross-repository attachment linkage.\n\nDetailed verifier and step-by-step runbook are available on request.\n\n## Suggested Fix\n\nAdd repository and linkage validation before updating issue/comment attachments.\n\nRecommended checks:\n\n- Load the target issue for `UpdateIssueAttachments` and derive its `RepoID`.\n- Load the target comment\u0027s issue for `UpdateCommentAttachments` and derive its `RepoID`.\n- Reject any attachment whose `RepoID` differs from the target issue repository.\n- Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.\n- If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.\n- Preserve any legacy `RepoID = 0` migration behavior only when it can be proven safe for the target repository.\n\nAlso consider a cleanup/audit query for existing inconsistent rows where `attachment.issue_id != 0` and `attachment.repo_id` differs from the linked issue repository.\n\n## Regression Tests\n\nAdd tests that fail before the fix and pass after it:\n\n- `UpdateIssueAttachments` rejects an attachment whose `RepoID` differs from the target issue\u0027s `RepoID`.\n- `UpdateCommentAttachments` rejects an attachment whose `RepoID` differs from the target comment issue\u0027s `RepoID`.\n- Same-repository unlinked attachment linking still works for normal issue/comment editing.\n- Attachments already linked to a different issue/comment cannot be moved by passing their UUID in `files[]`.\n- Existing release guard test remains passing.",
  "id": "GHSA-6c6r-5xr4-cr5m",
  "modified": "2026-07-21T20:22:58Z",
  "published": "2026-07-21T20:22:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-6c6r-5xr4-cr5m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content"
}

GHSA-6CC3-6HQ4-GC95

Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-26 21:30
VLAI
Details

Missing Authorization vulnerability in Brecht WP Recipe Maker wp-recipe-maker allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Recipe Maker: from n/a through <= 10.2.4.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-24357"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:39Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in Brecht WP Recipe Maker wp-recipe-maker allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Recipe Maker: from n/a through \u003c= 10.2.4.",
  "id": "GHSA-6cc3-6hq4-gc95",
  "modified": "2026-01-26T21:30:34Z",
  "published": "2026-01-22T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24357"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/wp-recipe-maker/vulnerability/wordpress-wp-recipe-maker-plugin-10-2-4-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6CC6-Q8X8-H7VM

Vulnerability from github – Published: 2024-02-27 06:30 – Updated: 2026-04-08 18:32
VLAI
Details

The Thank You Page Customizer for WooCommerce – Increase Your Sales plugin for WordPress is vulnerable to unauthorized execution of shortcodes due to a missing capability check on the get_text_editor_content() function in all versions up to, and including, 1.1.2. This makes it possible for authenticated attackers, with subscriber-level access and above, to execute arbitrary shortcodes.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-1687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T06:15:45Z",
    "severity": "MODERATE"
  },
  "details": "The Thank You Page Customizer for WooCommerce \u2013 Increase Your Sales plugin for WordPress is vulnerable to unauthorized execution of shortcodes due to a missing capability check on the get_text_editor_content() function in all versions up to, and including, 1.1.2. This makes it possible for authenticated attackers, with subscriber-level access and above, to execute arbitrary shortcodes.",
  "id": "GHSA-6cc6-q8x8-h7vm",
  "modified": "2026-04-08T18:32:36Z",
  "published": "2024-02-27T06:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1687"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3041096%40woo-thank-you-page-customizer\u0026new=3041096%40woo-thank-you-page-customizer\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/310afe02-3a51-4633-b359-65ae58d0c032?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:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6CCG-P595-WXJR

Vulnerability from github – Published: 2023-12-04 03:30 – Updated: 2023-12-07 00:30
VLAI
Details

In imsservice, there is a possible way to write permission usage records of an app due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-42671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-04T01:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In imsservice, there is a possible way to write permission usage records of an app due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed",
  "id": "GHSA-6ccg-p595-wxjr",
  "modified": "2023-12-07T00:30:37Z",
  "published": "2023-12-04T03:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42671"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/https://www.unisoc.com/en_us/secy/announcementDetail/1731138365803266049"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "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.

← Back to the CWE list