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.

6795 vulnerabilities reference this CWE, most recent first.

GHSA-W5WV-WVRP-V5M5

Vulnerability from github – Published: 2026-01-27 22:15 – Updated: 2026-01-29 03:43
VLAI
Summary
Kargo's `GetConfig()` and `RefreshResource()` API endpoints allow unauthenticated access
Details

Impact

A bug was found with authentication checks on the GetConfig() API endpoint. This allowed unauthenticated users to access this endpoint by specifying an Authorization header with any non-empty Bearer token value, regardless of validity. This vulnerability did allow for exfiltration of configuration data such as endpoints for connected Argo CD clusters. This data could allow an attacker to enumerate cluster URLs and namespaces for use in subsequent attacks.

Additionally, the same bug affected the RefreshResource endpoint. This endpoint does not lead to any information disclosure, but could be used by an unauthenticated attacker to perform a denial-of-service style attack against the Kargo API. RefreshResource sets an annotation on specific Kubernetes resources to trigger reconciliations. If run on a constant loop, this could also slow down legitimate requests to the Kubernetes API server.

This vulnerability was identified by security researchers, and there are no known reports of exploitation in the wild.

Patches

This problem has been patched in the previous 3 versions of Kargo. Based on our information, almost all users are on one of these versions. If for some reason you cannot upgrade from an earlier version, please reach out to us.

Workarounds

There are no workarounds for this issue, so it is highly recommended to upgrade at the earliest possible

Additional details

This issue was caused by fallback logic in token authentication. The majority of Kargo endpoints are backed by Kubernetes objects, and for these endpoints, unrecognized token types are passed to the Kubernetes API for validation. However, the affected endpoints do not use Kubernetes or used an internal client not subject to authentication, so unrecognized tokens had no validation fallback. As a result, any request with a non-empty Bearer token in the Authorization header was incorrectly treated as authorized.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/akuity/kargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/akuity/kargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0-rc.1"
            },
            {
              "fixed": "1.7.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/akuity/kargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0-rc.1"
            },
            {
              "fixed": "1.8.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24748"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-27T22:15:28Z",
    "nvd_published_at": "2026-01-27T22:15:56Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA bug was found with authentication checks on the `GetConfig()` API endpoint. This allowed unauthenticated users to access this endpoint by specifying an `Authorization` header with any non-empty `Bearer` token value, regardless of validity.  This vulnerability did allow for exfiltration of configuration data such as endpoints for connected Argo CD clusters. This data could allow an attacker to enumerate cluster URLs and namespaces for use in subsequent attacks.\n\nAdditionally, the same bug affected the `RefreshResource` endpoint. This endpoint does not lead to any information disclosure, but could be used by an unauthenticated attacker to perform a denial-of-service style attack against the Kargo API. `RefreshResource` sets an annotation on specific Kubernetes resources to trigger reconciliations. If run on a constant loop, this could also slow down legitimate requests to the Kubernetes API server.\n\nThis vulnerability was identified by security researchers, and there are no known reports of exploitation in the wild.\n\n### Patches\n\nThis problem has been patched in the previous 3 versions of Kargo. Based on our information, almost all users are on one of these versions. If for some reason you cannot upgrade from an earlier version, please reach out to us.\n\n### Workarounds\n\nThere are no workarounds for this issue, so it is highly recommended to upgrade at the earliest possible\n\n### Additional details\n\nThis issue was caused by fallback logic in token authentication. The majority of Kargo endpoints are backed by Kubernetes objects, and for these endpoints, unrecognized token types are passed to the Kubernetes API for validation. However, the affected endpoints do not use Kubernetes or used an internal client not subject to authentication, so unrecognized tokens had no validation fallback. As a result, any request with a non-empty `Bearer` token in the `Authorization` header was incorrectly treated as authorized.",
  "id": "GHSA-w5wv-wvrp-v5m5",
  "modified": "2026-01-29T03:43:04Z",
  "published": "2026-01-27T22:15:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/akuity/kargo/security/advisories/GHSA-w5wv-wvrp-v5m5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24748"
    },
    {
      "type": "WEB",
      "url": "https://github.com/akuity/kargo/commit/23646eaefb449a6cc2e76a8033e8a57f71369772"
    },
    {
      "type": "WEB",
      "url": "https://github.com/akuity/kargo/commit/aa28f81ac15ad871c6eba329fc2f0417a08c39d7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/akuity/kargo/commit/b3297ace0d3b9e7f7128858c5c4288d77f072b8c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/akuity/kargo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kargo\u0027s `GetConfig()` and `RefreshResource()` API endpoints allow unauthenticated access"
}

