Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

6979 vulnerabilities reference this CWE, most recent first.

GHSA-CQ3F-VC6P-68FH

Vulnerability from github – Published: 2026-06-04 14:55 – Updated: 2026-06-09 11:58
VLAI
Summary
Better Auth: Device authorization approve and deny accept any authenticated session while the user code is pending
Details

Am I affected?

You are affected if all of the following are true:

  • You use better-auth at a version >= 1.6.0, < 1.6.11.
  • The deviceAuthorization plugin is enabled in your auth config (deviceAuthorization() in your plugins array).
  • A third party can observe a pending user code before the legitimate user completes verification.

The standard device-flow UX displays user codes to humans, so realistic exposure includes shoulder-surfing, screen-share, voice or video calls, support-chat transcripts, referrer headers, and shared logs.

If your application does not enable the deviceAuthorization plugin, you are not affected.

Fix:

  1. Upgrade to better-auth@1.6.11 or later.
  2. If you cannot upgrade, see workarounds below.

Summary

Better Auth's deviceAuthorization plugin treated any authenticated session as the owner of any pending device code. The ownership gate on POST /device/approve and POST /device/deny short-circuited whenever the row's userId was unset, and the GET /device verification handler did not claim the row. An authenticated attacker who learned a valid user_code before the legitimate user completed approval could bind the polling device to the attacker's account or deny the legitimate flow.

Details

The device authorization flow binds the polling device to the user who entered the user code on the verification page. In affected versions, the plugin only created that binding at approve or deny time, with no claim at the verification step. The ownership check at approve and deny short-circuited when the owner was missing, accepting any authenticated caller instead of rejecting the request.

The fix changes GET /device to claim the pending row for the calling session. The approve and deny gates now require strict equality between the row's owner and the calling session. RFC 8628 §5.5 covers this risk class as Session Spying: a malicious party can hijack a session by completing authorization before the legitimate initiating user does.

Patches

Fixed in better-auth@1.6.11. After the patch, GET /device claims the pending row for the calling session, and POST /device/approve and POST /device/deny reject calls whose session does not match the claimed owner. Custom verification pages must serve GET /device to an authenticated session for the flow to succeed.

Workarounds

If you cannot upgrade immediately:

  • Disable the plugin if you do not use the device flow: remove deviceAuthorization() from your plugins array.
  • Add a before hook on POST /device/approve and POST /device/deny that tracks which session called GET /device for each user code, and rejects calls from a different session.
  • Shorten the pending lifetime of device codes via the expiresIn plugin option to reduce the exploitation window.

Impact

  • Account takeover on the polling device: the attacker's session becomes the device's session, so the device operates as the attacker.
  • Denial of the legitimate sign-in: the attacker can mark the code as denied, blocking the victim's flow.

Credit

Reported by Quikturn Security Team.

