[Bug]: CONFLUENCE_SPACES_FILTER is only enforced in confluence_search, not in other Confluence read tools

[gsobczyk]

Prerequisites

• I have searched the existing issues to make sure this bug has not already been reported.
• I have checked the README for relevant information.

Bug Description

CONFLUENCE_SPACES_FILTER is documented (.env.example:233) as limiting "searches and other operations" to an allowlist of spaces, but the code only enforces it inside confluence_search. Every other Confluence read tool (confluence_get_page, confluence_get_space_page_tree, confluence_get_page_children, confluence_get_page_ancestors, confluence_get_comments, etc.) ignores the filter entirely, so an agent (or user) can trivially read content from spaces outside the configured allowlist as long as the underlying credentials have access.

Steps to Reproduce

1. Set CONFLUENCE_SPACES_FILTER=ANYSPACE (a single, narrow space).
2. Ask an MCP client to search for content that actually lives in a different space (e.g. OTHERSPACE).
3. confluence_search correctly returns an empty result set — the filter works as intended here.
4. The agent falls back to confluence_get_space_page_tree(space_key=OTHERSPACE, ...) and then confluence_get_page(page_id=...) for a page found in that tree.
5. Both calls succeed and return full page content from OTHERSPACE, even though it's outside the configured CONFLUENCE_SPACES_FILTER allowlist.

Expected Behavior

CONFLUENCE_SPACES_FILTER should be a hard boundary enforced consistently across all Confluence tools that accept or resolve a space_key/page, not just confluence_search. Compare with the Jira equivalent (JIRA_PROJECTS_FILTER), which is enforced both in search (src/mcp_atlassian/jira/search.py) and in direct single-item lookups — jira_get_issue explicitly rejects issues whose project prefix isn't in the allowlist (src/mcp_atlassian/jira/issues.py:104-123).

Actual Behavior

Only `confluence_search` applies the filter, via `SearchMixin.search()` (`src/mcp_atlassian/confluence/search.py:113-115`):


for filter_str in (self.config.spaces_filter, spaces_filter):
    if filter_str:
        cql = self._and_spaces_filter(cql, filter_str)


No equivalent check exists in `src/mcp_atlassian/confluence/pages.py`, which backs `get_page`, `get_space_page_tree`, `get_page_children`, `get_child_pages`, `create_page`, etc. — none of these read `self.config.spaces_filter` at all.

mcp-atlassian Version

v0.22.1

Installation Method

From PyPI (pip install mcp-atlassian / uv add mcp-atlassian)

Operating System

Linux (Specify distribution below if relevant)

Python Version

3.14.4

Atlassian Instance Type

Confluence Server / Data Center

Client Application

opencode + mcp via uvx

Additional Context

No response

[ebarkhordar]

Confirmed by reading HEAD 0587fdc. I did not run this against a live Confluence, so this is a code read rather than a reproduction of your steps.

config.spaces_filter is read in exactly one place in the package: confluence/search.py:113. confluence/pages.py, comments.py and labels.py contain zero references to it, and there is no enforcement layer above them either. The filter_kwargs={"spaces_filter": None} at servers/dependencies.py:170 only feeds config construction at :658, it gates nothing.

Two points that widen the report, both of which change what a fix has to cover.

It is not only the read tools. Parsing the @confluence_mcp.tool decorators in servers/confluence.py gives 35 registered tools, and search is the only one that consults the filter. 15 of the other 34 are tagged write and are addressed by page_id or space_key exactly like the read ones:

add_label, create_page, update_page, update_page_section, delete_page, move_page, add_comment, reply_to_comment, add_inline_comment, upload_attachment, upload_attachments, delete_attachment, create_page_from_template, set_page_restrictions, copy_page

So the fallback path you describe also reaches delete_page, move_page and set_page_restrictions against a page in a space outside the allowlist. A fix scoped to the title would leave those open. The credentials have that access either way, so this is about honoring the operator's configured scope rather than privilege escalation, but the write tools are the part where the consequence is not recoverable by re-reading a page.

The Jira precedent is broader than the single site you cited. Alongside jira/issues.py:107 (get_issue), the allowlist is enforced at jira/projects.py:101, which drops non-allowlisted projects from the listing, and at servers/jira.py:3197. Jira enforces at search, single-item lookup and enumeration; Confluence enforces at search only.

On whether this is a bug or intended: the invariant is already stated in the repo's own words at confluence/search.py:109-112, "config.spaces_filter is a hard boundary and is always applied ... otherwise the tool argument would defeat the operator's allowlist in shared-credential deployments". That comment names the boundary and the threat model, but the guard it justifies only defends against the tool argument overriding the allowlist. Other entry points never reach the check.

Where to enforce looks like your call rather than something to guess at: a shared space_key resolver in pages.py would cover the tree and create paths, but the page_id-addressed tools need a page lookup before the space is even known, which costs an extra API call per call.

[amitvijapur]

Traced this — config.spaces_filter is read in exactly one place in the package, confluence/search.py, and nothing else in the Confluence tool surface checks it. I have a fix that adds a shared enforcement helper to ConfluenceClient and wires it into the page, comment, label, restriction, and template tool handlers (with a resolver for the page-ID-only ones), plus tests. Opening a PR now.