GHSA-W5WW-7CHG-MXCQ

Vulnerability from github – Published: 2026-07-02 17:18 – Updated: 2026-07-02 17:18
VLAI
Summary
OpenClaw: Telegram interactive callbacks could skip commands.allowFrom
Details

Summary

Telegram interactive callbacks could skip commands.allowFrom. In affected versions, a Telegram user able to invoke an affected callback could mark the callback as an authorized sender before applying commands.allowFrom.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could trigger command behavior outside the configured Telegram sender allowlist. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.5.6.

Mitigations

restrict Telegram command callbacks to trusted chats until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.5.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T17:18:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nTelegram interactive callbacks could skip commands.allowFrom. In affected versions, a Telegram user able to invoke an affected callback could mark the callback as an authorized sender before applying `commands.allowFrom`.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could trigger command behavior outside the configured Telegram sender allowlist. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.6`.\n\n### Mitigations\n\nrestrict Telegram command callbacks to trusted chats until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-w5ww-7chg-mxcq",
  "modified": "2026-07-02T17:18:51Z",
  "published": "2026-07-02T17:18:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w5ww-7chg-mxcq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Telegram interactive callbacks could skip commands.allowFrom"
}

GHSA-W5XM-MX47-V7C8

Vulnerability from github – Published: 2024-06-08 21:30 – Updated: 2024-11-18 19:40
Withdrawn 2024-11-18 VLAI
Summary
lunary-ai/lunary allows users unauthorized access to projects
Details

Withdrawn: This advisory was incorrectly linked the the npm package lunary. The advisory is valid, but not for that packlage.

In lunary-ai/lunary version v1.2.13, an incorrect authorization vulnerability exists that allows unauthorized users to access and manipulate projects within an organization they should not have access to. Specifically, the vulnerability is located in the checkProjectAccess method within the authorization middleware, which fails to adequately verify if a user has the correct permissions to access a specific project. Instead, it only checks if the user is part of the organization owning the project, overlooking the necessary check against the account_project table for explicit project access rights. This flaw enables attackers to gain complete control over all resources within a project, including the ability to create, update, read, and delete any resource, compromising the privacy and security of sensitive information.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "lunary"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-4146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-10T15:33:08Z",
    "nvd_published_at": "2024-06-08T20:15:52Z",
    "severity": "CRITICAL"
  },
  "details": "Withdrawn: This advisory was incorrectly linked the the npm package `lunary`. The advisory is valid, but not for that packlage.\n\nIn lunary-ai/lunary version v1.2.13, an incorrect authorization vulnerability exists that allows unauthorized users to access and manipulate projects within an organization they should not have access to. Specifically, the vulnerability is located in the `checkProjectAccess` method within the authorization middleware, which fails to adequately verify if a user has the correct permissions to access a specific project. Instead, it only checks if the user is part of the organization owning the project, overlooking the necessary check against the `account_project` table for explicit project access rights. This flaw enables attackers to gain complete control over all resources within a project, including the ability to create, update, read, and delete any resource, compromising the privacy and security of sensitive information.",
  "id": "GHSA-w5xm-mx47-v7c8",
  "modified": "2024-11-18T19:40:39Z",
  "published": "2024-06-08T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4146"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/c43b6c62035f32ca455f66d5fd22ba661648cde7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lunary-ai/lunary"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/a749e696-b398-4260-b2d0-b0054b9fffa7"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "lunary-ai/lunary allows users unauthorized access to projects",
  "withdrawn": "2024-11-18T19:40:39Z"
}

GHSA-W65P-8M9J-6PM4

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

Incorrect Authorization vulnerability in Drupal Freelinking allows Forceful Browsing.This issue affects Freelinking: from 0.0.0 before 4.0.1.

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-2024-13270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-09T20:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in Drupal Freelinking allows Forceful Browsing.This issue affects Freelinking: from 0.0.0 before 4.0.1.",
  "id": "GHSA-w65p-8m9j-6pm4",
  "modified": "2025-01-31T18:31:04Z",
  "published": "2025-01-09T21:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13270"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2024-034"
    }
  ],
  "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-W65R-3XH2-3PJ4

Vulnerability from github – Published: 2025-09-16 00:30 – Updated: 2025-11-03 21:34
VLAI
Details

This issue was addressed with improved checks to prevent unauthorized actions. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-43307"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T23:15:33Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved checks to prevent unauthorized actions. This issue is fixed in macOS Tahoe 26. An app may be able to access sensitive user data.",
  "id": "GHSA-w65r-3xh2-3pj4",
  "modified": "2025-11-03T21:34:30Z",
  "published": "2025-09-16T00:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43307"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125110"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Sep/53"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W65V-2JVX-6697

Vulnerability from github – Published: 2023-06-02 12:30 – Updated: 2024-04-04 04:28
VLAI
Details

Wade Graphic Design FANTSY has a vulnerability of insufficient authorization check. An unauthenticated remote user can exploit this vulnerability by modifying URL parameters to gain administrator privileges to perform arbitrary system operation or disrupt service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-28698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T11:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "Wade Graphic Design FANTSY has a vulnerability of insufficient authorization check. An unauthenticated remote user can exploit this vulnerability by modifying URL parameters to gain administrator privileges to perform arbitrary system operation or disrupt service.",
  "id": "GHSA-w65v-2jvx-6697",
  "modified": "2024-04-04T04:28:38Z",
  "published": "2023-06-02T12:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28698"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7101-f88db-1.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-W66G-J6C4-HCFC

Vulnerability from github – Published: 2026-09-22 20:34 – Updated: 2026-09-22 20:34
VLAI
Summary
MCP Atlassian: JIRA_PROJECTS_FILTER / CONFLUENCE_SPACES_FILTER allow forbidden-project content exfiltration (one LIVE-proven on Atlassian Cloud)
Details

Summary

mcp-atlassian is a popular community MCP server wrapper exposing Jira / Confluence to MCP clients. Operators commonly restrict the surface to a small allowlist of projects/spaces via the JIRA_PROJECTS_FILTER and CONFLUENCE_SPACES_FILTER environment variables, which the README documents as the principal mechanism for limiting attacker-controlled MCP clients (= prompt-injected LLM agents) to the operator's intended subset of the workspace.

We identified three distinct sub-bugs that let attacker-controlled queries read content from forbidden projects/spaces (= projects NOT in the operator's filter) despite the filter being correctly set. The most severe is empirically reproduced on production Atlassian Cloud with real operator credentials and sentinel content in two real projects.

Sub-bug Layer Class Live?
A1 Jira jira_search jql substring-bypass 🔴 LIVE PROVEN 2026-05-18 on real Atlassian Cloud
A2 Confluence confluence_search cql case-sensitive substring-bypass code-level verified
B Jira agile get_board_issues / get_agile_boards zero-filter (missing check) code-level verified

Details

Sub-bug A1 — src/mcp_atlassian/jira/search.py lines 92-94 at HEAD d8bc78698a63cb6b321c7ca796d6329d448f7f6d:

if projects_filter and "project = " not in jql.lower():
    jql = f"{jql} AND project in ({','.join(projects_filter)})"

The substring check is satisfied by any JQL of the form project = <forbidden-project> — including a project NOT in projects_filter. The wrapper does NOT verify that the project named in the user JQL is a member of the allowlist. The user-supplied JQL is sent verbatim to Jira's search API which returns content from the forbidden project (Jira's authorization is satisfied because the operator's PAT typically has broader access than the operator's intended allowlist — which is why the operator set a filter in the first place).

Sub-bug A2 — src/mcp_atlassian/confluence/search.py line 60: same pattern as A1, PLUS the substring check "space = " not in cql is case-sensitive (no .lower()). User CQL SPACE = "<forbidden-space>" (uppercase) bypasses the substring match.

Sub-bug B — get_board_issues and get_agile_boards paths have no projects_filter enforcement at all — no substring check, no AST walk, the allowlist is silently ignored. An MCP client invoking get_agile_boards enumerates boards across the entire workspace (including forbidden projects), and get_board_issues(boardId=<forbidden-board>) returns all issues with no filter check.

PoC

End-to-end Phase C against real Atlassian Cloud + real mcp-atlassian Python binary v0.21.1 (latest on PyPI) with operator-provided test workspace and two real Jira projects (one allowed, one forbidden via JIRA_PROJECTS_FILTER):

Step JQL submitted Result Verdict
1 initialize – MCP 2024-11-05 OK ✓
2 tools/list – 33+ tools incl. jira_search ✓
3 CONTROL project = <allowed> returns allowed issue ✓
4 NEG CTRL summary ~ "any-string" wrapper appends AND project in (<allowed>) → 0 forbidden results ✓
5 BYPASS A1 project = <forbidden> returns forbidden issue with sentinel content 🔴 BYPASS

Full RPC log and a reproducible test script are available in a disclosure bundle I have prepared. I can share the zip via a private channel (email / your preferred private fork / encrypted upload) — please reply with your preference. The bundle includes:

  • 00-FINDING-REPORT.md (primary report)
  • ATTACK-MATRIX.md
  • Verbatim source files at HEAD with sha256 chain of custody (source-jira-search.py, source-confluence-search.py)
  • Phase C live test script + JSON-RPC witness log
  • Bundle zip sha256: 034cbf0bcb66c325be9373ff2dc186b8b0e1747c5165d6fba3bca83054949dd3

Repro recipe (no bundle needed) :

pip install mcp-atlassian
export JIRA_URL=https://<your-test-workspace>.atlassian.net
export JIRA_USERNAME=<your-test-email>
export JIRA_API_TOKEN=<your-pat>
export JIRA_PROJECTS_FILTER=<your-allowed-project-key>
# Then drive the MCP via stdio JSON-RPC with tools/call jira_search jql="project = <forbidden-project-key>"
# Expect: forbidden project content returned despite the filter.

Impact

Severity is higher in deployments where the operator's PAT covers a broader set of projects than JIRA_PROJECTS_FILTER (= the common configuration, which is the reason operators set the filter).

Affected: every operator who relies on JIRA_PROJECTS_FILTER / CONFLUENCE_SPACES_FILTER to confine an attacker-controlled MCP client (= prompt-injected LLM agent) to a subset of their workspace.

Suggested fix

  1. Replace substring checks with AST-based JQL/CQL parsers that walk the WHERE clause looking for project/space constraints. Reject queries whose project/space constraint references a key not in the allowlist.
  2. Add projects_filter check inside get_board_issues (resolve board → project, reject if not in filter) and get_agile_boards (filter returned list).
  3. Make the Confluence substring check case-insensitive (cql.lower()) for defense-in-depth, even after the AST fix lands.
  4. Default-deny for ambiguous queries: if the AST parser can't fully classify a clause, refuse instead of pass-through.
  5. Add unit tests that assert attacker JQL project = <not-in-filter> returns zero results when the filter is set.

Disclosure

ISO/IEC 29147. Default 90-day embargo from the date you acknowledge receipt. Happy to coordinate the CVE via the GitHub CNA pipeline. Credit under: Mordehai Attia, Founder, Corsen AI (https://corsen.ai , GitHub @CorsenAI).

Thank you for maintaining mcp-atlassian — the project is widely used and your security policy was clear, which made this disclosure straightforward to file. Looking forward to coordinating the fix.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1276",
      "CWE-184",
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:34:47Z",
    "nvd_published_at": "2026-09-22T18:17:17Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`mcp-atlassian` is a popular community MCP server wrapper exposing Jira / Confluence to MCP clients. Operators commonly restrict the surface to a small allowlist of projects/spaces via the `JIRA_PROJECTS_FILTER` and `CONFLUENCE_SPACES_FILTER` environment variables, which the README documents as the principal mechanism for limiting attacker-controlled MCP clients (= prompt-injected LLM agents) to the operator\u0027s intended subset of the workspace.\n\nWe identified **three distinct sub-bugs** that let attacker-controlled queries read content from **forbidden** projects/spaces (= projects NOT in the operator\u0027s filter) despite the filter being correctly set. The most severe is **empirically reproduced on production Atlassian Cloud** with real operator credentials and sentinel content in two real projects.\n\n| Sub-bug | Layer | Class | Live? |\n|---|---|---|---|\n| **A1** | Jira `jira_search` `jql` | substring-bypass | \ud83d\udd34 **LIVE PROVEN 2026-05-18 on real Atlassian Cloud** |\n| **A2** | Confluence `confluence_search` `cql` | case-sensitive substring-bypass | code-level verified |\n| **B** | Jira agile `get_board_issues` / `get_agile_boards` | zero-filter (missing check) | code-level verified |\n\n### Details\n\n**Sub-bug A1** \u2014 `src/mcp_atlassian/jira/search.py` lines 92-94 at HEAD `d8bc78698a63cb6b321c7ca796d6329d448f7f6d`:\n\n```python\nif projects_filter and \"project = \" not in jql.lower():\n    jql = f\"{jql} AND project in ({\u0027,\u0027.join(projects_filter)})\"\n```\n\nThe substring check is satisfied by *any* JQL of the form `project = \u003cforbidden-project\u003e` \u2014 including a project NOT in `projects_filter`. The wrapper does NOT verify that the project named in the user JQL is a member of the allowlist. The user-supplied JQL is sent verbatim to Jira\u0027s search API which returns content from the forbidden project (Jira\u0027s authorization is satisfied because the operator\u0027s PAT typically has broader access than the operator\u0027s intended allowlist \u2014 which is *why* the operator set a filter in the first place).\n\n**Sub-bug A2** \u2014 `src/mcp_atlassian/confluence/search.py` line 60: same pattern as A1, PLUS the substring check `\"space = \" not in cql` is **case-sensitive** (no `.lower()`). User CQL `SPACE = \"\u003cforbidden-space\u003e\"` (uppercase) bypasses the substring match.\n\n**Sub-bug B** \u2014 `get_board_issues` and `get_agile_boards` paths have **no `projects_filter` enforcement at all** \u2014 no substring check, no AST walk, the allowlist is silently ignored. An MCP client invoking `get_agile_boards` enumerates boards across the entire workspace (including forbidden projects), and `get_board_issues(boardId=\u003cforbidden-board\u003e)` returns all issues with no filter check.\n\n### PoC\n\nEnd-to-end Phase C against real Atlassian Cloud + real `mcp-atlassian` Python binary v0.21.1 (latest on PyPI) with operator-provided test workspace and two real Jira projects (one allowed, one forbidden via `JIRA_PROJECTS_FILTER`):\n\n| Step | JQL submitted | Result | Verdict |\n|---|---|---|---|\n| 1 initialize | \u2013 | MCP 2024-11-05 OK | \u2713 |\n| 2 tools/list | \u2013 | 33+ tools incl. `jira_search` | \u2713 |\n| 3 CONTROL | `project = \u003callowed\u003e` | returns allowed issue | \u2713 |\n| 4 NEG CTRL | `summary ~ \"any-string\"` | wrapper appends `AND project in (\u003callowed\u003e)` \u2192 0 forbidden results | \u2713 |\n| 5 **BYPASS A1** | `project = \u003cforbidden\u003e` | **returns forbidden issue with sentinel content** | \ud83d\udd34 **BYPASS** |\n\nFull RPC log and a reproducible test script are available in a disclosure bundle I have prepared. I can share the zip via a private channel (email / your preferred private fork / encrypted upload) \u2014 please reply with your preference. The bundle includes:\n\n- 00-FINDING-REPORT.md (primary report)\n- ATTACK-MATRIX.md\n- Verbatim source files at HEAD with sha256 chain of custody (`source-jira-search.py`, `source-confluence-search.py`)\n- Phase C live test script + JSON-RPC witness log\n- Bundle zip sha256: `034cbf0bcb66c325be9373ff2dc186b8b0e1747c5165d6fba3bca83054949dd3`\n\nRepro recipe (no bundle needed) :\n\n```bash\npip install mcp-atlassian\nexport JIRA_URL=https://\u003cyour-test-workspace\u003e.atlassian.net\nexport JIRA_USERNAME=\u003cyour-test-email\u003e\nexport JIRA_API_TOKEN=\u003cyour-pat\u003e\nexport JIRA_PROJECTS_FILTER=\u003cyour-allowed-project-key\u003e\n# Then drive the MCP via stdio JSON-RPC with tools/call jira_search jql=\"project = \u003cforbidden-project-key\u003e\"\n# Expect: forbidden project content returned despite the filter.\n```\n\n### Impact\n\nSeverity is higher in deployments where the operator\u0027s PAT covers a broader set of projects than `JIRA_PROJECTS_FILTER` (= the common configuration, which is the reason operators set the filter).\n\nAffected: every operator who relies on `JIRA_PROJECTS_FILTER` / `CONFLUENCE_SPACES_FILTER` to confine an attacker-controlled MCP client (= prompt-injected LLM agent) to a subset of their workspace.\n\n### Suggested fix\n\n1. Replace substring checks with **AST-based JQL/CQL parsers** that walk the WHERE clause looking for `project`/`space` constraints. Reject queries whose `project`/`space` constraint references a key not in the allowlist.\n2. Add `projects_filter` check inside `get_board_issues` (resolve board \u2192 project, reject if not in filter) and `get_agile_boards` (filter returned list).\n3. Make the Confluence substring check case-insensitive (`cql.lower()`) for defense-in-depth, even after the AST fix lands.\n4. Default-deny for ambiguous queries: if the AST parser can\u0027t fully classify a clause, refuse instead of pass-through.\n5. Add unit tests that assert attacker JQL `project = \u003cnot-in-filter\u003e` returns zero results when the filter is set.\n\n### Disclosure\n\nISO/IEC 29147. Default 90-day embargo from the date you acknowledge receipt. Happy to coordinate the CVE via the GitHub CNA pipeline. Credit under: **Mordehai Attia, Founder, Corsen AI** (https://corsen.ai , GitHub @CorsenAI).\n\nThank you for maintaining mcp-atlassian \u2014 the project is widely used and your security policy was clear, which made this disclosure straightforward to file. Looking forward to coordinating the fix.",
  "id": "GHSA-w66g-j6c4-hcfc",
  "modified": "2026-09-22T20:34:48Z",
  "published": "2026-09-22T20:34:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-w66g-j6c4-hcfc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77251"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Atlassian: JIRA_PROJECTS_FILTER / CONFLUENCE_SPACES_FILTER allow forbidden-project content exfiltration (one LIVE-proven on Atlassian Cloud)"
}

