Mcp Atlassian
Monthly
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote caller to read any file accessible to the MCP process and have it uploaded to an attacker-controlled endpoint. The issue affects only deployments running the HTTP transports (streamable-http or sse) with READ_ONLY_MODE=false, where a request that carries X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token but no Authorization header is accepted as a 'pat' identity, so the attacker-chosen Atlassian URL is used to build the attachment client and the confluence_upload_attachment (or Jira attachment) tool accepts an arbitrary server-side file_path. CVSS 3.1 rates it 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact, a public Docker-based proof of concept was confirmed by the reporter so publicly available exploit code exists, and EPSS is low at 0.30% (23rd percentile) with no confirmed actively exploited (CISA KEV) status; version 0.22.0 fixes the flaw.
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network caller abuse the streamable HTTP transport, which accepts requests carrying no user identity and silently falls back to the operator's global Atlassian credentials, to force the upload_attachment tool to read any file readable by the MCP process and push its contents into an attacker-chosen Jira issue or Confluence page, where the attacker can retrieve them. Exploitation requires the server to be running the streamable HTTP transport, reachable by the attacker, and configured with shared operator credentials - stdio-only deployments and deployments that enforce per-user identity/tokens are not exposed - and impact is confidentiality-only (file exfiltration), with no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the underlying issue is a path-traversal flaw (CWE-22) fixed in version 0.22.0, and the practical risk is bounded more by who actually deploys this MCP server over the network than by exploit maturity.
MCP Atlassian servers before 0.22.0 write their plaintext OAuth fallback token file using permissions inherited from the process umask, so on a shared host with a permissive or default umask another local account can read the file and reuse the stored refresh and access tokens for Atlassian (Confluence/Jira) access. The flaw is a local, multi-user exposure rather than a remote one: the attacker must already hold a separate account on the same machine and the deployment must actually use the plaintext fallback storage path, which is why the independent assessment scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N instead of the vendor's AV:N rating. Because the leaked refresh token keeps working even after access-token rotation, credential rotation alone does not close the exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in the vendor-released version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an accepted MCP caller to read arbitrary files from the host on which the server runs: the confluence_upload_attachment tool opens a caller-supplied file_path after only converting it with os.path.abspath, with no check that the resolved path stays inside the workspace, and then uploads the contents as a Confluence attachment the caller can download back. The vulnerability is an access-gated, confused-deputy arbitrary-file-read (CWE-22, assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, no integrity or availability impact); exploitation requires an authenticated MCP caller (PR:L), a server older than 0.22.0 configured with Confluence credentials that can write attachments, and a space the attacker can read back - single-user local stdio deployments where the caller already owns the host gain nothing. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in version 0.22.0.
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to 0.22.0, where the Jira update_issue tool converts a caller-supplied attachments argument into local filesystem paths and passes them to the attachment upload implementation without any workspace confinement. A caller able to invoke the update_issue tool can therefore use the server as a confused deputy, reading arbitrary files (e.g. credentials, config, SSH keys) readable by the server process and attaching their contents to a Jira issue the caller controls, with confidentiality impact only - no write or code execution through this flaw. Exploitation is access-gated: the vendor rates it AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6), while our independent assessment scores it PR:L/S:U, since a permitted MCP caller and a shared-credential deployment are realistic prerequisites; no public exploit code has been identified at time of analysis.
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read arbitrary files readable by the server's OS user and exfiltrate them by pushing them to Confluence as attachments. The upload code path converts a caller-supplied file_path to an absolute path without the workspace confinement that had already been added to the download path (CVE-2026-27825), so relative or absolute traversal sequences escape the intended workspace. The independent assessment scores the flaw CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only, no integrity or availability impact), requiring an authenticated caller with access to the MCP tool; the vendor's advisory scored it 8.6 with PR:N and S:C. No public exploit identified at time of analysis, and instances at 0.22.0 or later are not affected.
Unauthenticated network callers can drive Jira and Confluence tool handlers using an operator's globally configured credentials in sooperset/mcp-atlassian prior to 0.22.0, when the server is run over the HTTP streamable-http transport without an independent authentication boundary. The root cause is a missing-authentication flaw (CWE-306) scored CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), giving remote, unauthenticated, low-complexity read and write access with the permissions of the configured service account and no availability impact. Exploitation is configuration-dependent - stdio deployments and instances fronted by an authenticating proxy or enforcing per-user OAuth identities are not exposed - and no public exploit or CISA KEV listing was identified at time of analysis. The issue is fixed in version 0.22.0.
MCP Atlassian server versions prior to 0.22.0 allow an authenticated MCP caller to read arbitrary files from the server host by supplying an absolute or traversal path to the file_path argument of the jira_upload_attachment or confluence_upload_attachment tools, whose bytes are then uploaded into Atlassian and can be read back by the same caller. Exploitation is conditional: it requires the server to be deployed in HTTP or multi-user mode (not single-user stdio), a permitted caller able to invoke the upload tools (CVSS PR:L), and shared operator credentials so the exfiltrated content lands where the attacker can retrieve it; impact is confidentiality-focused (C:H) with limited integrity effect (I:L) and no availability impact. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), though EPSS context was not provided; the vendor-released fix is version 0.22.0.
Arbitrary local file read in MCP Atlassian (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP caller who can reach the Jira or Confluence upload_attachment tool over the HTTP-exposed 'streamable-http' transport to supply a traversal or absolute file_path that is not confined to the workspace, causing the server process to read sensitive local files and exfiltrate them as Atlassian attachments. The vendor rates this 8.3 (CVSS 4.0) with PR:L, high confidentiality impact and no integrity or availability impact, consistent with our independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. Exploitation is limited by prerequisites: working Atlassian upload credentials and tool access must already be held, the HTTP transport must be exposed rather than stdio-only, and reachable data is bounded to files readable by the server process user; no public exploit code was identified at time of analysis and the issue is not listed in CISA KEV.
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised the configured Atlassian backend return a 3xx redirect pointing at an internal address (for example the 169.254.169.254 cloud metadata service), which the MCP server's HTTP session then follows - potentially returning cloud IAM credentials or other internal service data to the attacker. Only deployments configured through the basic-auth or oauth_pat branches are exposed, because those fetcher sessions fail to attach the _make_ssrf_safe_hook redirect validator that the header-PAT branch sets via attach_ssrf_hook=True; header-PAT deployments are not affected. Publicly available exploit code exists (no CISA KEV listing, so no confirmed active exploitation), the vendor fix ships in 0.22.0, and EPSS remains low at 0.32% (26th percentile) with the assessed vector requiring high attack complexity and a malicious upstream prerequisite.
Arbitrary server-local file read and exfiltration in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, low-privileged MCP caller abuse the upload_attachment tool for Confluence or Jira to read files on the server host via a caller-supplied file_path, then retrieve the pages' contents as a normal attachment. The vulnerability is CWE-22 (path traversal): the pre-0.22.0 code only normalized the path with os.path.abspath and performed no workspace confinement, so absolute paths and traversal sequences that escape the working directory are accepted. Impact is confidentiality-only (no write or code execution) and exploitation is conditionally gated - it matters primarily in shared-credential or multi-tenant deployments where a caller's legitimate upload capability exceeds its intended file-read scope; single-user, locally trusted deployments face negligible additional exposure. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor fix is available in version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a low-privileged authenticated MCP caller write attacker-chosen files into the server's working directory, because validate_safe_path defaults its base directory to os.getcwd() and the Confluence attachment call sites omit base_dir. Overwriting an importable Python module in that location can escalate to code execution once the application imports the modified module, and the vector intentionally bypasses the earlier remediation tracked as CVE-2026-27825. Exploitation requires permitted MCP tool access (CVSS vector shows PR:L, i.e. authenticated with low privileges) and a subsequent import or re-import of the overwritten module, so code execution is not immediate; no public exploit code has been identified at time of analysis and there is no CISA KEV entry. The vendor rates this 8.3, while an independent assessment confirms it is a genuine remote-exploitable code-execution path whose real-world priority is moderated by those preconditions.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 allows unauthenticated callers to reach internal or cloud metadata endpoints by exploiting a DNS-rebinding race, because the server validates a hostname's resolved IP and then lets Requests/urllib3 resolve that same hostname again at connection time. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N (7.5): no authentication is needed, but the attacker must control authoritative DNS for a low-TTL name that answers publicly during validation and privately during connection, and the server must actually be able to reach a valuable internal target for the attack to pay off. This is a bypass of the earlier CVE-2026-27826 hardening rather than a new class of bug, no public exploit code or confirmed active exploitation was identified at time of analysis, and environments already running 0.22.0 or with no reachable internal/metadata endpoints are not exploitable.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 applies its ENABLED_TOOLS and TOOLSETS least-privilege filters only when tools are enumerated via tools/list, and never re-checks them when a request is dispatched through tools/call. An authenticated, low-privileged MCP client that knows or guesses the exact name of an excluded tool can therefore invoke read, write, and delete operations against Confluence and Jira that the operator deliberately hid, yielding full confidentiality, integrity, and availability impact against Atlassian data (CVSS 3.1 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, CWE-862 Missing Authorization). The flaw is meaningful only where the toolset configuration is the trust boundary - the highest risk is in shared-credential or multi-tenant deployments - and no public exploit code was identified at time of analysis. A vendor-released patch is available in version 0.22.0.
Information disclosure in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an authenticated caller of the MCP server to read Jira issues, agile boards, and Confluence pages that the operator intended to exclude via JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER, because the Jira search path only checks whether a project clause is present rather than whether it is permitted, the Confluence search path applies an incomplete case-sensitive space check (and lets a caller-supplied spaces_filter replace rather than narrow the configured allowlist), and the Jira board APIs (get_board_issues, get_agile_boards) omit project-filter enforcement entirely. The flaw requires low privileges (an accepted MCP client) and no user interaction, but it only yields data beyond the intended scope when the server's shared operator credentials hold broader Atlassian access than the configured filter - the typical shared-credential, delegated, or multi-tenant MCP deployment. There is no confirmed active exploitation and no public exploit identified at time of analysis; the issue is fixed in 0.22.0, and an independent assessment rates it a moderate-priority filter-bypass/authorization control failure rather than a top-tier emergency.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticated caller to force the MCP server to send requests to an arbitrary destination of the attacker's choosing by supplying the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers, which are consumed by _process_authentication_headers without passing through validate_url_for_ssrf. A successful attack redirects the server's Atlassian fetchers at internal services or cloud metadata endpoints, leaking response data back to the caller (scope-changing, high confidentiality impact, no integrity or availability impact per the assessed vector); no public exploit code was identified at time of analysis and EPSS data was not supplied. The defect is an incomplete remediation of the earlier SSRF CVE-2026-27826, and the project shipped a fix in version 0.22.0.
Unauthenticated network clients that can reach an mcp-atlassian server running in HTTP (streamable-http) transport mode can invoke Atlassian tools using the operator's globally configured Jira or Confluence credentials, inheriting that account's read and write access to both products. The flaw is an authentication deficiency (CWE-287) in which the request path through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, and _get_fetcher accepts a request without a verified user identity and falls back to the shared, operator-scoped credential set; exploitation requires no authentication (PR:N), user interaction, or special privilege once the endpoint is reachable, which is why the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N (10.0). Exposure is limited to the shared-credential/multi-tenant deployment pattern - stdio-transport installs and per-user token deployments that never fall back to global credentials are not affected - and at the time of analysis no public exploit code had been identified and the issue was not confirmed actively exploited (CISA KEV).
Server-side request forgery in MCP Atlassian (sooperset) versions before 0.22.0 lets unauthenticated callers drive the server into issuing HTTP requests to internal or cloud-metadata addresses by exploiting a DNS-rebinding race in the header-based authentication flow. Only deployments on the header_pat branch, which trust caller-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers, are exposed; the URL is validated for SSRF once and then re-resolved by the HTTP client at connection time, so a low-TTL attacker-controlled hostname can return a public IP during validation and 127.0.0.1 or 169.254.169.254 during the actual request, with roughly 50 percent success per attempt. Publicly available exploit code exists (a DNS-rebinding proof of concept using rbndr.us), EPSS is low at 0.42 percent (36th percentile), there is no KEV listing indicating confirmed actively exploited (CISA KEV) status, and the vendor-released patch is version 0.22.0.
Arbitrary server-local file disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, permitted Confluence MCP caller read any file accessible to the server process by passing a traversal or absolute path to the upload_attachment tool and receiving the contents back as a published attachment. Exploitation requires only a valid MCP caller session (no user interaction, low privileges per PR:L), and the scope change in the CVSS vector reflects the server process acting as a confused deputy on behalf of the caller, yielding high confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no CISA KEV listing; the practical risk is highest in shared-credential or multi-tenant MCP deployments where the caller is less privileged than the server process, and is low in single-user deployments where the caller already owns the underlying filesystem. Vendor-released patch: 0.22.0.
Server-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0 allows remote, unauthenticated attackers to make the server issue HTTP requests to internal or otherwise protected network resources. The flaw lives in validate_url_for_ssrf, which parses a URL's authority differently from the Requests connection layer when the server runs the header-based Jira/Confluence URL authentication flow, so a crafted backslash-containing URL can pass validation as an external hostname while the HTTP client actually connects to an internal host. Exploitation is limited to deployments that accept client-supplied Atlassian base URLs, requires the attacker to win the parser-versus-connection-layer discrepancy reliably, and no public exploit code or confirmed active exploitation was identified at time of analysis.
MCP Atlassian, the Model Context Protocol server that bridges AI clients to Confluence and Jira, resolves client-supplied attachment paths on the server itself, so a remote client with write-tool access can read arbitrary files from the server host in versions before 0.22.0. The confluence_upload_attachment, confluence_upload_attachments and jira_update_issue tools all funnel an unconfined file_path into os.path.abspath() plus open(), and the resulting bytes are uploaded to Atlassian as an attachment — giving the attacker a convenient exfiltration channel for server files, environment-held Atlassian credentials, or other tenants' data. The vendor advisory includes a working proof-of-concept (publicly available exploit code exists), but no active exploitation is confirmed (no CISA KEV listing); the CVSS 3.1 score is 7.7 with EPSS not provided in the input. Only local single-user stdio deployments are outside the trust boundary.
Arbitrary file read via path traversal in mcp-atlassian prior to 0.22.0 allows any authenticated MCP client to supply an absolute or traversal path to the confluence_upload_attachment tool, causing the server to open and exfiltrate the targeted file as a Confluence attachment. On Linux deployments, /proc/self/environ exposes live API credentials including CONFLUENCE_API_TOKEN, AWS keys, and database passwords, enabling full Atlassian account takeover and lateral movement. A confirmed prompt injection attack chain means threat actors who can write content an AI agent will read - such as a malicious Jira ticket - can trigger the same credential exfiltration with zero MCP credentials; publicly available exploit code and a demonstration video exist.
MCP Atlassian server has a path traversal vulnerability enabling unauthorized access to Confluence and Jira data outside the intended scope.
Unauthenticated attackers can abuse the MCP Atlassian server to perform arbitrary outbound HTTP requests by manipulating HTTP headers, enabling credential theft from cloud instance metadata endpoints or internal network reconnaissance without requiring authentication. The vulnerability exists in the HTTP middleware layer prior to version 0.17.0, affecting Atlassian Confluence and Jira deployments. No patch is currently available.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an MCP caller who controls the public Jira base URL have a Jira user-lookup request redirected to an internal address, bypassing the SSRF redirect protections previously added for CVE-2026-27826. The vulnerable path is JiraUserMixin._lookup_user_by_permissions, which calls the module-level requests.get instead of the fetcher's protected session, so the response hook that enforces redirect validation is never applied. Impact is limited and blind (confidentiality-only, no integrity or availability effect) and, per the independent assessment, requires the attacker to control the Jira endpoint plus a server that issues a redirect to an internal target, making it most realistic in HTTP/multi-user or shared-credential deployments rather than single-user stdio setups with a fixed trusted Jira URL. No public exploit code was identified at time of analysis and there is no KEV listing; v0.22.0 resolves the issue.
Local credential disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 allows a co-resident local user or process to read stored Atlassian OAuth access and refresh tokens and reuse the associated Atlassian session. The server creates its ~/.mcp-atlassian directory and the oauth-<client_id>.json token file without explicit owner-only permission modes (CWE-732), so the resulting group- or world-readable bits - an artifact of a permissive process umask - expose the tokens to anyone with read access on the host; the CVSS vector (AV:L/PR:L) confirms this requires an existing local account and no network reachability. Only multi-user or multi-process hosts that rely on the OAuth token-file fallback are exposed; single-user hosts with a restrictive umask are not. No public exploit identified at time of analysis, and the vendor CVSS of 5.5 understates impact only marginally - the independent assessment adds a low integrity component (I:L) because a stolen refresh token can also be used to act within the victim's Atlassian tenant. The issue is fixed in version 0.22.0.
Reflected cross-site scripting in MCP Atlassian versions prior to 0.22.0 lets unauthenticated remote attackers inject markup or script through the OAuth error query parameter, which the CallbackHandler._send_response method in oauth_setup.py interpolates into an HTML page without escaping (CWE-79). Exploitation requires a deployment that uses the interactive OAuth setup flow and a targeted user who is actively completing that flow and opens the attacker's crafted authorization callback, which is why the assessed impact is confined to the victim's browser context (CVSS 5.4, C:L/I:L, UI:R) with no server-side code execution or Atlassian data-plane access. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in version 0.22.0.
Authenticated path traversal in MCP Atlassian (mcp-atlassian) prior to 0.22.0 lets a permitted MCP caller supply an absolute or traversal-laden file_path to the Confluence attachment-upload flow and cause the server to read and upload an arbitrary local file using the operator's credentials, exposing file contents to the linked Confluence instance. The flaw is a direct gap left by the CVE-2026-27825 fix, which hardened download destinations but never constrained upload source paths; only confidentiality is affected (no write or availability impact), and exploitation is bounded to files readable by the server process. No public exploit identified at time of analysis, and the issue is fully resolved by upgrading to 0.22.0.
Path traversal in MCP Atlassian (mcp-atlassian) before 0.22.0 allows an MCP caller that already holds attachment-upload authorization to supply an absolute path or ../ sequence to upload_attachment, causing the server to read an arbitrary server-local file and exfiltrate it through a Jira or Confluence attachment upload. The flaw is authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) and confidentiality-only: the resolved path is never confined to the server workspace, but there is no write, code-execution, or availability impact through this specific issue. No KEV listing and no public exploit code were identified at time of analysis, and the practical risk is bounded by the requirement that the caller is already trusted to invoke attachment tooling - highest in shared-credential or multi-tenant MCP deployments where the caller should not have host filesystem visibility. The vendor-released fix is version 0.22.0.
Authorization-boundary bypass in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 lets an authorized MCP caller search Jira projects and Confluence spaces that fall outside the administrator-configured allowlist, by supplying caller-controlled projects_filter/spaces_filter arguments that replace the operator's restriction or by embedding an explicit project/space clause that suppresses it. Rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), exploitation requires an already-authorized MCP caller plus a shared Atlassian credential whose access extends beyond the allowlist; the result is read-only information exposure with no integrity or availability impact. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); vendor-released patch: 0.22.0.
Plaintext storage of Atlassian OAuth credentials in MCP Atlassian before 0.22.0 lets any local user or process that can read the persisted token file recover live access and refresh tokens and reuse them against Confluence and Jira. The vulnerable code path is OAuthConfig._save_tokens, which writes ~/.mcp-atlassian/oauth-<client_id>.json using process-default permissions; on a host with a permissive umask, same-group or other local accounts can read it. Exploitation requires a pre-existing local foothold, a permissive umask, and that the OAuth plaintext-fallback file was actually created - it is not remotely exploitable and is not exposed on single-user hosts with a restrictive umask; no public exploit code was identified at time of analysis and this CVE is not in CISA KEV.
Path traversal in the MCP Atlassian MCP server (all versions prior to 0.22.0) allows an authenticated MCP caller that is authorized to invoke the Jira or Confluence attachment-upload tools to read arbitrary files as the server process. The upload tools accept a caller-supplied file_path and, before the fix, only normalised it with os.path.abspath without confining it to a workspace, so any path readable by the server account - tokens, keys, configuration - can be packaged and exfiltrated to an Atlassian issue or page; CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects high confidentiality loss but no integrity or availability impact, and no public exploit code has been identified at time of analysis. The issue matters most in shared-credential or multi-tenant deployments, where a low-privilege caller gains read access far beyond its intended Atlassian scope.
Server-side request forgery in the MCP Atlassian MCP server (versions 0.17.0 through 0.21.x) allows remote unauthenticated attackers to force the server to make outbound requests to internal addresses such as the cloud metadata endpoint 169.254.169.254. The flaw is an incomplete-fix TOCTOU: validate_url_for_ssrf resolves and approves the attacker-supplied X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url host once at middleware time, but the actual HTTP client re-resolves the raw hostname at connect time with no IP pinning, so a DNS-rebinding name can pass validation with a public IP and then resolve to a link-local or RFC1918 address. Exploitation is a documented, publicly described proof-of-concept rather than confirmed in-the-wild activity (no CISA KEV listing), and the vendor has released version 0.22.0 as the fix.
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote caller to read any file accessible to the MCP process and have it uploaded to an attacker-controlled endpoint. The issue affects only deployments running the HTTP transports (streamable-http or sse) with READ_ONLY_MODE=false, where a request that carries X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token but no Authorization header is accepted as a 'pat' identity, so the attacker-chosen Atlassian URL is used to build the attachment client and the confluence_upload_attachment (or Jira attachment) tool accepts an arbitrary server-side file_path. CVSS 3.1 rates it 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact, a public Docker-based proof of concept was confirmed by the reporter so publicly available exploit code exists, and EPSS is low at 0.30% (23rd percentile) with no confirmed actively exploited (CISA KEV) status; version 0.22.0 fixes the flaw.
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network caller abuse the streamable HTTP transport, which accepts requests carrying no user identity and silently falls back to the operator's global Atlassian credentials, to force the upload_attachment tool to read any file readable by the MCP process and push its contents into an attacker-chosen Jira issue or Confluence page, where the attacker can retrieve them. Exploitation requires the server to be running the streamable HTTP transport, reachable by the attacker, and configured with shared operator credentials - stdio-only deployments and deployments that enforce per-user identity/tokens are not exposed - and impact is confidentiality-only (file exfiltration), with no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the underlying issue is a path-traversal flaw (CWE-22) fixed in version 0.22.0, and the practical risk is bounded more by who actually deploys this MCP server over the network than by exploit maturity.
MCP Atlassian servers before 0.22.0 write their plaintext OAuth fallback token file using permissions inherited from the process umask, so on a shared host with a permissive or default umask another local account can read the file and reuse the stored refresh and access tokens for Atlassian (Confluence/Jira) access. The flaw is a local, multi-user exposure rather than a remote one: the attacker must already hold a separate account on the same machine and the deployment must actually use the plaintext fallback storage path, which is why the independent assessment scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N instead of the vendor's AV:N rating. Because the leaked refresh token keeps working even after access-token rotation, credential rotation alone does not close the exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in the vendor-released version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an accepted MCP caller to read arbitrary files from the host on which the server runs: the confluence_upload_attachment tool opens a caller-supplied file_path after only converting it with os.path.abspath, with no check that the resolved path stays inside the workspace, and then uploads the contents as a Confluence attachment the caller can download back. The vulnerability is an access-gated, confused-deputy arbitrary-file-read (CWE-22, assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, no integrity or availability impact); exploitation requires an authenticated MCP caller (PR:L), a server older than 0.22.0 configured with Confluence credentials that can write attachments, and a space the attacker can read back - single-user local stdio deployments where the caller already owns the host gain nothing. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in version 0.22.0.
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to 0.22.0, where the Jira update_issue tool converts a caller-supplied attachments argument into local filesystem paths and passes them to the attachment upload implementation without any workspace confinement. A caller able to invoke the update_issue tool can therefore use the server as a confused deputy, reading arbitrary files (e.g. credentials, config, SSH keys) readable by the server process and attaching their contents to a Jira issue the caller controls, with confidentiality impact only - no write or code execution through this flaw. Exploitation is access-gated: the vendor rates it AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6), while our independent assessment scores it PR:L/S:U, since a permitted MCP caller and a shared-credential deployment are realistic prerequisites; no public exploit code has been identified at time of analysis.
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read arbitrary files readable by the server's OS user and exfiltrate them by pushing them to Confluence as attachments. The upload code path converts a caller-supplied file_path to an absolute path without the workspace confinement that had already been added to the download path (CVE-2026-27825), so relative or absolute traversal sequences escape the intended workspace. The independent assessment scores the flaw CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only, no integrity or availability impact), requiring an authenticated caller with access to the MCP tool; the vendor's advisory scored it 8.6 with PR:N and S:C. No public exploit identified at time of analysis, and instances at 0.22.0 or later are not affected.
Unauthenticated network callers can drive Jira and Confluence tool handlers using an operator's globally configured credentials in sooperset/mcp-atlassian prior to 0.22.0, when the server is run over the HTTP streamable-http transport without an independent authentication boundary. The root cause is a missing-authentication flaw (CWE-306) scored CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), giving remote, unauthenticated, low-complexity read and write access with the permissions of the configured service account and no availability impact. Exploitation is configuration-dependent - stdio deployments and instances fronted by an authenticating proxy or enforcing per-user OAuth identities are not exposed - and no public exploit or CISA KEV listing was identified at time of analysis. The issue is fixed in version 0.22.0.
MCP Atlassian server versions prior to 0.22.0 allow an authenticated MCP caller to read arbitrary files from the server host by supplying an absolute or traversal path to the file_path argument of the jira_upload_attachment or confluence_upload_attachment tools, whose bytes are then uploaded into Atlassian and can be read back by the same caller. Exploitation is conditional: it requires the server to be deployed in HTTP or multi-user mode (not single-user stdio), a permitted caller able to invoke the upload tools (CVSS PR:L), and shared operator credentials so the exfiltrated content lands where the attacker can retrieve it; impact is confidentiality-focused (C:H) with limited integrity effect (I:L) and no availability impact. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), though EPSS context was not provided; the vendor-released fix is version 0.22.0.
Arbitrary local file read in MCP Atlassian (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP caller who can reach the Jira or Confluence upload_attachment tool over the HTTP-exposed 'streamable-http' transport to supply a traversal or absolute file_path that is not confined to the workspace, causing the server process to read sensitive local files and exfiltrate them as Atlassian attachments. The vendor rates this 8.3 (CVSS 4.0) with PR:L, high confidentiality impact and no integrity or availability impact, consistent with our independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. Exploitation is limited by prerequisites: working Atlassian upload credentials and tool access must already be held, the HTTP transport must be exposed rather than stdio-only, and reachable data is bounded to files readable by the server process user; no public exploit code was identified at time of analysis and the issue is not listed in CISA KEV.
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised the configured Atlassian backend return a 3xx redirect pointing at an internal address (for example the 169.254.169.254 cloud metadata service), which the MCP server's HTTP session then follows - potentially returning cloud IAM credentials or other internal service data to the attacker. Only deployments configured through the basic-auth or oauth_pat branches are exposed, because those fetcher sessions fail to attach the _make_ssrf_safe_hook redirect validator that the header-PAT branch sets via attach_ssrf_hook=True; header-PAT deployments are not affected. Publicly available exploit code exists (no CISA KEV listing, so no confirmed active exploitation), the vendor fix ships in 0.22.0, and EPSS remains low at 0.32% (26th percentile) with the assessed vector requiring high attack complexity and a malicious upstream prerequisite.
Arbitrary server-local file read and exfiltration in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, low-privileged MCP caller abuse the upload_attachment tool for Confluence or Jira to read files on the server host via a caller-supplied file_path, then retrieve the pages' contents as a normal attachment. The vulnerability is CWE-22 (path traversal): the pre-0.22.0 code only normalized the path with os.path.abspath and performed no workspace confinement, so absolute paths and traversal sequences that escape the working directory are accepted. Impact is confidentiality-only (no write or code execution) and exploitation is conditionally gated - it matters primarily in shared-credential or multi-tenant deployments where a caller's legitimate upload capability exceeds its intended file-read scope; single-user, locally trusted deployments face negligible additional exposure. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor fix is available in version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a low-privileged authenticated MCP caller write attacker-chosen files into the server's working directory, because validate_safe_path defaults its base directory to os.getcwd() and the Confluence attachment call sites omit base_dir. Overwriting an importable Python module in that location can escalate to code execution once the application imports the modified module, and the vector intentionally bypasses the earlier remediation tracked as CVE-2026-27825. Exploitation requires permitted MCP tool access (CVSS vector shows PR:L, i.e. authenticated with low privileges) and a subsequent import or re-import of the overwritten module, so code execution is not immediate; no public exploit code has been identified at time of analysis and there is no CISA KEV entry. The vendor rates this 8.3, while an independent assessment confirms it is a genuine remote-exploitable code-execution path whose real-world priority is moderated by those preconditions.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 allows unauthenticated callers to reach internal or cloud metadata endpoints by exploiting a DNS-rebinding race, because the server validates a hostname's resolved IP and then lets Requests/urllib3 resolve that same hostname again at connection time. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N (7.5): no authentication is needed, but the attacker must control authoritative DNS for a low-TTL name that answers publicly during validation and privately during connection, and the server must actually be able to reach a valuable internal target for the attack to pay off. This is a bypass of the earlier CVE-2026-27826 hardening rather than a new class of bug, no public exploit code or confirmed active exploitation was identified at time of analysis, and environments already running 0.22.0 or with no reachable internal/metadata endpoints are not exploitable.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 applies its ENABLED_TOOLS and TOOLSETS least-privilege filters only when tools are enumerated via tools/list, and never re-checks them when a request is dispatched through tools/call. An authenticated, low-privileged MCP client that knows or guesses the exact name of an excluded tool can therefore invoke read, write, and delete operations against Confluence and Jira that the operator deliberately hid, yielding full confidentiality, integrity, and availability impact against Atlassian data (CVSS 3.1 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, CWE-862 Missing Authorization). The flaw is meaningful only where the toolset configuration is the trust boundary - the highest risk is in shared-credential or multi-tenant deployments - and no public exploit code was identified at time of analysis. A vendor-released patch is available in version 0.22.0.
Information disclosure in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an authenticated caller of the MCP server to read Jira issues, agile boards, and Confluence pages that the operator intended to exclude via JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER, because the Jira search path only checks whether a project clause is present rather than whether it is permitted, the Confluence search path applies an incomplete case-sensitive space check (and lets a caller-supplied spaces_filter replace rather than narrow the configured allowlist), and the Jira board APIs (get_board_issues, get_agile_boards) omit project-filter enforcement entirely. The flaw requires low privileges (an accepted MCP client) and no user interaction, but it only yields data beyond the intended scope when the server's shared operator credentials hold broader Atlassian access than the configured filter - the typical shared-credential, delegated, or multi-tenant MCP deployment. There is no confirmed active exploitation and no public exploit identified at time of analysis; the issue is fixed in 0.22.0, and an independent assessment rates it a moderate-priority filter-bypass/authorization control failure rather than a top-tier emergency.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticated caller to force the MCP server to send requests to an arbitrary destination of the attacker's choosing by supplying the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers, which are consumed by _process_authentication_headers without passing through validate_url_for_ssrf. A successful attack redirects the server's Atlassian fetchers at internal services or cloud metadata endpoints, leaking response data back to the caller (scope-changing, high confidentiality impact, no integrity or availability impact per the assessed vector); no public exploit code was identified at time of analysis and EPSS data was not supplied. The defect is an incomplete remediation of the earlier SSRF CVE-2026-27826, and the project shipped a fix in version 0.22.0.
Unauthenticated network clients that can reach an mcp-atlassian server running in HTTP (streamable-http) transport mode can invoke Atlassian tools using the operator's globally configured Jira or Confluence credentials, inheriting that account's read and write access to both products. The flaw is an authentication deficiency (CWE-287) in which the request path through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, and _get_fetcher accepts a request without a verified user identity and falls back to the shared, operator-scoped credential set; exploitation requires no authentication (PR:N), user interaction, or special privilege once the endpoint is reachable, which is why the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N (10.0). Exposure is limited to the shared-credential/multi-tenant deployment pattern - stdio-transport installs and per-user token deployments that never fall back to global credentials are not affected - and at the time of analysis no public exploit code had been identified and the issue was not confirmed actively exploited (CISA KEV).
Server-side request forgery in MCP Atlassian (sooperset) versions before 0.22.0 lets unauthenticated callers drive the server into issuing HTTP requests to internal or cloud-metadata addresses by exploiting a DNS-rebinding race in the header-based authentication flow. Only deployments on the header_pat branch, which trust caller-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers, are exposed; the URL is validated for SSRF once and then re-resolved by the HTTP client at connection time, so a low-TTL attacker-controlled hostname can return a public IP during validation and 127.0.0.1 or 169.254.169.254 during the actual request, with roughly 50 percent success per attempt. Publicly available exploit code exists (a DNS-rebinding proof of concept using rbndr.us), EPSS is low at 0.42 percent (36th percentile), there is no KEV listing indicating confirmed actively exploited (CISA KEV) status, and the vendor-released patch is version 0.22.0.
Arbitrary server-local file disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, permitted Confluence MCP caller read any file accessible to the server process by passing a traversal or absolute path to the upload_attachment tool and receiving the contents back as a published attachment. Exploitation requires only a valid MCP caller session (no user interaction, low privileges per PR:L), and the scope change in the CVSS vector reflects the server process acting as a confused deputy on behalf of the caller, yielding high confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no CISA KEV listing; the practical risk is highest in shared-credential or multi-tenant MCP deployments where the caller is less privileged than the server process, and is low in single-user deployments where the caller already owns the underlying filesystem. Vendor-released patch: 0.22.0.
Server-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0 allows remote, unauthenticated attackers to make the server issue HTTP requests to internal or otherwise protected network resources. The flaw lives in validate_url_for_ssrf, which parses a URL's authority differently from the Requests connection layer when the server runs the header-based Jira/Confluence URL authentication flow, so a crafted backslash-containing URL can pass validation as an external hostname while the HTTP client actually connects to an internal host. Exploitation is limited to deployments that accept client-supplied Atlassian base URLs, requires the attacker to win the parser-versus-connection-layer discrepancy reliably, and no public exploit code or confirmed active exploitation was identified at time of analysis.
MCP Atlassian, the Model Context Protocol server that bridges AI clients to Confluence and Jira, resolves client-supplied attachment paths on the server itself, so a remote client with write-tool access can read arbitrary files from the server host in versions before 0.22.0. The confluence_upload_attachment, confluence_upload_attachments and jira_update_issue tools all funnel an unconfined file_path into os.path.abspath() plus open(), and the resulting bytes are uploaded to Atlassian as an attachment — giving the attacker a convenient exfiltration channel for server files, environment-held Atlassian credentials, or other tenants' data. The vendor advisory includes a working proof-of-concept (publicly available exploit code exists), but no active exploitation is confirmed (no CISA KEV listing); the CVSS 3.1 score is 7.7 with EPSS not provided in the input. Only local single-user stdio deployments are outside the trust boundary.
Arbitrary file read via path traversal in mcp-atlassian prior to 0.22.0 allows any authenticated MCP client to supply an absolute or traversal path to the confluence_upload_attachment tool, causing the server to open and exfiltrate the targeted file as a Confluence attachment. On Linux deployments, /proc/self/environ exposes live API credentials including CONFLUENCE_API_TOKEN, AWS keys, and database passwords, enabling full Atlassian account takeover and lateral movement. A confirmed prompt injection attack chain means threat actors who can write content an AI agent will read - such as a malicious Jira ticket - can trigger the same credential exfiltration with zero MCP credentials; publicly available exploit code and a demonstration video exist.
MCP Atlassian server has a path traversal vulnerability enabling unauthorized access to Confluence and Jira data outside the intended scope.
Unauthenticated attackers can abuse the MCP Atlassian server to perform arbitrary outbound HTTP requests by manipulating HTTP headers, enabling credential theft from cloud instance metadata endpoints or internal network reconnaissance without requiring authentication. The vulnerability exists in the HTTP middleware layer prior to version 0.17.0, affecting Atlassian Confluence and Jira deployments. No patch is currently available.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an MCP caller who controls the public Jira base URL have a Jira user-lookup request redirected to an internal address, bypassing the SSRF redirect protections previously added for CVE-2026-27826. The vulnerable path is JiraUserMixin._lookup_user_by_permissions, which calls the module-level requests.get instead of the fetcher's protected session, so the response hook that enforces redirect validation is never applied. Impact is limited and blind (confidentiality-only, no integrity or availability effect) and, per the independent assessment, requires the attacker to control the Jira endpoint plus a server that issues a redirect to an internal target, making it most realistic in HTTP/multi-user or shared-credential deployments rather than single-user stdio setups with a fixed trusted Jira URL. No public exploit code was identified at time of analysis and there is no KEV listing; v0.22.0 resolves the issue.
Local credential disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 allows a co-resident local user or process to read stored Atlassian OAuth access and refresh tokens and reuse the associated Atlassian session. The server creates its ~/.mcp-atlassian directory and the oauth-<client_id>.json token file without explicit owner-only permission modes (CWE-732), so the resulting group- or world-readable bits - an artifact of a permissive process umask - expose the tokens to anyone with read access on the host; the CVSS vector (AV:L/PR:L) confirms this requires an existing local account and no network reachability. Only multi-user or multi-process hosts that rely on the OAuth token-file fallback are exposed; single-user hosts with a restrictive umask are not. No public exploit identified at time of analysis, and the vendor CVSS of 5.5 understates impact only marginally - the independent assessment adds a low integrity component (I:L) because a stolen refresh token can also be used to act within the victim's Atlassian tenant. The issue is fixed in version 0.22.0.
Reflected cross-site scripting in MCP Atlassian versions prior to 0.22.0 lets unauthenticated remote attackers inject markup or script through the OAuth error query parameter, which the CallbackHandler._send_response method in oauth_setup.py interpolates into an HTML page without escaping (CWE-79). Exploitation requires a deployment that uses the interactive OAuth setup flow and a targeted user who is actively completing that flow and opens the attacker's crafted authorization callback, which is why the assessed impact is confined to the victim's browser context (CVSS 5.4, C:L/I:L, UI:R) with no server-side code execution or Atlassian data-plane access. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in version 0.22.0.
Authenticated path traversal in MCP Atlassian (mcp-atlassian) prior to 0.22.0 lets a permitted MCP caller supply an absolute or traversal-laden file_path to the Confluence attachment-upload flow and cause the server to read and upload an arbitrary local file using the operator's credentials, exposing file contents to the linked Confluence instance. The flaw is a direct gap left by the CVE-2026-27825 fix, which hardened download destinations but never constrained upload source paths; only confidentiality is affected (no write or availability impact), and exploitation is bounded to files readable by the server process. No public exploit identified at time of analysis, and the issue is fully resolved by upgrading to 0.22.0.
Path traversal in MCP Atlassian (mcp-atlassian) before 0.22.0 allows an MCP caller that already holds attachment-upload authorization to supply an absolute path or ../ sequence to upload_attachment, causing the server to read an arbitrary server-local file and exfiltrate it through a Jira or Confluence attachment upload. The flaw is authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) and confidentiality-only: the resolved path is never confined to the server workspace, but there is no write, code-execution, or availability impact through this specific issue. No KEV listing and no public exploit code were identified at time of analysis, and the practical risk is bounded by the requirement that the caller is already trusted to invoke attachment tooling - highest in shared-credential or multi-tenant MCP deployments where the caller should not have host filesystem visibility. The vendor-released fix is version 0.22.0.
Authorization-boundary bypass in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 lets an authorized MCP caller search Jira projects and Confluence spaces that fall outside the administrator-configured allowlist, by supplying caller-controlled projects_filter/spaces_filter arguments that replace the operator's restriction or by embedding an explicit project/space clause that suppresses it. Rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), exploitation requires an already-authorized MCP caller plus a shared Atlassian credential whose access extends beyond the allowlist; the result is read-only information exposure with no integrity or availability impact. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); vendor-released patch: 0.22.0.
Plaintext storage of Atlassian OAuth credentials in MCP Atlassian before 0.22.0 lets any local user or process that can read the persisted token file recover live access and refresh tokens and reuse them against Confluence and Jira. The vulnerable code path is OAuthConfig._save_tokens, which writes ~/.mcp-atlassian/oauth-<client_id>.json using process-default permissions; on a host with a permissive umask, same-group or other local accounts can read it. Exploitation requires a pre-existing local foothold, a permissive umask, and that the OAuth plaintext-fallback file was actually created - it is not remotely exploitable and is not exposed on single-user hosts with a restrictive umask; no public exploit code was identified at time of analysis and this CVE is not in CISA KEV.
Path traversal in the MCP Atlassian MCP server (all versions prior to 0.22.0) allows an authenticated MCP caller that is authorized to invoke the Jira or Confluence attachment-upload tools to read arbitrary files as the server process. The upload tools accept a caller-supplied file_path and, before the fix, only normalised it with os.path.abspath without confining it to a workspace, so any path readable by the server account - tokens, keys, configuration - can be packaged and exfiltrated to an Atlassian issue or page; CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects high confidentiality loss but no integrity or availability impact, and no public exploit code has been identified at time of analysis. The issue matters most in shared-credential or multi-tenant deployments, where a low-privilege caller gains read access far beyond its intended Atlassian scope.
Server-side request forgery in the MCP Atlassian MCP server (versions 0.17.0 through 0.21.x) allows remote unauthenticated attackers to force the server to make outbound requests to internal addresses such as the cloud metadata endpoint 169.254.169.254. The flaw is an incomplete-fix TOCTOU: validate_url_for_ssrf resolves and approves the attacker-supplied X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url host once at middleware time, but the actual HTTP client re-resolves the raw hostname at connect time with no IP pinning, so a DNS-rebinding name can pass validation with a public IP and then resolve to a link-local or RFC1918 address. Exploitation is a documented, publicly described proof-of-concept rather than confirmed in-the-wild activity (no CISA KEV listing), and the vendor has released version 0.22.0 as the fix.