29 mcp-atlassian vulnerabilities fixed in 0.22.0: HTTP authentication bypass, server file exfiltration, SSRF, token file permissions and more

Who is affected

All 29 CVE records list versions before 0.22.0 as affected. The matching 29 GitHub security advisories (GHSAs) were all published by the maintainer on 2026-07-10, the day 0.22.0 was released, and the CVEs were published together on 2026-09-22. The release notes say this release resolved 37 advisories from a security audit; this page covers the 29 that received CVE-2026-772xx IDs. The maintainer’s advisory list also has 3 CVEs fixed in 0.22.0 but published earlier (CVE-2026-73496, CVE-2026-73497, CVE-2026-73498), plus GHSA-6rrj-86cw-gg9j, which has no CVE record yet; those are outside the scope of this page.

Which deployments are most at risk depends on the transport and settings:

OSV lists affected tagged releases v0.1.4 through v0.21.1 for CVE-2026-77244. The OSV range starts at introduced: "0", which the OSV schema defines as a special value for a version that sorts before any other version; it does not name a specific introducing commit, and the actual point where the flaw was introduced is not confirmed.

All 29 CVEs

CVSS is the CNA score in the CVE record; scores marked “(4.0)” are CVSS 4.0 and the rest are 3.1, and the two versions can’t be compared directly. “Key preconditions” summarises each advisory’s conditions for an attack and is not a full description.

How it works

mcp-atlassian is an MCP server: it lets AI assistants call Jira and Confluence features through the MCP protocol. It can talk to one AI client locally over stdio, or serve several users over HTTP on a network. The 29 flaws fall roughly into seven groups.

1. HTTP authentication bypass (3: CVE-2026-77244, CVE-2026-77254, CVE-2026-77248)

When serving over HTTP, each request is supposed to carry the user’s own proof of identity (a token, a string that proves “who you are”). Older versions had a two-part problem. First, the HTTP transport accepted requests without a verified identity; the vendor advisory’s title also says the token verifier accepted any non-empty token. Second, when a request had no usable user credentials, the code fell back to the global Jira or Confluence account the operator had configured on the server. Put together: anyone who could reach the endpoint, with no account, could read and write data as the operator, and the audit trail would name the operator. The CVE record for CVE-2026-77244 classifies it as CWE-287 (improper authentication) and also lists CWE-303 and CWE-862; CVE-2026-77254 describes the same global-credential fallback (CWE-306), and CVE-2026-77248 is a report that chains it with the attachment file read below.

The flawed approach (conceptual illustration, not the original source code):

user_creds = get_user_credentials(request)   # may be empty
if not user_creds:
    user_creds = GLOBAL_OPERATOR_CREDENTIALS   # no identity → borrow the operator's account
client = make_jira_client(user_creds)

The fixed approach (0.22.0):

user_creds = get_user_credentials(request)
if not user_creds:
    if not ALLOW_GLOBAL_CRED_FALLBACK:          # off by default
        return http_401()                       # reject at the transport boundary
    user_creds = GLOBAL_OPERATOR_CREDENTIALS

2. Broken restrictions: tool allowlist and project/space filters (3)

Operators can limit which tools are available with ENABLED_TOOLS and TOOLSETS, and which projects and spaces can be touched with JIRA_PROJECTS_FILTER and CONFLUENCE_SPACES_FILTER. In CVE-2026-77243, the tool limit applied only when tools were listed: a hidden tool didn’t appear in the list but still ran when called by name, including write and delete tools. In CVE-2026-77251 and CVE-2026-77252, the project/space filter used a plain text check to decide whether a query already named a project, so a caller who named another project or space in the query stopped the filter from being added; a call parameter could also replace the operator’s setting, and the board tools had no check at all. The precondition is a caller who can already use these tools (a legitimate user, or a prompt-injected AI) and a server account that can see more than the filter allows. 0.22.0 enforces tool permissions at call time and always adds the filter to queries, so callers can narrow the scope but never widen it.

3. Attachment upload tools reading server files (12)

The Jira and Confluence attachment upload tools (including the attachments parameter of Jira update_issue) take a “file path on the server”; the server process reads that file and uploads it as an attachment. Older versions didn’t restrict the path, so a caller could name any file the server process can read, such as environment variables holding API tokens, .env files, SSH keys or cloud credentials, and have it uploaded to an issue or page they can see. Several advisories call this an incomplete fix of CVE-2026-27825: 0.17.0 added path checks for the “download attachment, write a file” direction but not for “upload attachment, read a file”. The 12 advisories are separate reports of the same root cause from different researchers, and they describe the preconditions differently: most require a caller who can use write tools and has an issue or page to attach to; some note that a prompt-injected AI triggers it and that local stdio mode is affected; others describe a no-account scenario (see “Chaining” below).

The flawed approach (conceptual illustration):

path = caller_supplied_path          # path chosen by the caller
upload_as_attachment(open(path, "rb"))  # reads a file on the server directly

The fixed approach (0.22.0):

path = validate_safe_path(caller_supplied_path)  # must be inside the server's working directory, else rejected
upload_as_attachment(open(path, "rb"))

4. Incomplete path restriction allowing a module overwrite (1: CVE-2026-77271)

When 0.17.0 fixed CVE-2026-27825, it limited where attachment downloads can be written to the process’s working directory. In common container deployments, though, the working directory is the program’s own directory, so its own Python modules were inside the “allowed” area. The advisory describes how someone with Confluence write access who can reach the HTTP port could overwrite a program file with an attachment, and the replaced code would run the next time the process restarts. The 0.22.0 release notes say this “intra-CWD overwrite” variant is closed.

5. SSRF protection bypasses (6)