GHSA-W66P-78G4-MR7G

Vulnerability from github – Published: 2022-05-17 01:39 – Updated: 2024-09-27 18:07
VLAI
Summary
OpenStack Keystone Insufficient token expiration
Details

OpenStack Keystone, as used in OpenStack Folsom 2012.2, does not properly implement token expiration, which allows remote authenticated users to bypass intended authorization restrictions by creating new tokens through token chaining. NOTE: this issue exists because of a CVE-2012-3426 regression.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2012-5563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-14T00:53:23Z",
    "nvd_published_at": "2012-12-18T01:55:00Z",
    "severity": "HIGH"
  },
  "details": "OpenStack Keystone, as used in OpenStack Folsom 2012.2, does not properly implement token expiration, which allows remote authenticated users to bypass intended authorization restrictions by creating new tokens through token chaining.  NOTE: this issue exists because of a CVE-2012-3426 regression.",
  "id": "GHSA-w66p-78g4-mr7g",
  "modified": "2024-09-27T18:07:52Z",
  "published": "2022-05-17T01:39:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5563"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/keystone/commit/38c7e46a640a94da4da89a39a5a1ea9c081f1eb5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/keystone/commit/f9d4766249a72d8f88d75dcf1575b28dd3496681"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/keystone/+bug/1079216"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/80370"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/keystone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keystone/PYSEC-2012-20.yaml"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20121201003009/http://secunia.com/advisories/51423"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20140802122732/http://secunia.com/advisories/51436"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200228144943/http://www.securityfocus.com/bid/56727"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-1557.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/11/28/5"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/11/28/6"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1641-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenStack Keystone Insufficient token expiration"
}