References

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45337"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-345",
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T14:55:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\nYou are affected if all of the following are true:\n\n- You use `better-auth` at a version `\u003e= 1.6.0, \u003c 1.6.11`.\n- The `deviceAuthorization` plugin is enabled in your auth config (`deviceAuthorization()` in your `plugins` array).\n- A third party can observe a pending user code before the legitimate user completes verification.\n\nThe standard device-flow UX displays user codes to humans, so realistic exposure includes shoulder-surfing, screen-share, voice or video calls, support-chat transcripts, referrer headers, and shared logs.\n\nIf your application does not enable the `deviceAuthorization` plugin, you are not affected.\n\nFix:\n\n1. Upgrade to `better-auth@1.6.11` or later.\n2. If you cannot upgrade, see workarounds below.\n\n### Summary\n\nBetter Auth\u0027s `deviceAuthorization` plugin treated any authenticated session as the owner of any pending device code. The ownership gate on `POST /device/approve` and `POST /device/deny` short-circuited whenever the row\u0027s `userId` was unset, and the `GET /device` verification handler did not claim the row. An authenticated attacker who learned a valid `user_code` before the legitimate user completed approval could bind the polling device to the attacker\u0027s account or deny the legitimate flow.\n\n### Details\n\nThe device authorization flow binds the polling device to the user who entered the user code on the verification page. In affected versions, the plugin only created that binding at approve or deny time, with no claim at the verification step. The ownership check at approve and deny short-circuited when the owner was missing, accepting any authenticated caller instead of rejecting the request.\n\nThe fix changes `GET /device` to claim the pending row for the calling session. The approve and deny gates now require strict equality between the row\u0027s owner and the calling session. RFC 8628 \u00a75.5 covers this risk class as Session Spying: a malicious party can hijack a session by completing authorization before the legitimate initiating user does.\n\n### Patches\n\nFixed in `better-auth@1.6.11`. After the patch, `GET /device` claims the pending row for the calling session, and `POST /device/approve` and `POST /device/deny` reject calls whose session does not match the claimed owner. Custom verification pages must serve `GET /device` to an authenticated session for the flow to succeed.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- **Disable the plugin** if you do not use the device flow: remove `deviceAuthorization()` from your `plugins` array.\n- **Add a `before` hook** on `POST /device/approve` and `POST /device/deny` that tracks which session called `GET /device` for each user code, and rejects calls from a different session.\n- **Shorten the pending lifetime of device codes** via the `expiresIn` plugin option to reduce the exploitation window.\n\n### Impact\n\n- **Account takeover on the polling device**: the attacker\u0027s session becomes the device\u0027s session, so the device operates as the attacker.\n- **Denial of the legitimate sign-in**: the attacker can mark the code as denied, blocking the victim\u0027s flow.\n\n### Credit\n\nReported by Quikturn Security Team.\n\n### References\n\n- [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html)\n- [CWE-863: Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html)\n- [CWE-639: Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html)\n- [RFC 8628 \u00a75.5: Session Spying](https://datatracker.ietf.org/doc/html/rfc8628#section-5.5)",
  "id": "GHSA-cq3f-vc6p-68fh",
  "modified": "2026-06-09T11:58:19Z",
  "published": "2026-06-04T14:55:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-cq3f-vc6p-68fh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/pull/9573"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Better Auth: Device authorization approve and deny accept any authenticated session while the user code is pending"
}

GHSA-CQ7V-6GR4-8HX4

Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-09-05 18:31
VLAI
Details

NVIDIA ConnectX contains a vulnerability in the management interface, where an attacker with local access could cause incorrect authorization to modify the configuration. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, and data tampering.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-23262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T16:15:34Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA ConnectX contains a vulnerability in the management interface, where an attacker with local access could cause incorrect authorization to modify the configuration. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, and data tampering.",
  "id": "GHSA-cq7v-6gr4-8hx4",
  "modified": "2025-09-05T18:31:15Z",
  "published": "2025-09-05T18:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23262"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5655"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-23262"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CQC8-8583-C382

Vulnerability from github – Published: 2025-01-28 18:31 – Updated: 2025-01-28 18:31
VLAI
Details

A privilege escalation vulnerability exists in the web-based management interface of HPE Aruba Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to change the state of certain settings of a vulnerable system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-23053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-28T18:15:38Z",
    "severity": "MODERATE"
  },
  "details": "A privilege escalation vulnerability exists in the web-based management interface of HPE Aruba Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to change the state of certain settings of a vulnerable system.",
  "id": "GHSA-cqc8-8583-c382",
  "modified": "2025-01-28T18:31:28Z",
  "published": "2025-01-28T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23053"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04775en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CQCC-25CV-67XR

Vulnerability from github – Published: 2022-04-03 00:01 – Updated: 2022-04-13 00:00
VLAI
Details

Improper access control in Gitlab CE/EE versions 12.7 to 14.5.4, 14.6 to 14.6.4, and 14.7 to 14.7.1 allowed for project non-members to retrieve issue details when it was linked to an item from the vulnerability dashboard.

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-2022-0390"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-01T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper access control in Gitlab CE/EE versions 12.7 to 14.5.4, 14.6 to 14.6.4, and 14.7 to 14.7.1 allowed for project non-members to retrieve issue details when it was linked to an item from the vulnerability dashboard.",
  "id": "GHSA-cqcc-25cv-67xr",
  "modified": "2022-04-13T00:00:51Z",
  "published": "2022-04-03T00:01:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0390"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1179733"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-0390.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/330030"
    }
  ],
  "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-CQGR-63WX-2GM4

Vulnerability from github – Published: 2024-06-27 21:32 – Updated: 2025-10-15 15:30
VLAI
Details

