GHSA-xv8h-26ch-vfh9: 
Python Analyse et atténuation de la vulnérabilité

Summary

JIRA_PROJECTS_FILTER and CONFLUENCE_SPACES_FILTER are documented and used as a tenant/access boundary — Jira get_issue even enforces them with the comment "These should NOT be overridden by the request," and the search docstring calls the filter "a hard boundary." However, the allowlist is consulted on exactly two code paths: JQL/CQL search and Jira get_issue. Every other identifier-bearing tool ignores it — all mutating tools, all Confluence read-by-key paths, and every Jira read-by-key tool other than get_issue (comments, worklogs, full attachment content, transitions). A user constrained to project PROJ / space SPACE can therefore read, create, modify, delete, and move issues and pages in any project/space the underlying credential can reach. The lone get_issue gate creates a false impression that read-by-key is protected, while sibling read tools circumvent it.

Evidence

Exhaustive grep: projects_filter appears only in jira/{config,search,issues,projects}.py; spaces_filter only in confluence/{config,search}.py (+ servers wiring). It is absent from every other module. Tools that do not check the allowlist (non-exhaustive):

• Jira reads-by-key (bypass get_issue's gate): get_issue_comments (comments.py:31), get_worklogs (worklog.py:204), get_issue_attachment_contents (attachments.py:146 — returns full attachment file bytes, exposed via the download_attachments tool which takes only an issue_key), get_transitions (transitions.py:79). Each calls the Atlassian API on an arbitrary issue_key with no project check.
• Jira writes: create_issue (issues.py:593), update_issue (:1103), delete_issue (:1477), move_issue (:1498, moves data across projects), batch_create_issues (:1784), add_comment (comments.py:197), transition_issue (transitions.py:120), add_worklog, add_watcher, create_issue_link, attachment uploads.
• Confluence reads & writes: get_page_content (pages.py:181, read-by-key bypass), get_page_comments, attachment reads, create_page (:670), update_page (:779), delete_page (:1286), move_page (:1432), copy (:1548), add_comment/add_inline_comment (comments.py). Controls that do enforce it (the only two): jira/search.py::_and_projects_filter + confluence/search.py::_and_spaces_filter (both also bypassable via ) OR ( — see companion advisory 04), and jira/issues.py::get_issue. No other read-by-key path — Jira or Confluence — has an equivalent gate.

Impact

• Read bypass (confidentiality, C:H): a restricted user can read full issue comments, worklogs, and attachment file contents (via download_attachments, issue_key-only) and any Confluence page/comment/attachment by ID from any project/space the credential can reach. Issue keys and page IDs are trivially enumerable.
• Write-scope bypass (integrity, I:H): in a shared-credential deployment (operator credentials via global fallback / external passthrough, with the allowlist as the only tenant boundary), any user can create/modify/delete/move Jira issues and Confluence pages in projects/spaces intended to be off-limits — including destructive delete_issue/delete_page and cross-project move_issue (data exfiltration by moving a restricted issue into an allowed project).
• The single get_issue gate is a false-assurance: it is the only read-by-key path checked, so operators may reasonably believe read-by-key is protected when it is not.

PR:N / CVSS 9.1 applies when ALLOW_GLOBAL_CRED_FALLBACK=true makes the endpoint serve unauthenticated requests with operator credentials.

Proof of concept

poc/write_bypass_poc.py statically analyzes the real source and reports, per tool, whether the allowlist variable is referenced in its body:

jira.get_issue (read-by-key)  [CONTROL]          True
jira.get_issue_comments (read)                   False  <-- BYPASS
jira.get_worklogs (read)                          False  <-- BYPASS
jira.get_issue_attachment_contents (file bytes)   False  <-- BYPASS
jira.get_transitions (read)                       False  <-- BYPASS
jira.create_issue (write)                         False  <-- BYPASS
jira.delete_issue (write)                         False  <-- BYPASS
jira.move_issue (write, cross-project)            False  <-- BYPASS
confluence.get_page_content (read-by-key)         False  <-- BYPASS
confluence.create_page/update/delete (write)      False  <-- BYPASS
Allowlist enforced ONLY on: jira.get_issue + JQL/CQL search.
RESULT: VULNERABLE — allowlist is not a real boundary
jira.delete_issue                       False  <-- BYPASS
jira.move_issue                         False  <-- BYPASS
confluence.get_page_content             False  <-- BYPASS
confluence.create_page/update/delete    False  <-- BYPASS
RESULT: VULNERABLE — allowlist is search/read-by-key(Jira)-only; writes and Confluence reads escape the boundary

Remediation

• Enforce the project/space allowlist centrally on every tool that takes an issue/project/space/page identifier — reads and writes — not only on search and Jira get_issue. Resolve the target's project/space and reject if outside the allowlist before performing the operation.
• Add the missing Confluence read-by-key gate mirroring Jira get_issue.
• Consider enforcing the boundary at the dependency/tool-dispatch layer so new tools inherit it by default.

Fix

Fixed in mcp-atlassian 0.24.1. Duplicate reports closed into this advisory: GHSA-w2rr-5298-w3w2, GHSA-5qqr-h8h4-jxj3, GHSA-3m9j-pqwm-7rp3, GHSA-2442-w8m8-cq8q, GHSA-p2f3-gj2x-j8rh, GHSA-63gc-grg5-wm39, GHSA-qrgx-mpgm-p7c8, GHSA-6f2p-xww9-wm23, GHSA-gx86-fmjj-gxpq, GHSA-m6c2-3wjj-8x2g, GHSA-j9p7-q3h7-rc9c, GHSA-mhg4-7hgf-384c, GHSA-cr3j-mmm5-fvqg. Their reporters are credited here.