GHSA-W67P-2W4G-FGJP

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22
VLAI
Details

The /rest/project-templates/1.0/createshared resource in Atlassian Jira Server and Data Center before version 8.5.5, from 8.6.0 before 8.7.2, and from 8.8.0 before 8.8.1 allows remote attackers to enumerate project names via an improper authorization vulnerability.

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-2020-4029"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-01T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The /rest/project-templates/1.0/createshared resource in Atlassian Jira Server and Data Center before version 8.5.5, from 8.6.0 before 8.7.2, and from 8.8.0 before 8.8.1 allows remote attackers to enumerate project names via an improper authorization vulnerability.",
  "id": "GHSA-w67p-2w4g-fgjp",
  "modified": "2022-05-24T17:22:14Z",
  "published": "2022-05-24T17:22:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4029"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-70926"
    }
  ],
  "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-W68R-5P45-5RQP

Vulnerability from github – Published: 2021-05-06 18:54 – Updated: 2021-05-04 22:46
VLAI
Summary
Improper Input Validation in Laravel
Details

An issue was discovered in Laravel before 6.18.35 and 7.x before 7.24.0. The $guarded property is mishandled in some situations involving requests with JSON column nesting expressions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "laravel/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.18.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "laravel/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-24941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-04T22:46:50Z",
    "nvd_published_at": "2020-09-04T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Laravel before 6.18.35 and 7.x before 7.24.0. The $guarded property is mishandled in some situations involving requests with JSON column nesting expressions.",
  "id": "GHSA-w68r-5p45-5rqp",
  "modified": "2021-05-04T22:46:50Z",
  "published": "2021-05-06T18:54:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24941"
    },
    {
      "type": "WEB",
      "url": "https://github.com/laravel/framework/commit/897d107775737a958dbd0b2f3ea37877c7526371"
    },
    {
      "type": "WEB",
      "url": "https://blog.laravel.com/security-release-laravel-61835-7240"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Input Validation in Laravel"
}
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