In version 1.2.7 of lunary-ai/lunary, any authenticated user, regardless of their role, can change the name of an organization due to improper access control. The function checkAccess() is not implemented, allowing users with the lowest privileges, such as the 'Prompt Editor' role, to modify organization attributes without proper authorization.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-6086"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-27T19:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In version 1.2.7 of lunary-ai/lunary, any authenticated user, regardless of their role, can change the name of an organization due to improper access control. The function checkAccess() is not implemented, allowing users with the lowest privileges, such as the \u0027Prompt Editor\u0027 role, to modify organization attributes without proper authorization.",
  "id": "GHSA-cqgr-63wx-2gm4",
  "modified": "2025-10-15T15:30:19Z",
  "published": "2024-06-27T21:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6086"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/3451fcd7b9d95e9091d62c515752f39f2faa6e54"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/9e83f63f-c5c1-422f-8010-95c353f0c643"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CQGW-44WG-44RF

Vulnerability from github – Published: 2026-04-03 03:17 – Updated: 2026-04-28 18:16
VLAI
Summary
OpenClaw: Discord voice manager bypasses channel-level member access allowlist
Details

Summary

Discord voice manager bypasses channel-level member access allowlist

Current Maintainer Triage

  • Status: open
  • Normalized severity: medium
  • Assessment: v2026.3.28 still accepts Discord voice ingress before channel allowlist authorization, and main-only gating means this remains a real shipped access-control bug.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • dba96e7507e0900f120e5e28e57755d69bf78759 — 2026-03-31T21:29:13+09:00

Release Process Note

  • The fix is already present in released version 2026.3.31.
  • This draft looks ready for final maintainer disposition or publication, not additional code-fix work.

Thanks @zsxsoft for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41381"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T03:17:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nDiscord voice manager bypasses channel-level member access allowlist\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: medium\n- Assessment: v2026.3.28 still accepts Discord voice ingress before channel allowlist authorization, and main-only gating means this remains a real shipped access-control bug.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `dba96e7507e0900f120e5e28e57755d69bf78759` \u2014 2026-03-31T21:29:13+09:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.31`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @zsxsoft for reporting.",
  "id": "GHSA-cqgw-44wg-44rf",
  "modified": "2026-04-28T18:16:34Z",
  "published": "2026-04-03T03:17:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-cqgw-44wg-44rf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/dba96e7507e0900f120e5e28e57755d69bf78759"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Discord voice manager bypasses channel-level member access allowlist"
}

GHSA-CQQG-QHCP-9MQR

Vulnerability from github – Published: 2024-11-29 06:35 – Updated: 2024-11-29 21:31
VLAI
Details

In Click Studios Passwordstate before build 9920, there is a potential permission escalation on the edit folder screen.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-54124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-29T04:15:04Z",
    "severity": "HIGH"
  },
  "details": "In Click Studios Passwordstate before build 9920, there is a potential permission escalation on the edit folder screen.",
  "id": "GHSA-cqqg-qhcp-9mqr",
  "modified": "2024-11-29T21:31:03Z",
  "published": "2024-11-29T06:35:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54124"
    },
    {
      "type": "WEB",
      "url": "https://www.clickstudios.com.au/passwordstate-changelog.aspx"
    },
    {
      "type": "WEB",
      "url": "https://www.clickstudios.com.au/security/advisories"
    }
  ],
  "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"
    }
  ]
}

GHSA-CQRW-J4QC-7F9W

Vulnerability from github – Published: 2026-05-15 21:31 – Updated: 2026-06-08 23:59
Withdrawn 2026-06-08 VLAI
Summary
Duplicate Advisory: phpMyFAQ has unauthenticated FAQ permission bypass via getFaqBySolutionId fallback query
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-289f-fq7w-6q2w. This link is maintained to preserve external references.

Original Description

