Between 14 and 22 September 2026, NVD published a batch of CVEs for mcp-atlassian, a popular open source MCP server that lets AI assistants read and write Jira and Confluence. The most serious, CVE-2026-77244, rates CVSS 10.0: the server's HTTP transport accepted any non-empty token, or none at all, and then ran tools with the operator's own Atlassian credentials. All of the issues are fixed in version 0.22.0, which the maintainers released on 10 July and which resolved 37 advisories in total.
What's affected
Every CVE below affects mcp-atlassian (PyPI) before 0.22.0 and is fixed in 0.22.0.
- CVE-2026-77244 (CVSS 10.0). The
AtlassianOpaqueTokenVerifieraccepted any non-empty string. Requests with no Authorization header, or any Bearer value, reached tool handlers, which fell back to the server'sJIRA_USERNAMEandJIRA_API_TOKENenvironment variables. The advisory says this hit deployments where the OAuth proxy was not enabled, which is the default. Reported by crazydude123. - CVE-2026-77243 (CVSS 8.8).
ENABLED_TOOLSandTOOLSETShid tools fromtools/listbut were not rechecked ontools/call. A client that knew a hidden tool's name could call it, including write and delete tools. - CVE-2026-77271 (CVSS 8.8 per NVD). Attachment path validation defaulted its base directory to the current working directory, so an attacker could overwrite a Python module there and get code execution when it was later imported. NVD says this bypassed the remediation for an earlier CVE, CVE-2026-27825.
- CVE-2026-73496 (CVSS 7.7). The Confluence and Jira attachment upload tools accepted absolute or traversing file paths, so a client with write-tool access could upload server files, environment-held credentials or another tenant's data to Atlassian. NVD notes a local single-user stdio deployment does not cross this trust boundary.
- CVE-2026-73497 (CVSS 6.5). From 0.17.0, SSRF validation of the
X-Atlassian-Jira-UrlandX-Atlassian-Confluence-Urlheaders checked DNS once and connected later, so DNS rebinding could reach cloud metadata or internal services. - CVE-2026-77250 (CVSS 6.1). OAuth fallback token files under
~/.mcp-atlassian/were written with default permissions, readable by other local users on a permissive umask.
The theme is clear: the server-side, multi-user HTTP mode carried most of the risk.
How to check if you're exposed
Find the version:
pip show mcp-atlassian 2>/dev/null | grep -i '^version'
Then find out how it runs. In each MCP client config, an mcp-atlassian entry with a command runs locally over stdio. An entry with a url points at a shared HTTP deployment, which is where CVE-2026-77244 applies.
For an HTTP deployment, send a request with no credentials. On 0.22.0, the release notes say unauthenticated HTTP requests get a 401:
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://mcp-atlassian.internal.example/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Anything other than 401 needs investigation. Also check token file permissions on hosts that used OAuth:
ls -l ~/.mcp-atlassian/ 2>/dev/null
What to do now
- Upgrade to 0.22.0 or later. Read the upgrade notes first, because several defaults changed.
- Leave the global credential fallback off. In 0.22.0 it is opt-in through
ALLOW_GLOBAL_CRED_FALLBACK, which defaults to off. Turning it back on brings back the shared-identity model that made CVE-2026-77244 so damaging. - Expect attachment paths to fail if they point outside the server's working directory. That is the fix for CVE-2026-73496 and CVE-2026-77271 working.
- Rotate the operator's Atlassian API token if an HTTP deployment before 0.22.0 was reachable by anyone you don't fully trust, then review Jira and Confluence audit logs for actions by that account.
- Tighten token files with
chmod 600on anything under~/.mcp-atlassian/created before the upgrade. - Don't rely on tool hiding for authorization on any MCP server until you've confirmed it enforces the restriction on calls, not just on listing.
Why it matters
Many MCP servers start life as single-user stdio tools, where the user and the server share one identity and one machine. Adding an HTTP transport turns that into a multi-user service, and every assumption has to change. Here the server kept using one person's credentials for everyone and treated "has a token" as "is authenticated."
CVE-2026-77243 is a pattern worth testing in every MCP server you run: filtering tools/list is a display choice, not access control. If the call path doesn't check, the restriction doesn't exist.
The timing is also a lesson. The fix shipped in July, but the CVE records only appeared in September. Teams that only react to CVE feeds would have learned about a CVSS 10.0 issue two months after the patch was available.
Try it yourself
Pick one MCP server your team runs over HTTP and send it an unauthenticated tools/list request like the one above. Note what comes back. Then walk through how to set up and register MCP servers with authentication from the start. The Gold directory at gold.safeguard.sh also lists MCP servers alongside known CVEs.
Click through it at your own pace, or open it full screen.
Quick check
I run mcp-atlassian locally over stdio for myself. Is CVE-2026-77244 a concern?
It's an HTTP transport issue, so a local stdio setup isn't the target. Upgrade anyway, since 0.22.0 also fixes the token file permission and path issues.
Why did a missing token still work?
The token verifier accepted any non-empty value, requests without one still reached tool handlers, and the handlers fell back to the operator's environment credentials.
Does hiding a tool with ENABLED_TOOLS stop clients from calling it on old versions?
No. Before 0.22.0, CVE-2026-77243 let a client call a hidden tool directly by name.