SSRF (server-side request forgery) means making the server connect somewhere it shouldn’t for the attacker, such as internal services or a cloud metadata service (which can hand out cloud credentials). The multi-user HTTP mode lets request headers name the Jira/Confluence URL to connect to; 0.17.0 added a check for CVE-2026-27826 that rejects URLs pointing at internal addresses. These 6 CVEs are gaps in that check: the address resolved during the check differs from the one used to connect (DNS rebinding, CVE-2026-77242 and CVE-2026-77265); when the server is redirected to an internal address, some code paths or authentication methods don’t check the redirect (CVE-2026-77249 and CVE-2026-77261); the checker and the code that sends the request see different hosts in the same URL (CVE-2026-77274); and header URLs still reach a path that isn’t checked (CVE-2026-77267). CVE-2026-77261 is about the basic auth and OAuth authentication methods not checking redirects, and requires the connected Atlassian server itself to return a malicious redirect. 0.22.0 checks redirects on every connection, rejects URLs that can be read two ways, and pins the connection to the address that was checked.

6. Overly permissive OAuth token files (3: CVE-2026-77250, CVE-2026-77256, CVE-2026-77268)

With OAuth, the program stores tokens in the system keyring, but it also always writes a plaintext backup with the access token and refresh token in the .mcp-atlassian folder in the home directory. That file is created with default permissions, which in common setups lets the group or every user on the machine read it. On shared hosts, CI machines or containers that mount the home directory, other users or processes can take the tokens, and a refresh token keeps granting access until revoked or expired. 0.22.0 makes the file owner-only (file 0600, folder 0700).

7. Reflected XSS in the OAuth setup page (1: CVE-2026-77272)

While the OAuth setup wizard runs, the program briefly starts a web server to receive the authorisation callback, listening on all network interfaces. The callback page put the error message from the URL straight into its HTML, so a crafted link could run JavaScript in the victim’s browser. The victim has to be running the setup wizard (the advisory says it waits up to 5 minutes) and open the attacker’s link. 0.22.0 HTML-escapes the callback page output.

Chaining

Stated by an advisory: combining the HTTP authentication bypass with the attachment file read lets someone with no account read files on the server. Advisory GHSA-cc5h-2pwp-pvcc (CVE-2026-77248) says: “Chained, an unauthenticated network attacker reads arbitrary files on the MCP server host”, with the preconditions of the streamable-http transport and global operator credentials. GHSA-f4p7-qx46-wc5j (CVE-2026-77260) also describes an HTTP-mode upload with no authentication that borrows the operator’s credentials, and GHSA-wv8v-v4c5-v75j (CVE-2026-77246) describes a case with no Authorization header where the file goes to a service URL given in the request headers. The release notes list GHSA-cc5h-2pwp-pvcc under the HTTP authentication fix, and the attachment path restriction shipped in the same release, so both ends are closed in 0.22.0.

PlainCVE’s analysis: the files read often include the operator’s Atlassian API token or other service credentials, which an attacker can use directly against Atlassian or those services without going through the MCP server, and upgrading does not invalidate them; if you suspect exposure, rotate credentials rather than only upgrading. Also, from 0.22.0 attachment paths are only confined to the working directory; if secrets such as a .env file sit in the working directory, they can still be uploaded by a caller who can use the upload tools (the CVE-2026-77271 advisory uses a .env file in a container’s working directory as an example), and with ALLOW_GLOBAL_CRED_FALLBACK=true on an exposed server, unauthenticated requests can use those tools too.

What is not confirmed (our analysis)

0.22.0 gates the fallback to global credentials. On 2026-07-11, the day after 0.22.0 shipped, the maintainer acknowledged in another PR that the OAuth proxy verifier still accepted any non-empty bearer token; the PR for validating tokens upstream (last updated 2026-09-21) was still unmerged on 2026-09-28. So when the OAuth proxy is enabled, 0.22.0 still has the “accepts any non-empty token” behavior (confirmed by the maintainer); no source says whether later versions fix it.

Timeline

The maintainer advisories and the fix both came about two and a half months before the CVEs were published.

Further reading

• Scoring: the highest is CVE-2026-77244, which the CNA scores CVSS 3.1 10.0 (scope changed, high confidentiality and integrity impact, no availability impact), followed by CVE-2026-77254 at 9.1. For 8 CVEs the CNA score is CVSS 4.0. As of 2026-09-24, NVD is still analysing CVE-2026-77244 and has no score of its own.
• Exploitation: as of 2026-09-24, none of the 29 CVEs is in CISA KEV. In CISA’s SSVC assessments in the CVE records, CVE-2026-77244 is “none” but rated automatable; checking all 29 records on 2026-09-28, 26 have an SSVC assessment (7 “none”, 19 “poc”, meaning a public proof of concept), none is “active”, and 3 (CVE-2026-77262, CVE-2026-77265, CVE-2026-77267) have no assessment yet. Many of the public advisories include reproduction steps the researchers tested in their own test environments. No source reports exploitation in the wild, and there is no information on whether they were exploited before a patch existed. FIRST publishes an EPSS score (an estimate of the chance of exploitation in the next 30 days) of 0.28% for CVE-2026-77244 (2026-09-27).
• Code execution: only the CVE-2026-77271 advisory describes a path to code execution (overwriting a program module, effective after a restart); the others don’t say so. The CVE-2026-77244 advisory only relates it to an earlier, different CVE (CVE-2026-27825) of the same class.
• Related advisory: GHSA-vc8m-84rp-53hx (CVE-2026-77254) describes the same fallback to global credentials and was closed by the same fix.
• Related weakness types: CWE-287, CWE-306, CWE-862, CWE-22, CWE-918, CWE-732, CWE-79; the design principles “deny by default on failure” (fail-closed) and “check permissions when a tool runs, not only when it is listed”.