phpMyFAQ before 4.1.2 contains an information disclosure vulnerability in the getIdFromSolutionId() method that lacks permission filtering, allowing unauthenticated attackers to enumerate restricted FAQ entries and read their titles via the /solution_id_{id}.html endpoint. Attackers can sequentially iterate solution IDs to discover all FAQs including those restricted to specific users or groups, leaking sensitive metadata through redirect Location headers and page canonical links.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyfaq/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:59:55Z",
    "nvd_published_at": "2026-05-15T19:17:03Z",
    "severity": "HIGH"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-289f-fq7w-6q2w. This link is maintained to preserve external references.\n\n### Original Description\nphpMyFAQ before 4.1.2 contains an information disclosure vulnerability in the getIdFromSolutionId() method that lacks permission filtering, allowing unauthenticated attackers to enumerate restricted FAQ entries and read their titles via the /solution_id_{id}.html endpoint. Attackers can sequentially iterate solution IDs to discover all FAQs including those restricted to specific users or groups, leaking sensitive metadata through redirect Location headers and page canonical links.",
  "id": "GHSA-cqrw-j4qc-7f9w",
  "modified": "2026-06-08T23:59:55Z",
  "published": "2026-05-15T21:31:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-99qv-g4x9-mgc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46366"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/phpmyfaq-unauthenticated-information-disclosure-via-getidfromsolutionid-permission-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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"
    }
  ],
  "summary": "Duplicate Advisory: phpMyFAQ has unauthenticated FAQ permission bypass via getFaqBySolutionId fallback query",
  "withdrawn": "2026-06-08T23:59:55Z"
}

GHSA-CQWH-GP47-J7Q9

Vulnerability from github – Published: 2021-12-22 00:00 – Updated: 2022-07-13 00:01
VLAI
Details

