Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
30 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The uploadattachment method in confluence/attachments.py reads and uploads arbitrary local files to Confluence without calling validatesafepath(). Both download methods (downloadattachment at line 223, downloadcontentattachments at line 272) correctly call validatesafepath() before writing files, but the upload path at lines 35-79 skips this check entirely. An AI agent connected via MCP (or an attacker influencing that agent through prompt injection) can read any file on the host and exfiltrate it by uploading it as a Confluence page attachment. Vulnerable Code File: src/mcpatlassian/confluence/attachments.py, lines 62-79 The validatesafepath function is already imported at line 9 of the same file, and used in the download methods. It was just not added to the upload path. Proof of Concept Tested with mcp-atlassian 0.21.1 on Python 3.11 (EC2, Amazon Linux 2023). An MCP tool call like this reads /etc/passwd and uploads it to Confluence: Impact Exfiltration of any file readable…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When OAuth tokens are saved, MCP Atlassian always writes a plaintext fallback copy under ~/.mcp-atlassian/oauth-<clientid.json. The fallback file is created with the process default umask rather than restrictive permissions. In this environment the file was created as mode 0664, exposing access and refresh tokens to same-group local users and any process that can read the home directory. Details OAuthConfig.savetokens() stores OAuth token data in keyring, but it also unconditionally maintains a plaintext file fallback for backwards compatibility in src/mcpatlassian/utils/oauth.py:350-386. If keyring saving fails it also falls back to the same file path in src/mcpatlassian/utils/oauth.py:387-391. The fallback writer creates ~/.mcp-atlassian and then writes oauth-<clientid.json with a normal open(tokenpath, "w") call in src/mcpatlassian/utils/oauth.py:392-420. No mode=0o600, os.open(..., 0o600), chmod, or owner-only directory permission is applied. The file contains both…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for the SSRF vulnerability tracked as GHSA-7r34-79r5-rcc9 / CVE-2026-27826 is incomplete. That fix added two defenses: validateurlforssrf() on the per-request X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers (blocking a directly-internal base URL), and a redirect-validation hook (makessrfsafehook) attached to the fetcher's HTTP session so that an attacker-controlled public host cannot redirect outbound requests to an internal address. However, one outbound request path does not go through the hooked session. JiraUserMixin.lookupuserbypermissions issues its request with the module-level requests.get instead of self.jira.session.get, so the redirect-validation hook never runs for it. An unauthenticated attacker (in the HTTP / multi-tenant transport mode that binds 0.0.0.0 with no credentials) can therefore set a public base URL that passes validateurlforssrf(), then have their own server return an HTTP redirect to an internal address. The bare requests.get…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Jira and Confluence attachment upload tools accept caller-controlled file path parameters and read those paths from the MCP server's local filesystem before uploading the file as an Atlassian attachment. In local stdio deployments, this can expose files readable by the user's MCP process. In documented HTTP/SSE or streamable-http deployments, the impact is higher: any MCP client that is allowed to invoke write/upload tools can cause the server process to read a server-local file and upload it to Jira or Confluence. This is not dependent on an AI prompt injection or model behavior. It can be triggered deterministically with a normal MCP tool call. Details The vulnerable behavior exists because upload tool arguments are treated as server-local filesystem paths. Relevant implementation points: - mcpatlassian.confluence.attachments.AttachmentsMixin.uploadattachment - Accepts filepath. - Converts the supplied value to an absolute path when needed. - Checks existence with…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mcp-atlassian deploys in two common patterns: Pattern A (single-user, server-side credentials): operator sets JIRAUSERNAME + JIRAAPITOKEN (or CONFLUENCEUSERNAME + CONFLUENCEAPITOKEN) in environment variables. Server uses these to call Jira/Confluence. This is the documented quickstart pattern. Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth proxy or accepts per-user tokens via Authorization or service headers. The authentication mechanism in HTTP transport has two issues that combine to permit unauthenticated access to Pattern A deployments: 1. AtlassianOpaqueTokenVerifier.verifytoken() at src/mcpatlassian/utils/tokenverifier.py accepts any non-empty string as a valid token: async def verifytoken(self, token: str) - AccessToken | None: if not token: return None scopes = self.requiredscopes or [] return AccessToken( token=token, clientid="atlassian", scopes=scopes, expiresat=int(time.time()) + 86400 30, ) The docstring documents this: "we accept…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Environment - Project: sooperset/mcp-atlassian - Affected function: validateurlforssrf() - Affected path: header-based Jira/Confluence URL authentication flow - Tested endpoint: POST /mcp - Tested version: 2.14.5 Description The SSRF protection in validateurlforssrf() can be bypassed with a URL containing a backslash before userinfo-like syntax. Affected code: Payload: For this input, urllib.parse.urlparse() treats the hostname as: Therefore, validateurlforssrf() validates www.baidu.com instead of 127.0.0.1. However, the downstream request made through the Atlassian client / requests.Session reaches the local service: This allows an attacker-controlled Jira URL to target loopback or internal services. Proof of Concept Start a local HTTP server: Start mcp-atlassian with streamable HTTP transport on port 9000. Initialize an MCP session with the malicious Jira URL: Send the initialized notification using the returned Mcp-Session-Id: Trigger Jira fetcher creation and token validation:…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The path traversal fix introduced in v0.17.0 (GHSA-xjgw-4wvw-rgm4) is incomplete. validatesafepath() is called without an explicit basedir, defaulting to os.getcwd(). In standard container deployments the process CWD is the application directory (e.g. /app), so paths within that directory, including the application's own Python source modules, pass validation without raising an exception. An attacker can overwrite a module file and achieve remote code execution on the next process restart. Versions = 0.17.0 are not fully patched as stated in the original advisory. Confirmed on v0.21.0 (latest). Details src/mcpatlassian/utils/io.py — validatesafepath() defaults to CWD when no basedir is supplied: Both call sites in src/mcpatlassian/confluence/attachments.py omit basedir: When the process CWD is /app, any path under /app satisfies isrelativeto(CWD) and passes the guard, including all Python source modules: PoC Prerequisites: same as GHSA-xjgw-4wvw-rgm4 — Confluence credentials…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The UserTokenMiddleware extracts URLs from X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url HTTP headers and passes them directly to API client constructors without any SSRF validation. Affected Package - Ecosystem: PyPI - Package: mcp-atlassian - Affected versions: all versions before fix commit 5cd697dfce91 - Patched versions: = commit 5cd697dfce91 Details In main.py, processauthenticationheaders() extracts URLs from ASGI headers without validation. In dependencies.py, getjirafetcher() creates JiraConfig with url=jiraurlheader directly. There is no validateurl call, no IP range check, no hostname validation. The fix adds URL validation to some paths but the header-based URL extraction in processauthenticationheaders() still passes raw URLs through. The derived config objects use the header URL directly and the fetcher makes HTTP requests to that URL. PoC Steps to reproduce: 1. git clone https://github.com/sooperset/mcp-atlassian /tmp/mcp-atlassiantest 2. cd…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OAuth 2.0 setup wizard's local callback HTTP server reflects the error query parameter directly into an HTML response without any sanitization or encoding. An attacker can craft a malicious callback URL containing JavaScript in the error parameter that executes in the victim's browser when the setup wizard is running. The server binds to all network interfaces (0.0.0.0), making it accessible from the local network rather than just localhost. Details The vulnerability exists in the CallbackHandler class in src/mcpatlassian/utils/oauthsetup.py. Step 1 -- Attacker-controlled input enters unsanitized: At line 63-66, the error query parameter from the URL is read and interpolated into a message string without HTML escaping: Step 2 -- Unsanitized input is injected into HTML: At line 124-125 in sendresponse, the message variable (containing the unescaped attacker input) is injected directly into the HTML template via f-string interpolation: Step 3 -- Server listens on all…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mcp-atlassian exposes an MCP tool confluenceuploadattachment whose filepath argument is passed directly to open(filepath, "rb") without any path validation. An attacker able to invoke the tool can read arbitrary files readable by the server process and exfiltrate them into a multipart upload directed at an attacker-controlled Confluence host. In the default streamable-http transport the server binds 0.0.0.0 with no built-in authentication, making this remotely exploitable without credentials. This is the read-side symmetric twin of GHSA-xjgw-4wvw-rgm4 / CVE-2026-27825 (fixed in v0.17.0). The v0.17.0 patch only covered the download/write path; the upload path that reads local files was left unguarded. Details Vulnerable sink src/mcpatlassian/confluence/attachments.py:477 filepath is attacker-controlled end-to-end. Taint source src/mcpatlassian/servers/confluence.py:1290-1369, tool definition at :1307: No Pydantic pattern=, no validator, no validatesafepath() call. Call chain…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OAuth token fallback file storage in OAuthConfig.savetokenstofile() creates token files containing access tokens, refresh tokens, and cloud IDs with default filesystem permissions (typically 0644 on Linux, world-readable). Any local user on a shared system can read these files to obtain full Atlassian API credentials, enabling unauthorized access to the victim's Jira and Confluence data. Details The vulnerability exists in src/mcpatlassian/utils/oauth.py in the savetokenstofile method. Step 1 -- Directory created without restrictive permissions: At line 402-403, the token directory is created with mkdir(existok=True) which uses the default umask (typically creating directories with mode 0755): Step 2 -- Token file written with default permissions: At line 417-418, the token file containing sensitive credentials is written using open() with no explicit mode, inheriting default umask permissions (typically 0644 on Linux): Step 3 -- The file contains full API credentials:…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Missing path validation in confluenceuploadattachment allows any authenticated MCP client to read arbitrary files from the server filesystem and exfiltrate their contents to Confluence. On Linux deployments, /proc/self/environ yields all runtime secrets in a single call. --- Details AttachmentsMixin.uploadattachment() in src/mcpatlassian/confluence/attachments.py opens the caller-supplied filepath with no boundary check: The download path was correctly hardened in GHSA-xjgw-4wvw-rgm4 via validatesafepath() (lines 223, 272). That fix was not applied to the upload path, leaving it completely unguarded. The MCP tool layer (servers/confluence.py:1295) passes filepath verbatim with no additional sanitization. --- PoC Tested on mcp-atlassian 0.21.1 against live Confluence Cloud. Attachment confirmed uploaded and retrieved with full credential content intact. --- Impact Any MCP client with edit access to one Confluence page can read arbitrary files from the server process. On…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
makessrfsafehook() blocks HTTP redirects to private/internal IPs by validating the Location header before the client follows a 3xx response. The problem is that this hook is only attached in one of three authentication branches — the header-PAT path. Basic auth and OAuth branches skip it entirely, so if the connected Atlassian server returns a redirect to something like http://169.254.169.254/, the requests session follows it without complaint. This is an incomplete fix for GHSA-7r34-79r5-rcc9. The hook works fine when it's there — it just isn't there for most production auth configurations. Details In src/mcpatlassian/servers/dependencies.py, three branches construct a fetcher and call createandvalidate(). Only Branch 1 passes attachssrfhook=True: attachssrfhook defaults to False, so branches 2 and 3 silently skip the protection. The hook itself (makessrfsafehook) is straightforward — it checks response.isredirect, grabs the Location header, and calls validateurlforssrf() to…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The upload attachment tools in both Confluence and Jira accept arbitrary file paths without path traversal validation. The uploadattachment methods read any file accessible to the server process and upload it to a Confluence page or Jira issue. Despite the existence of a validatesafepath utility function (used correctly in download operations), the upload paths do not use it. This allows an authenticated MCP client (or an AI assistant manipulated via prompt injection) to exfiltrate arbitrary files from the server filesystem to an attacker-controlled Confluence page or Jira issue. Details The vulnerability exists in two parallel code paths: Confluence: src/mcpatlassian/confluence/attachments.py:35-108 src/mcpatlassian/confluence/attachments.py:62-65 Convert to absolute path if relative if not os.path.isabs(filepath): filepath = os.path.abspath(filepath) Check if file exists if not os.path.exists(filepath): error... The filepath parameter is only checked for existence,…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSRF protection for header-based authentication uses a validate-then-use pattern vulnerable to DNS rebinding. validateurlforssrf resolves the hostname via DNS and checks that the resolved IP is globally routable. However, the actual HTTP request happens later, during which the DNS record may have changed to point to an internal IP (127.0.0.1, 169.254.169.254, etc.). The SSRF redirect hook only validates redirect targets, not the initial connection. Details The vulnerability spans main.py (validation) and dependencies.py (use). Step 1 -- URL validation at middleware time: In src/mcpatlassian/servers/main.py:524-531, the URL from X-Atlassian-Jira-Url is validated: if jiraurlstr: ssrferror = validateurlforssrf(jiraurlstr) if ssrferror: blocked validateurlforssrf (src/mcpatlassian/utils/urls.py:113-116) resolves DNS and checks isglobal: dnserror = checkdnsresolution(hostname) if dnserror: return dnserror Step 2 -- HTTP request happens later with a separate DNS resolution:…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The uploadattachment functions in both the Jira and Confluence modules accept a user-controlled filepath parameter and open the specified file for reading without calling validatesafepath(). An authenticated MCP client can supply an arbitrary path such as /etc/passwd or /proc/self/environ, causing the server process to read and transmit the file's contents to the remote Atlassian instance as an attachment. This is an incomplete fix relative to GHSA-xjgw-4wvw-rgm4: the downloadattachment and downloadissueattachments paths were hardened with validatesafepath(), but the upload direction was left unguarded in both the Jira and Confluence modules. --- Details Affected functions: | File | Function | Line | |------|----------|------| | src/mcpatlassian/jira/attachments.py | uploadattachment() | ~372–415 | | src/mcpatlassian/confluence/attachments.py | uploadattachment() | ~62–108 | | src/mcpatlassian/confluence/attachments.py | uploadattachmentdirect() | ~476–477 | Jira — vulnerable…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The confluenceuploadattachment and confluenceuploadattachments MCP tools accept a filepath parameter and do not validate that the path is confined to an allowed directory before opening the file. An attacker who can call these tools can read any file accessible to the MCP server process (SSH keys, .env files, API credentials) and exfiltrate it by uploading it to Confluence. Note: The Jira uploadattachment mixin method in jira/attachments.py has the same missing validation, but it is NOT registered as an MCP tool in servers/jira.py and is therefore not currently reachable via MCP. It should still be patched to prevent future exposure if Jira upload tools are added. This is an incomplete fix for CVE-2026-27825. That CVE was patched by adding validatesafepath() to download operations (v0.17.0). The same protection was not applied to upload operations. Details validatesafepath() is imported in both confluence/attachments.py and jira/attachments.py and is correctly called in all…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an arbitrary local file READ vulnerability on the Confluence and Jira uploadattachment tool paths. It's the symmetric counterpart of the file-write vulnerability you patched as CVE-2026-27825. The write direction was fixed; the read direction was left open. Reporter: Sean Valentine Severity: High (Critical in LLM-driven / prompt-injection deployments) Affected versions: main branch as of 2026-04-21. Both Confluence and Jira upload paths. Details File: src/mcpatlassian/confluence/attachments.py lines 62-78 and 477 Same shape in src/mcpatlassian/jira/attachments.py around lines 374-386. validatesafepath() was added to the download paths as the CVE-2026-27825 fix, but the symmetric upload paths were never updated. os.path.abspath() alone does not restrict the result to any safe base directory, so absolute paths like /etc/shadow, /root/.ssh/idrsa, or ~/.aws/credentials are opened and uploaded verbatim. The Jira updateissue tool exposes the same primitive via its…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files Date: 2026-05-05 Target: sooperset/mcp-atlassian Commit: d8bc78698a63cb6b321c7ca796d6329d448f7f6d Summary mcp-atlassian supports HTTP/SSE deployment for persistent, remote, and multi-user use. In that mode, write-capable Jira and Confluence attachment flows accept caller-controlled server-local file paths and read those paths without an upload-source allowlist or base directory restriction. An authenticated caller, or a prompt-injected agent with tool-call capability, can cause the MCP server process to read a local file it can access and attach that file into a Jira issue or Confluence page using configured Atlassian credentials. This is distinct from the prior download-path advisory: that issue was an arbitrary file write sink. This path is upload-source local file disclosure. Impact Impact is local file disclosure through an authenticated Atlassian attachment write. In Docker/Kubernetes deployments…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ENABLEDTOOLS and TOOLSETS filters are enforced at tools/list time only. tools/call dispatches from the full unfiltered tool registry (73 tools). Any user with access to the server endpoint that knows a tool name can invoke it directly. Tool names are not secret since mcp-atlassian is open source. Any direct JSON-RPC call bypasses the restriction entirely. READONLYMODE is not affected: it has dual enforcement at list time (listtoolsmcp) and call time @checkwriteaccess decorator. The developers applied the correct pattern to READONLYMODE but not to ENABLEDTOOLS or toolsets - confirming this is an implementation oversight. Impact Any user with access to the MCP server's HTTP endpoint can invoke any of the 73 registered tools regardless of ENABLEDTOOLS or TOOLSETS configuration - including write and delete operations on Jira issues, Confluence pages, etc. Operators deploying mcp-atlassian via Streamable HTTP rely on ENABLEDTOOLS to enforce least-privilege access; the bypass…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical Confused Deputy (Arbitrary File Read & Exfiltration) vulnerability in the Atlassian MCP server (Python) allows an AI agent to exfiltrate sensitive host files and environment secrets. By providing absolute system paths to the attachments parameter of the updateissue tool, an agent can force the privileged MCP process to read and upload any file it has access to—including its own environment variables and host configuration—directly to a Jira ticket. Details The vulnerability is located in the updateissue tool handler. The attachments parameter accepts a list of file paths that are passed directly to the Jira API's upload method without any sanitization or validation. Specifically, the implementation fails to: 1. Restrict paths to a safe workspace: It accepts absolute paths starting with /. 2. Prevent directory traversal: It does not filter for ../ sequences. 3. Validate ownership: It allows the process to read system-level files (like /proc/self/environ) that the…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MCP Atlassian exposes Jira and Confluence attachment upload tools that accept arbitrary local filesystem paths and upload those file contents to Atlassian. In HTTP or multi-user deployments, an MCP caller who can invoke write tools can cause the server to read any file accessible to the MCP process and send it to Jira/Confluence as an attachment. Details The Confluence MCP upload tool accepts a filepath described as an absolute or relative server path in src/mcpatlassian/servers/confluence.py:1290-1316 and forwards it directly to confluencefetcher.uploadattachment() in src/mcpatlassian/servers/confluence.py:1356-1363. The multi-upload variant accepts comma-separated local paths in src/mcpatlassian/servers/confluence.py:1372-1449. The Confluence attachment implementation converts relative paths to absolute paths, checks only existence, and then opens the path for upload. There is no call to validatesafepath() or any allowed directory check for uploads in…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 JIRAPROJECTSFILTER and CONFLUENCESPACESFILTER 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 jirasearch jql | substring-bypass | 🔴 LIVE PROVEN 2026-05-18 on real Atlassian Cloud | | A2 | Confluence confluencesearch cql |…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The mcp-atlassian server exposes an MCP tool (confluenceuploadattachment and the Jira attachment variant) that accepts an arbitrary server-side file path and opens it for upload without any path validation. When the server is deployed in HTTP transport mode (streamable-http or sse), a remote, unauthenticated attacker can supply attacker-controlled Atlassian service headers (X-Atlassian-Confluence-Url / X-Atlassian-Confluence-Personal-Token) to redirect the upload to an attacker-controlled endpoint, then pass an arbitrary filepath (e.g. /etc/passwd, ~/.env, SSH private keys, cloud credentials) to exfiltrate any file readable by the server process. No prior account, session token, or Authorization header is required. The vulnerability was confirmed through both static code analysis (Phase 1) and a live Docker-based proof-of-concept (Phase 2). --- Details Data flow (source → sink) | Step | Location | Role | |------|----------|------| | 1 |…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the documented multi-user HTTP deployment (--transport streamable-http with global operator Atlassian credentials), sooperset/mcp-atlassian exposes all tools to unauthenticated network clients, and the uploadattachment tool reads an attacker-supplied filepath with no path validation. Chained, an unauthenticated network attacker reads arbitrary files on the MCP server host (e.g. /proc/self/environ → the operator's Atlassian API token + .env secrets, ~/.ssh/idrsa, /etc/passwd) by uploading them to an attacker-chosen page/issue and reading them back. Details Missing authentication (transport): - streamable-http binds 0.0.0.0 by default (src/mcpatlassian/init.py:151). - The OAuth-proxy auth provider is opt-in (ATLASSIANOAUTHPROXYENABLE, default false), so mainmcp is built with auth=None (src/mcpatlassian/servers/main.py:724-731, 813-817). - UserTokenMiddleware.parseauthheader sets authvalidationerror only for a malformed Authorization header; a request with no Authorization…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.