Stormshield Endpoint Security 2.x before 2.1.2 has Incorrect Access Control.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-45089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-21T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Stormshield Endpoint Security 2.x before 2.1.2 has Incorrect Access Control.",
  "id": "GHSA-cqwh-gp47-j7q9",
  "modified": "2022-07-13T00:01:50Z",
  "published": "2021-12-22T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45089"
    },
    {
      "type": "WEB",
      "url": "https://advisories.stormshield.eu/2021-071"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CR22-WJX7-2W6M

Vulnerability from github – Published: 2026-05-21 20:33 – Updated: 2026-06-12 19:26
VLAI
Summary
MCP Server Kubernetes: Tool Access Control Bypass via Presentation-Layer Filtering Without Execution-Layer Enforcement
Details

Summary

mcp-server-kubernetes exposes three environment variables (ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, ALLOWED_TOOLS) documented as access controls for restricting which Kubernetes operations are available. These controls are enforced at the tool discovery layer (tools/list) but not at the execution layer (tools/call). Any client that knows a tool name can invoke it directly regardless of the configured restriction mode. The access control was effectively cosmetic.

Fixed in v3.6.0.

Impact

An attacker or misconfigured AI agent with network access to the MCP server's HTTP endpoint could invoke any Kubernetes tool regardless of the restriction mode configured by the operator -- including kubectl_delete, exec_in_pod, kubectl_generic, and node_management.

The project explicitly supports and documents multi-client HTTP deployment scenarios (Streamable HTTP and SSE transports, in-cluster deployments, Codex CLI and Gemini CLI integrations). In these deployments, operators relied on the tool restriction env vars to enforce least-privilege access across users or roles. The bypass invalidated that model entirely.

Severity scales with the Kubernetes service account's permissions. In environments where the MCP server runs with cluster-admin (common in dev/staging), this is equivalent to full cluster compromise for any client that can reach the endpoint.

The MCP_AUTH_TOKEN / X-MCP-AUTH mechanism controls who can reach the endpoint but provides no per-tool authorization. An authenticated client restricted to ALLOWED_TOOLS=kubectl_get could still invoke kubectl_delete after authentication.

Root Cause

In src/index.ts, the ListToolsRequestSchema handler applied the configured filtering logic before returning available tools. The CallToolRequestSchema handler dispatched directly by tool name with no equivalent check -- every tool was reachable unconditionally.

Proof of Concept

Tested across all three restriction modes against a live kind cluster. In each case, kubectl_delete was absent from tools/list but executed successfully via a direct tools/call request:

curl -s http://<HOST>:3003/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"kubectl_delete","arguments":{"resourceType":"pod","name":"test-pod","namespace":"default"}}}'

Result: {"result":{"content":[{"type":"text","text":"pod \"test-pod\" deleted\n"}]}}

Confirmed across ALLOW_ONLY_READONLY_TOOLS=true, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true, and ALLOWED_TOOLS=kubectl_get.

Remediation

The fix applies the same filtering logic from ListToolsRequestSchema at the start of the CallToolRequestSchema handler, returning an error for any tool call outside the active allowed set. Fixed in v3.6.0.

Credit

Discovered by Francisco Rosales of Manifold Security, coordinated by Ax Sharma, Head of Research at Manifold Security.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "mcp-server-kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46519"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:33:46Z",
    "nvd_published_at": "2026-06-11T19:16:42Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`mcp-server-kubernetes` exposes three environment variables (`ALLOW_ONLY_READONLY_TOOLS`, `ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS`, `ALLOWED_TOOLS`) documented as access controls for restricting which Kubernetes operations are available. These controls are enforced at the tool discovery layer (`tools/list`) but not at the execution layer (`tools/call`). Any client that knows a tool name can invoke it directly regardless of the configured restriction mode. The access control was effectively cosmetic.\n\nFixed in v3.6.0.\n\n## Impact\n\nAn attacker or misconfigured AI agent with network access to the MCP server\u0027s HTTP endpoint could invoke any Kubernetes tool regardless of the restriction mode configured by the operator -- including `kubectl_delete`, `exec_in_pod`, `kubectl_generic`, and `node_management`.\n\nThe project explicitly supports and documents multi-client HTTP deployment scenarios (Streamable HTTP and SSE transports, in-cluster deployments, Codex CLI and Gemini CLI integrations). In these deployments, operators relied on the tool restriction env vars to enforce least-privilege access across users or roles. The bypass invalidated that model entirely.\n\nSeverity scales with the Kubernetes service account\u0027s permissions. In environments where the MCP server runs with `cluster-admin` (common in dev/staging), this is equivalent to full cluster compromise for any client that can reach the endpoint.\n\nThe `MCP_AUTH_TOKEN` / `X-MCP-AUTH` mechanism controls who can reach the endpoint but provides no per-tool authorization. An authenticated client restricted to `ALLOWED_TOOLS=kubectl_get` could still invoke `kubectl_delete` after authentication.\n\n## Root Cause\n\nIn `src/index.ts`, the `ListToolsRequestSchema` handler applied the configured filtering logic before returning available tools. The `CallToolRequestSchema` handler dispatched directly by tool name with no equivalent check -- every tool was reachable unconditionally.\n\n## Proof of Concept\n\nTested across all three restriction modes against a live kind cluster. In each case, `kubectl_delete` was absent from `tools/list` but executed successfully via a direct `tools/call` request:\n\n```shell\ncurl -s http://\u003cHOST\u003e:3003/mcp \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Accept: application/json, text/event-stream\u0027 \\\n  -d \u0027{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{\"name\":\"kubectl_delete\",\"arguments\":{\"resourceType\":\"pod\",\"name\":\"test-pod\",\"namespace\":\"default\"}}}\u0027\n```\n\nResult: `{\"result\":{\"content\":[{\"type\":\"text\",\"text\":\"pod \\\"test-pod\\\" deleted\\n\"}]}}`\n\nConfirmed across `ALLOW_ONLY_READONLY_TOOLS=true`, `ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true`, and `ALLOWED_TOOLS=kubectl_get`.\n\n## Remediation\n\nThe fix applies the same filtering logic from `ListToolsRequestSchema` at the start of the `CallToolRequestSchema` handler, returning an error for any tool call outside the active allowed set. Fixed in v3.6.0.\n\n## Credit\n\nDiscovered by [Francisco Rosales](https://www.linkedin.com/in/francisco-rosales-celis/) of [Manifold Security](https://manifold.security), coordinated by [Ax Sharma](https://www.linkedin.com/in/axsharma/), Head of Research at Manifold Security.",
  "id": "GHSA-cr22-wjx7-2w6m",
  "modified": "2026-06-12T19:26:31Z",
  "published": "2026-05-21T20:33:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Flux159/mcp-server-kubernetes/security/advisories/GHSA-cr22-wjx7-2w6m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46519"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Flux159/mcp-server-kubernetes"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Flux159/mcp-server-kubernetes/releases/tag/v3.6.0"
    }
  ],
  "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": "MCP Server Kubernetes: Tool Access Control Bypass via Presentation-Layer Filtering Without Execution-Layer Enforcement"
}
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.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list